Как работает команда разработки в ИТ

Последние несколько лет я работаю в финтехе, поэтому примеры и распределение ролей здесь ближе к крупным продуктовым и enterprise-командам. Это не универсальная оргсхема, а одна из рабочих моделей. Этапы в ней пересекаются, а роли могут совмещаться.

Фаза 1. Исследование задачи

1. Product Owner (PO), бизнес-аналитик (BA) и другие продуктовые роли исследуют проблему, пользователей, текущий процесс и ожидаемый эффект. Для внутренних продуктов такое исследование не менее важно, чем для внешнего рынка.
2. PO отвечает за ценность и приоритеты продукта, согласует направление со стейкхолдерами и упорядочивает backlog. Конкретные границы роли зависят от организации.

Фаза 2. Анализ и планирование

1. Системные аналитики (СА) уточняют сценарии, данные, интеграции, ограничения и требования к качеству. Результатом может быть спецификация, схема, контракт API или другой понятный команде артефакт.
2. Tech Lead и разработчики оценивают варианты реализации, риски и объём работы. QA, DevOps, специалисты по безопасности и другие участники подключаются до разработки, если их ограничения влияют на решение.
3. В Scrum Scrum Master отвечает за понимание и применение фреймворка, помогает команде повышать эффективность и обеспечивает проведение полезных событий в пределах timebox. Он не обязан лично вести каждую встречу. В Kanban и других моделях те же задачи могут быть распределены иначе.

Фаза 3. Реализация

1. Разработчики реализуют решение, пишут автоматические тесты, проводят code review и уточняют требования вместе с аналитиками и продуктом. Хорошая постановка снижает неопределённость, но не отменяет диалог во время разработки.
2. Инфраструктурные, платформенные или DevOps-инженеры помогают с окружениями, CI/CD, наблюдаемостью и автоматизацией. DevOps при этом остаётся не только названием роли, но и набором практик совместной ответственности разработки и эксплуатации.

Фаза 4. Проверка качества

1. QA помогает определить стратегию качества, проектирует проверки, автоматизирует тесты и исследует рисковые сценарии. Производительность, безопасность и надёжность проверяют в объёме, который соответствует риску продукта.
2. Качество не начинается после завершения кода: критерии приёмки, тестируемость и наблюдаемость обсуждают заранее, а проверки выполняют на протяжении всего цикла.
3. В Scrum Daily Scrum помогает разработчикам проверить продвижение к цели спринта и скорректировать план на ближайшие сутки. Это не обязательный статус-отчёт руководителю, а ретроспектива проводится отдельно в конце спринта.

Фаза 5. Демо и ретроспектива

1. Команда сверяет результат с критериями приёмки и Definition of Done. Демо позволяет показать результат и собрать обратную связь. Sprint Review шире: команда и стейкхолдеры вместе оценивают результат спринта, изменения контекста и дальнейшие шаги; при необходимости обновляют Product Backlog.
2. Ретроспектива посвящена процессу: команда выбирает конкретные улучшения и проверяет их в следующих итерациях.

Фаза 6. Релиз

Релиз не обязан ждать демо или конца спринта: готовый инкремент можно поставить раньше. Sprint Review не служит обязательным разрешением на выпуск.

1. Релиз — общая ответственность команды. Автоматизированный pipeline, мониторинг, план отката, feature flags и понятный порядок реагирования снижают риск поставки.
2. После релиза команда следит не только за ошибками и техническими метриками, но и за продуктовыми показателями. PO и продуктовые роли собирают обратную связь и обновляют приоритеты.

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

Как выглядит один вертикальный срез

Возьмём учебный пример: клиент должен видеть статус своей заявки. Продуктовая задача не заканчивается экраном. Нужно договориться, откуда приходит статус, насколько он актуален, кто имеет право его увидеть и что показывать при недоступности источника.

Аналитик уточняет состояния и переходы, инженер предлагает способ получения данных, QA разбирает ошибки и задержки, специалист по эксплуатации помогает определить наблюдаемость. Эти действия идут рядом. Если передавать задачу строго по цепочке отделов, важное ограничение может обнаружиться слишком поздно.

Первый завершённый срез может поддерживать только один тип заявки, но должен проходить весь путь: источник, API, интерфейс, права, проверка и наблюдение после выпуска. Такой результат позволяет получить обратную связь о продукте. Отдельно готовый интерфейс без данных даёт гораздо меньше информации о работоспособности решения.

Кто принимает решение при конфликте

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

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

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

Роли и события Scrum определены в официальном Scrum Guide. Описанная здесь схема шире Scrum: это мой способ обсуждать путь продукта и ответственность участников.

---

Из моего Telegram-канала @it_underside.

Ваш ДПУПП