Основную причину я вижу в следующем: такое деление (один думает глобально про бизнес, второй думает локально про систему) по-нормальному срабатывает только при создании продукта по принципу конвейера: сперва один на своей полянке принял от менеджмента вводные и написал бизнес-аналитику, второй на основе этого написал задротские системные описания, чтобы, в свою очередь, это отправить в разработку.
В большинстве живых и более гибких продуктов эта линейная схема запутывается в лютый клубок: бизнес-аналитик делает свое описание, системный аналитик говорит «БОРИС ТУТ ХЕРНЯ ДАВАЙ СДЕЛАЕМ ПО ДРУГОМУ», бизнес-аналитик отвечает «СЕМЕНЫЧ НО У МЕНЯ ЖЕ ПРОЦЕСС ВСТАНЕТ», системный аналитик парирует «А ТЫ ЕГО БОРИС ПО ДРУГОМУ ПОВЕРНИ И НОРМ БУДЕТ», а бизнес-аналитик умудренно кивает «ТОЧНО СЕМЕНЫЧ У НАС ЖЕ ТАМ БАЗА НА ПОСТГРЕ ПОДНЯТА ЧЕРЕЗ НЕЕ ДАННЫЕ ПУСТИМ» - и они делают охрененно хорошее решение.
Чуете, да? Из-за того, что живая разработка не всегда идет по принципу «сперва придумай идеальный сценарий, а мы его реализуем», но часто закольцовывается, пересекается и ходит по кругу, БА начинает думать как СА, а СА начинает думать как БА. Со временем начинают происходить и еще более чудовищные вещи: БА может при продумывании задачи учитывать системную архитектуру и какие-нибудь особенности микросервисов, а СА - описывать задачи с минимальным вовлечением БА. БА приобретает черты СА, а СА начинает издали походить на БА.
Когда я возглавлял команду, которая работала над новым банковским мобильным приложением, доходило до смешного: в каждой из пяти подкоманд по формально были свои БА и СА, но в какой-то момент они начали меняться ролями, сливаться между собой и иногда аналитики уже сами забывали, бизнесовые они или системные. И я скажу страшную вещь: это было нормально, потому что для нормальной Agile-среды пофиг, какую должность ты носишь на бейджике - важны компетенции, а в нормальном, живом процессе более востребованы не люди «Я ГОТОВ ОПИСАТЬ ВАШУ ЗАДАЧУ С ПОЗИЦИЙ БИЗНЕСА А ДАЛЬШЕ ЛЮБИТЕСЬ САМИ», но люди «ЧЕГО ТЕБЕ НАДО? ЩАС ПАДАЖЖИ ДЛЯ РАЗРАБОВ ВСЕ ОПИШУ». В Agile-среде в принципе порой хрен разберешься, где заканчивается зона деятельности одного спеца и начинается зона деятельности другого - и это тоже нормальная командная практика. Цель и результаты у всех в любом случае единые; забегая вперед в один из своих будущих постов, такую конструкцию еще и проще синхронизировать с разработкой и дизайном.
В большинстве живых и более гибких продуктов эта линейная схема запутывается в лютый клубок: бизнес-аналитик делает свое описание, системный аналитик говорит «БОРИС ТУТ ХЕРНЯ ДАВАЙ СДЕЛАЕМ ПО ДРУГОМУ», бизнес-аналитик отвечает «СЕМЕНЫЧ НО У МЕНЯ ЖЕ ПРОЦЕСС ВСТАНЕТ», системный аналитик парирует «А ТЫ ЕГО БОРИС ПО ДРУГОМУ ПОВЕРНИ И НОРМ БУДЕТ», а бизнес-аналитик умудренно кивает «ТОЧНО СЕМЕНЫЧ У НАС ЖЕ ТАМ БАЗА НА ПОСТГРЕ ПОДНЯТА ЧЕРЕЗ НЕЕ ДАННЫЕ ПУСТИМ» - и они делают охрененно хорошее решение.
Чуете, да? Из-за того, что живая разработка не всегда идет по принципу «сперва придумай идеальный сценарий, а мы его реализуем», но часто закольцовывается, пересекается и ходит по кругу, БА начинает думать как СА, а СА начинает думать как БА. Со временем начинают происходить и еще более чудовищные вещи: БА может при продумывании задачи учитывать системную архитектуру и какие-нибудь особенности микросервисов, а СА - описывать задачи с минимальным вовлечением БА. БА приобретает черты СА, а СА начинает издали походить на БА.
Когда я возглавлял команду, которая работала над новым банковским мобильным приложением, доходило до смешного: в каждой из пяти подкоманд по формально были свои БА и СА, но в какой-то момент они начали меняться ролями, сливаться между собой и иногда аналитики уже сами забывали, бизнесовые они или системные. И я скажу страшную вещь: это было нормально, потому что для нормальной Agile-среды пофиг, какую должность ты носишь на бейджике - важны компетенции, а в нормальном, живом процессе более востребованы не люди «Я ГОТОВ ОПИСАТЬ ВАШУ ЗАДАЧУ С ПОЗИЦИЙ БИЗНЕСА А ДАЛЬШЕ ЛЮБИТЕСЬ САМИ», но люди «ЧЕГО ТЕБЕ НАДО? ЩАС ПАДАЖЖИ ДЛЯ РАЗРАБОВ ВСЕ ОПИШУ». В Agile-среде в принципе порой хрен разберешься, где заканчивается зона деятельности одного спеца и начинается зона деятельности другого - и это тоже нормальная командная практика. Цель и результаты у всех в любом случае единые; забегая вперед в один из своих будущих постов, такую конструкцию еще и проще синхронизировать с разработкой и дизайном.