коротко

Современная IT-команда — результат разделения труда: разработчики пишут код, тестировщики ищут баги, девопсы строят доставку, дизайнеры решают задачу пользователя, продакт решает что делать, проджект следит за сроками, тимлид отвечает за техническое качество. Каждый глубоко копает свой участок и теряет контекст соседних. Аналитик (BA/SA) сидит в центре и сшивает эти миры: переводит, уточняет, проверяет понимание. Чем дальше роль от кода — тем меньше технического понимания; чем дальше от бизнеса — тем меньше понимания «зачем».

Когда-то был просто «программист». Один человек писал код, сам его тестировал, сам выкладывал на сервер, сам общался с заказчиком, сам рисовал интерфейс. Иногда сам и паял железо.

Потом программ стало больше и они стали сложнее. Один человек перестал справляться — началось разделение труда. Сначала отделились те, кто пишет код, от тех, кто его тестирует. Потом — те, кто выкладывает. Потом появились те, кто только проектирует, кто только общается с заказчиком, кто решает, что вообще делать. Так мы получили современную команду.

Разделение труда — это хорошо: каждый становится экспертом, качество растёт. Но есть нюанс.

Проблема: потеря понимания

Представьте конвейер. Каждый делает свою операцию. Всё работает, пока конвейер настроен. Но если что-то идёт не так — человек на своём участке не понимает, как его работа связана с целым. В IT происходит то же самое.

Разработчик отлично знает код, но не всегда понимает, зачем эта фича бизнесу. Тестировщик проверяет по тест-кейсам, но не видит общей картины. Девопс настраивает пайплайны, но не знает, что за продукт деплоит. И чем дальше от кода — тем хуже: продакт принимает решения, но иногда не понимает, как это работает внутри; заказчик вообще видит только кнопки на экране.

Это не вина людей

Это следствие системы. Каждый глубоко копает свой участок и неизбежно теряет контекст соседних. Бороться надо не с людьми, а с разрывами между ними — это и есть работа аналитика.

Карта ролей

Грубо, с упрощениями, но чтобы была картинка. Для каждой роли — чем занимается и что важно про неё знать.

Разработчик (Developer)

Пишет код, превращает требования в работающую систему. Бывает фронтенд (интерфейс), бэкенд (серверная логика), фулстек (и то, и другое). Думает в терминах «как сделать», а не «зачем». Хотите хороший результат — дайте понятную задачу с контекстом.

Тестировщик (QA)

Проверяет, что система работает как задумано. Ищет баги, пишет тест-кейсы, иногда автоматизирует. Хороший тестировщик — не враг разработчика, а союзник: он находит проблемы до того, как их найдут пользователи.

Девопс (DevOps)

Занимается инфраструктурой: сервера, деплой, мониторинг, CI/CD. Делает так, чтобы код из репозитория попадал к пользователям. Это не «человек, который нажимает кнопку деплоя» — это инженер, который строит конвейер доставки. Без него команда выкладывает код вручную и страдает.

Дизайнер (UI/UX)

UI рисует интерфейс, UX думает, как пользователь будет взаимодействовать с системой. Часто это один человек. Хороший дизайнер не «делает красиво» — он решает задачу пользователя. Красота — побочный эффект.

Аналитик (BA/SA)

Выясняет, что нужно сделать. Переводит с языка бизнеса на язык разработки: пишет требования, рисует схемы, задаёт неудобные вопросы. Системный аналитик копает глубже в технику, бизнес-аналитик — в процессы и потребности; на практике границы размыты. Это вы.

Продакт-менеджер (Product Manager)

Решает, что делать и в каком порядке. Отвечает за продукт целиком: стратегию, приоритеты, метрики. Это не заказчик и не начальник, а партнёр. Хороший продакт объяснит «зачем», плохой скажет «просто сделай».

Проджект-менеджер (Project Manager)

Следит за сроками, ресурсами, рисками. Организует процесс: встречи, статусы, эскалации. Не принимает решения «что делать» — делает так, чтобы решения выполнялись вовремя.

