Современная IT-команда — результат разделения труда: разработчики пишут код, тестировщики ищут баги, девопсы строят доставку, дизайнеры решают задачу пользователя, продакт решает что делать, проджект следит за сроками, тимлид отвечает за техническое качество. Каждый глубоко копает свой участок и теряет контекст соседних. Аналитик (BA/SA) сидит в центре и сшивает эти миры: переводит, уточняет, проверяет понимание. Чем дальше роль от кода — тем меньше технического понимания; чем дальше от бизнеса — тем меньше понимания «зачем».
Когда-то был просто «программист». Один человек писал код, сам его тестировал, сам выкладывал на сервер, сам общался с заказчиком, сам рисовал интерфейс. Иногда сам и паял железо.
Потом программ стало больше и они стали сложнее. Один человек перестал справляться — началось разделение труда. Сначала отделились те, кто пишет код, от тех, кто его тестирует. Потом — те, кто выкладывает. Потом появились те, кто только проектирует, кто только общается с заказчиком, кто решает, что вообще делать. Так мы получили современную команду.
Разделение труда — это хорошо: каждый становится экспертом, качество растёт. Но есть нюанс.
Проблема: потеря понимания
Представьте конвейер. Каждый делает свою операцию. Всё работает, пока конвейер настроен. Но если что-то идёт не так — человек на своём участке не понимает, как его работа связана с целым. В IT происходит то же самое.
Разработчик отлично знает код, но не всегда понимает, зачем эта фича бизнесу. Тестировщик проверяет по тест-кейсам, но не видит общей картины. Девопс настраивает пайплайны, но не знает, что за продукт деплоит. И чем дальше от кода — тем хуже: продакт принимает решения, но иногда не понимает, как это работает внутри; заказчик вообще видит только кнопки на экране.
Это не вина людей
Это следствие системы. Каждый глубоко копает свой участок и неизбежно теряет контекст соседних. Бороться надо не с людьми, а с разрывами между ними — это и есть работа аналитика.
Карта ролей
Грубо, с упрощениями, но чтобы была картинка. Для каждой роли — чем занимается и что важно про неё знать.
Разработчик (Developer)
Пишет код, превращает требования в работающую систему. Бывает фронтенд (интерфейс), бэкенд (серверная логика), фулстек (и то, и другое). Думает в терминах «как сделать», а не «зачем». Хотите хороший результат — дайте понятную задачу с контекстом.
Тестировщик (QA)
Проверяет, что система работает как задумано. Ищет баги, пишет тест-кейсы, иногда автоматизирует. Хороший тестировщик — не враг разработчика, а союзник: он находит проблемы до того, как их найдут пользователи.
Девопс (DevOps)
Занимается инфраструктурой: сервера, деплой, мониторинг, CI/CD. Делает так, чтобы код из репозитория попадал к пользователям. Это не «человек, который нажимает кнопку деплоя» — это инженер, который строит конвейер доставки. Без него команда выкладывает код вручную и страдает.
Дизайнер (UI/UX)
UI рисует интерфейс, UX думает, как пользователь будет взаимодействовать с системой. Часто это один человек. Хороший дизайнер не «делает красиво» — он решает задачу пользователя. Красота — побочный эффект.
Аналитик (BA/SA)
Выясняет, что нужно сделать. Переводит с языка бизнеса на язык разработки: пишет требования, рисует схемы, задаёт неудобные вопросы. Системный аналитик копает глубже в технику, бизнес-аналитик — в процессы и потребности; на практике границы размыты. Это вы.
Продакт-менеджер (Product Manager)
Решает, что делать и в каком порядке. Отвечает за продукт целиком: стратегию, приоритеты, метрики. Это не заказчик и не начальник, а партнёр. Хороший продакт объяснит «зачем», плохой скажет «просто сделай».
Проджект-менеджер (Project Manager)
Следит за сроками, ресурсами, рисками. Организует процесс: встречи, статусы, эскалации. Не принимает решения «что делать» — делает так, чтобы решения выполнялись вовремя.
Тимлид (Team Lead)
Разработчик, который ещё и управляет командой: распределяет задачи, проводит код-ревью, менторит, отвечает за техническое качество и архитектуру в рамках своей команды. Ваш главный союзник в оценке сложности и технических ограничений.
Тимлид ≠ Engineering Manager — это разные люди в крупной команде
В небольшой команде тимлид совмещает всё. Но как только людей становится много, роль расщепляется на две. Team Lead остаётся техническим: код-ревью, архитектурные решения, качество кода, «как делать». Engineering Manager (EM) уходит в людей: найм, увольнения, 1-on-1, зарплаты, рост и развитие инженеров, разрешение человеческих конфликтов. EM почти не пишет код. Аналитику это важно практически: за оценкой сложности и техническим спором вы идёте к тимлиду, а «команда не успевает, нужен ещё человек» или «разработчик игнорирует мои требования, поговори с ним» — это к EM. Перепутаете — потеряете время.
Архитектор (Architect)
Появляется там, где система перестаёт умещаться в голову одной команды: много сервисов, несколько команд, сложные интеграции между ними. Отвечает за то, как части системы стыкуются друг с другом — границы сервисов, контракты, общие решения (какой протокол, какая шина событий, где хранить что). В отличие от тимлида, смотрит не внутрь одной команды, а на стыки между многими. Аналитик на интеграциях работает с ним плотно: именно архитектор скажет, «это идёт через очередь, а не синхронным вызовом», и это сразу меняет ваши требования.
SRE (Site Reliability Engineer)
Часто путают с девопсом, но это разные акценты. Девопс строит конвейер доставки (CI/CD, инфраструктура). SRE отвечает за то, чтобы прод работал и не падал: следит за SLO, дежурит на инцидентах, разбирает причины аварий, ставит бюджет ошибок. Если в требованиях есть «доступность 99.9%» или «время восстановления после сбоя» — это разговор с SRE, а не с разработчиком фичи.
Дата-инженер / аналитик данных (Data Engineer)
Владелец данных «вне продукта»: витрины, хранилище, потоки событий, по которым считаются метрики. Когда вам нужны данные для отчёта, для проверки гипотезы или для продуктовой метрики — вы идёте к нему, а не лезете в боевую базу. Он же скажет, какие события уже собираются, а какие надо добавить в требования заранее, иначе считать будет нечего.
Безопасник (Security / AppSec)
Тот самый молчащий стейкхолдер, который не приходит на груминги, а появляется на приёмке и рубит фичу одним вопросом: «а где у вас тут защита персональных данных?». Отвечает за то, чтобы система не утекала и не ломалась злонамеренно. С ним лучше познакомиться до приёмки: требования к персональным данным и правам доступа дешевле заложить заранее, чем переделывать после его вето.
Откуда это взялось
Деления на «BA» и «SA» в раннем IT не было — был «системный аналитик» в смысле 1970-х, человек, проектирующий систему целиком. Бизнес-анализ как отдельная дисциплина оформился к 2000-м (свод знаний BABOK вышел в 2005). Поэтому в вакансиях термины до сих пор плавают: в одной компании «системный аналитик» пишет ТЗ и рисует API, в другой — почти продакт. Смотрите не на название, а на обязанности.
Роли заданы не только обязанностями, но и тем, за что их премируют
Карта выше — это «кто что делает». Но в реальной команде роли сталкиваются не потому, что люди плохие, а потому что у каждого свой KPI, и эти KPI тянут в разные стороны. Конфликт в команде почти всегда — это конфликт интересов, зашитых в премию, а не конфликт характеров. Аналитику важно видеть эту механику: тогда вы понимаете, кто и почему будет давить, и к кому идти за чем.
| Роль | За что её премируют (KPI) | С кем структурно конфликтует |
|---|---|---|
| Продакт | Метрики продукта, выручка, выпущенные фичи | С тимлидом: давит «давайте ещё фичу» против защиты от техдолга. Хочет сейчас, тимлид хочет устойчиво. |
| Тимлид | Стабильность и скорость команды, качество кода | С продактом: тормозит фичи ради рефакторинга и техдолга, иначе через полгода команда встанет. |
| QA | Найденные баги, отсутствие дефектов в проде | С разработчиком: его премируют за найденные проблемы, разработчика — за сделанное в срок. Качество против сроков. |
| Разработчик | Закрытые задачи, выполненные в срок | С QA (сроки против качества) и отчасти с аналитиком, если требования меняются по ходу. |
| DevOps / SRE | Uptime, отсутствие инцидентов (SLO) | С командой фич: «выкатить быстро» против «не уронить прод». Тормозит рискованные релизы. |
| Аналитик | Понятные требования без переспросов и переделок | Прямого KPI-конфликта почти нет — поэтому аналитик и оказывается медиатором между остальными. |
Главное про конфликты
Когда продакт и тимлид спорят о фиче, они не «не любят друг друга» — они оба правы внутри своего KPI. Продакта премируют за выпущенную ценность, тимлида — за то, что система не развалится под техдолгом. Ваша роль аналитика тут не выбрать сторону, а сделать спор предметным: выложить цену каждого варианта (что стоит сделать сейчас, что стоит отложить, чем мы за это заплатим), чтобы решение принимал тот, кто за него отвечает. Считать эту цену — в записи про бизнес-контекст и деньги.
Связка с RACI: у каждой роли своя буква
Карта ролей становится рабочей, когда вы накладываете на неё модель ответственности. Грубо: продакт обычно Accountable за «ЧТО делаем» (отвечает головой за ценность), тимлид — Accountable за «КАК делаем» (техническое решение), аналитик — Responsible за требования (делает руками), а безопасник и SRE часто Consulted (с ними советуются до релиза). Споры в команде наполовину — это спор «а кто здесь вообще Accountable». Как разложить роли по буквам и не остаться с тремя Accountable на одну задачу — в записи про стейкхолдеров и RACI.
Где теряется понимание
Представьте путь информации. Заказчик рассказывает продакту, чего хочет. Продакт переводит это в задачи для аналитика. Аналитик пишет требования для разработчика. Разработчик пишет код. Тестировщик проверяет. Девопс выкладывает. На каждом переходе — потеря, как в игре «испорченный телефон».
flowchart LR A["Заказчик: клиенты быстрее оформляли заказ"] --> B["Продакт: упростить чекаут"] B --> C["Аналитик: убрать лишние поля формы"] C --> D["Разработчик: убрал поле комментарий"] D --> E["Пользователи: а где написать что домофон не работает?"]
Схема выше — это и есть «испорченный телефон» на конкретном примере. Заказчик сказал «хочу, чтобы клиенты быстрее оформляли заказ». Продакт услышал «упростить чекаут». Аналитик записал «убрать лишние поля». Разработчик убрал поле «комментарий к заказу». А пользователи спрашивают: «А где написать, что домофон не работает?» Пример утрированный, но суть верная: чем больше звеньев, тем больше искажений.
Что с этим делать аналитику
Вы в центре цепочки — переводчик между мирами. Ваша задача — сокращать дистанцию: не просто передавать информацию, а проверять понимание на каждом этапе. Несколько практик, которые работают у меня:
- Разговаривайте с разработчиками напрямую — не через тимлида, не через проджекта. Так вы узнаёте ограничения, которых нет в документации (как именно — в записи разговор с разработчиками).
- Ходите к заказчику вместе с продактом или вместо него, если продакт не против. Первичная информация — самая ценная.
- Задавайте «почему» вверх и вниз. Вверх — «почему мы это делаем?». Вниз — «почему это сложно реализовать?».
- Не стесняйтесь признавать, что не понимаете. «Объясни, как будто мне пять» — нормальная фраза. Лучше спросить, чем додумать неправильно.
Чем дальше роль от кода — тем меньше технического понимания. Чем дальше от бизнеса — тем меньше понимания «зачем». Аналитик сидит посередине и сшивает эти миры. А первый инструмент сшивания — умение задавать правильный вопрос про смысл и деньги задачи.
Частые вопросы
Чем системный аналитик отличается от бизнес-аналитика?
Системный аналитик копает в техническую сторону: API, схемы данных, интеграции, требования к системе. Бизнес-аналитик — в процессы и потребности бизнеса. На практике границы размыты, и в разных компаниях под одним названием делают разное. Фулстек-аналитик закрывает оба конца: от бизнес-смысла до контракта API.
Чем продакт отличается от проджекта?
Продакт-менеджер решает, ЧТО делать и в каком порядке, и отвечает за ценность продукта. Проджект-менеджер следит за тем, чтобы решённое выполнялось вовремя и в рамках ресурсов. Продакт — про содержание, проджект — про процесс и сроки.
Почему в команде теряется понимание задачи?
Из-за разделения труда информация идёт по цепочке заказчик → продакт → аналитик → разработчик → тестировщик → девопс, и на каждом переходе искажается, как в «испорченном телефоне». Чем больше звеньев, тем сильнее искажение. Поэтому аналитик проверяет понимание на каждом этапе, а не просто передаёт сообщение дальше.
Как спрашивают на собесе
Роли — частый блок на собеседовании аналитика: проверяют, понимаете ли вы, кто за что отвечает и к кому идти. Вопросы и что в них хотят услышать.
Чем BA отличается от SA и от продакта?
Классика, проверяют, что вы не путаете роли. Ожидаемый ответ: системный аналитик (SA) копает в технику — API, контракты, схемы данных, интеграции; бизнес-аналитик (BA) — в процессы и потребности бизнеса; продакт отвечает за ценность продукта и решает, ЧТО вообще делать. Аналитик помогает решить «как описать и реализовать», продакт — «зачем и что важнее». Хорошо добавить, что на практике границы размыты и смотреть надо на обязанности в конкретной вакансии, а не на название.
К кому пойдёшь за оценкой сложности, за приоритетом и за решением спорного требования?
Проверяют, понимаете ли вы маршрутизацию вопросов. Ожидаемый ответ: за оценкой сложности и техническими ограничениями — к тимлиду (или к разработчику напрямую); за приоритетом «что делаем раньше» — к продакту; за спорным требованием — к тому, кто за него Accountable по RACI (обычно продакт за «что» и тимлид за «как»). Сильный ответ показывает, что вы не несёте любой вопрос «начальнику», а адресуете тому, в чьей зоне ответственности он лежит.
Продакт и тимлид спорят о фиче — какова твоя роль?
Проверяют зрелость: не лезете ли вы судьёй и не прячетесь ли. Ожидаемый ответ: ваша роль — не выбрать сторону, а сделать спор предметным. Оба правы внутри своего KPI (продакт — за ценность, тимлид — за устойчивость и техдолг). Вы выкладываете факты: что даёт фича, чего стоит откладывание техдолга, какие есть промежуточные варианты, — и отдаёте решение тому, кто за него отвечает. Аналитик здесь медиатор и поставщик фактов, а не арбитр.