Роль аналитика в IT
Тема дорожной карты · Business Analysis
Роль BA в IT зависит от организации: в продуктовых компаниях часто сливается с Product Manager (PM отвечает за 'почему', BA — за 'что'); в outsourcing-разработке остаётся отдельной из-за контрактных требований к спецификациям; в регулируемых отраслях (банки, медицина) часто включает 'перевод' регуляторных требований. Ежедневно BA проводит интервью, документирует, моделирует, приоритизирует и валидирует — больше пишет и уточняет, чем строит.
Как это работает
Типичная неделя примерно делится на трети: 30-40% в разговорах (интервью со стейкхолдерами, refinement-сессии, уточняющие вопросы от инженеров); 30-40% в письме (user stories, BPMN-диаграммы, критерии приёмки, decision logs); 20-30% в ревью и валидации (проверка deliverables, проведение UAT, сбор обратной связи). Инструменты зависят от организации: Confluence + Jira (enterprise), Notion + Linear (современные продукты), Miro/FigJam (воркшопы), bpmn.io или Camunda Modeler (процессные диаграммы).
Когда применять
Выделенный BA окупается когда (а) в команде 3+ инженеров и цена ошибок спецификации высокая, (б) требования приходят от нескольких стейкхолдеров, которые не согласны, (в) compliance требует traceable-требований. Для проектов 1-2 инженеров PM или tech lead обычно поглощает роль. Для 50+ инженеров нужно несколько BA, разделённых по доменным областям, плюс senior BA-координатор.
Типичные ошибки
BA как узкое место — самая частая проблема масштабирования: каждый вопрос по требованиям маршрутизируется через одного человека, который становится ограничением. Чините документированием решений так, чтобы инженеры могли self-serve находить ответы — wiki-страницы по user story, а не по разговору со стейкхолдером. BA как PM — вторая ловушка: когда BA начинают приоритизировать, они конфликтуют с PM и путают команду. Граница: BA решает как захватить и структурировать требования; PM решает какие требования будут реализованы следующими.