Тимлид (Team Lead)

Разработчик, который ещё и управляет командой: распределяет задачи, проводит код-ревью, менторит, отвечает за техническое качество. Ваш главный союзник в оценке сложности и технических ограничений.

Откуда это взялось

Деления на «BA» и «SA» в раннем IT не было — был «системный аналитик» в смысле 1970-х, человек, проектирующий систему целиком. Бизнес-анализ как отдельная дисциплина оформился к 2000-м (свод знаний BABOK вышел в 2005). Поэтому в вакансиях термины до сих пор плавают: в одной компании «системный аналитик» пишет ТЗ и рисует API, в другой — почти продакт. Смотрите не на название, а на обязанности.

Где теряется понимание

Представьте путь информации. Заказчик рассказывает продакту, чего хочет. Продакт переводит это в задачи для аналитика. Аналитик пишет требования для разработчика. Разработчик пишет код. Тестировщик проверяет. Девопс выкладывает. На каждом переходе — потеря, как в игре «испорченный телефон».

flowchart LR
  A["Заказчик: клиенты быстрее оформляли заказ"] --> B["Продакт: упростить чекаут"]
  B --> C["Аналитик: убрать лишние поля формы"]
  C --> D["Разработчик: убрал поле комментарий"]
  D --> E["Пользователи: а где написать что домофон не работает?"]

Схема выше — это и есть «испорченный телефон» на конкретном примере. Заказчик сказал «хочу, чтобы клиенты быстрее оформляли заказ». Продакт услышал «упростить чекаут». Аналитик записал «убрать лишние поля». Разработчик убрал поле «комментарий к заказу». А пользователи спрашивают: «А где написать, что домофон не работает?» Пример утрированный, но суть верная: чем больше звеньев, тем больше искажений.

Что с этим делать аналитику

Вы в центре цепочки — переводчик между мирами. Ваша задача — сокращать дистанцию: не просто передавать информацию, а проверять понимание на каждом этапе. Несколько практик, которые работают у меня:

  • Разговаривайте с разработчиками напрямую — не через тимлида, не через проджекта. Так вы узнаёте ограничения, которых нет в документации (как именно — в записи разговор с разработчиками).
  • Ходите к заказчику вместе с продактом или вместо него, если продакт не против. Первичная информация — самая ценная.
  • Задавайте «почему» вверх и вниз. Вверх — «почему мы это делаем?». Вниз — «почему это сложно реализовать?».
  • Не стесняйтесь признавать, что не понимаете. «Объясни, как будто мне пять» — нормальная фраза. Лучше спросить, чем додумать неправильно.

Чем дальше роль от кода — тем меньше технического понимания. Чем дальше от бизнеса — тем меньше понимания «зачем». Аналитик сидит посередине и сшивает эти миры. А первый инструмент сшивания — умение задавать правильный вопрос про смысл и деньги задачи.

Частые вопросы

Чем системный аналитик отличается от бизнес-аналитика?

Системный аналитик копает в техническую сторону: API, схемы данных, интеграции, требования к системе. Бизнес-аналитик — в процессы и потребности бизнеса. На практике границы размыты, и в разных компаниях под одним названием делают разное. Фулстек-аналитик закрывает оба конца: от бизнес-смысла до контракта API.

Чем продакт отличается от проджекта?

Продакт-менеджер решает, ЧТО делать и в каком порядке, и отвечает за ценность продукта. Проджект-менеджер следит за тем, чтобы решённое выполнялось вовремя и в рамках ресурсов. Продакт — про содержание, проджект — про процесс и сроки.

Почему в команде теряется понимание задачи?

Из-за разделения труда информация идёт по цепочке заказчик → продакт → аналитик → разработчик → тестировщик → девопс, и на каждом переходе искажается, как в «испорченном телефоне». Чем больше звеньев, тем сильнее искажение. Поэтому аналитик проверяет понимание на каждом этапе, а не просто передаёт сообщение дальше.