Роли и зоны ответственности в Scrum Team

Recommended resources

The freely available resources this lesson will direct you to.

Здравствуйте! В предыдущем уроке мы выбирали предиктивный, адаптивный или гибридный способ работы по уровню неопределённости требований и технологии. Теперь перейдём к базовому устройству Scrum: кто за что отвечает внутри Scrum Team.

Для Project Manager это важно не только как теория для собеседования. В реальном продукте смешение зон ответственности быстро приводит к знакомым симптомам: Product Owner пытается раздать задачи разработчикам, Scrum Master превращается в секретаря встреч, а Developers ждут подробных указаний вместо того, чтобы управлять своей работой. В результате формально есть спринты, но нет самоуправления, прозрачных приоритетов и устойчивой поставки ценности.

К концу урока вы сможете различать три зоны подотчётности Scrum Team: максимизацию ценности продукта, создание готового Increment и эффективность применения Scrum.

Scrum Team: не иерархия, а единая команда вокруг продукта

Согласно Scrum Guide, Scrum Team состоит из одного Product Owner, одного Scrum Master и Developers. Это не три отдела и не цепочка управленческого подчинения. Внутри Scrum Team нет иерархии или подкоманд: это кросс-функциональная и самоуправляемая группа, сфокусированная на одной Product Goal.

Диаграмма показывает три взаимодополняющие зоны подотчётности Scrum Team: Product Owner максимизирует ценность, Scrum Master повышает эффективность команды, а Developers создают продукт. Их общая цель — ценный и пригодный к использованию Increment в каждом Sprint.

Слово Developers в Scrum не равно «программисты». Это все специалисты, которые непосредственно создают пригодный к использованию Increment: frontend- и backend-разработчики, QA-инженеры, аналитики, дизайнеры, DevOps-специалисты, инженеры по данным — в зависимости от продукта и того, какие навыки действительно нужны для поставки результата.

Главная идея Scrum — команда отвечает не за набор разрозненных активностей, а за создание полезного результата. Поэтому у всей Scrum Team есть общая подотчётность:

Создавать ценный, пригодный к использованию Increment в каждом Sprint.

Однако у участников команды есть разные конкретные подотчётности. Полезно не путать два близких термина:

Понятие	Смысл в Scrum	Пример
Исполнительская ответственность	Выполнить конкретную работу или создать результат работы	Аналитик подготовил описание сценария; разработчик реализовал API; QA провёл проверку
Подотчётность	Владеть итоговым результатом, принимать решения и отвечать за последствия	Product Owner отвечает за эффективное управление Product Backlog, даже если часть его подготовки делегирована аналитику

Подотчётность обычно нельзя полностью передать другому человеку. Например, Product Owner вправе попросить аналитика описать элементы бэклога, но именно Product Owner остаётся подотчётным за то, что бэклог прозрачен, понятен и упорядочен по ценности.

Accountability, Responsibility and Roles

Прочитайте материал Scrum.org, чтобы закрепить различие между выполнением задачи и подотчётностью за результат. Он также кратко формулирует четыре уровня подотчётности в Scrum, включая общую подотчётность всей команды за Increment.

В начале статьи обратите внимание на различие между responsibility и accountability. Прочитайте пример делегирования, а затем список four high-level areas of accountability, заканчивающийся формулировкой о подотчётности Scrum Master. Сопоставьте эти формулировки с тем, как решения сейчас принимаются в вашей команде.

В разговорной речи допустимо назвать Product Owner, Scrum Master и Developers «ролями». Но точнее воспринимать их как наборы подотчётностей, а не как названия должностей. Должность «руководитель проекта», «тимлид», «системный аналитик» или «руководитель направления» сама по себе ещё не говорит, кто в конкретной Scrum Team принимает продуктовые решения, кто обеспечивает эффективность Scrum и кто отвечает за создание Increment.

Product Owner: ценность, цель продукта и порядок работы

Product Owner подотчётен за максимизацию ценности продукта, создаваемого Scrum Team. Это не означает, что он лично оценивает каждую функцию в деньгах или единолично придумывает весь продукт. Его задача — обеспечить, чтобы команда работала над наиболее ценными проблемами в нужной последовательности.

Ключевой инструмент Product Owner — Product Backlog. Product Owner подотчётен за его эффективное управление, в том числе за:

разработку и ясную коммуникацию Product Goal;
создание и понятное объяснение элементов Product Backlog;
упорядочивание элементов бэклога;
прозрачность, доступность и понятность бэклога для команды и заинтересованных лиц.

Практически это означает, что Product Owner должен принимать или обеспечивать принятие решений вида:

Какую проблему продукта мы решаем?
Какой результат важнее: сократить время обработки кредитной заявки, снизить процент отказов, выполнить обязательное регуляторное изменение или уменьшить операционные издержки?
Что имеет смысл делать следующим, а что пока не стоит брать в работу?
Какие ожидания стейкхолдеров следует включить в бэклог, а какие — отклонить или отложить?

Что Product Owner не обязан и не должен делать

Product Owner не является диспетчером задач. Он не должен ежедневно распределять работу между разработчиками, назначать исполнителей или диктовать техническую реализацию.

Формулировка «PO определяет что делать, а Developers — как делать» полезна как первое приближение, но её нужно понимать аккуратно:

Product Owner формирует цель, ожидаемую ценность и порядок элементов бэклога.
Developers совместно определяют, как достичь Sprint Goal, какие технические шаги нужны, как организовать работу и кто за что возьмётся.
Если техническое ограничение делает ожидаемый результат невозможным или слишком рискованным, Developers должны сделать это прозрачным. Product Owner не может максимизировать ценность, игнорируя фактические ограничения реализации.

Product Owner — один человек, а не комитет. Он может учитывать интересы риск-менеджмента, юридической службы, операционных подразделений, маркетинга, банка-партнёра и пользователей. Но после обсуждений должен существовать понятный владелец решения о содержании и порядке Product Backlog.

Для FinTech-продукта это особенно критично. Если приоритеты одновременно определяют бизнес, compliance, безопасность, внешняя интеграционная команда и несколько руководителей, но никто не обладает полномочиями свести их в единый порядок, разработка получает конфликтующие срочные требования вместо управляемого бэклога.

Developers: создание Increment и управление работой внутри Sprint

Developers подотчётны за создание любого аспекта пригодного к использованию Increment в каждом Sprint. Их зона ответственности не ограничивается написанием кода. Если для рабочего Increment нужны тестирование, мониторинг, миграция данных, документация, настройка CI/CD, проверка безопасности или интеграция с внешним API, команда должна учитывать эту работу.

Scrum Guide выделяет четыре постоянные подотчётности Developers:

Создать план работы на Sprint — Sprint Backlog.
Поддерживать качество, соблюдая Definition of Done.
Ежедневно адаптировать свой план ради достижения Sprint Goal.
Нести взаимную профессиональную подотчётность друг перед другом.

Важно различать упорядочивание продукта и планирование реализации:

Вопрос	Основная подотчётность
Какую проблему решаем и почему она важна?	Product Owner
Что важнее в Product Backlog?	Product Owner
Реалистична ли работа в рамках Sprint?	Developers
Как разбить работу на технические шаги?	Developers
Кто будет выполнять конкретную работу?	Developers
Как обеспечить требуемое качество?	Developers
Как устранить процессное или организационное препятствие?	Scrum Master при участии всей команды

Самоуправление не означает, что команда действует без ограничений, архитектурных правил или координации с другими командами. Оно означает, что никто извне не должен детально управлять тем, кто, что, когда и как делает внутри работы, необходимой для достижения цели.

Например, в интеграции с сервисом оценки автомобиля Product Owner может поставить в высокий приоритет сценарий получения оценки до финального расчёта кредита. Но именно Developers определяют, потребуется ли техническое исследование, какие тайм-ауты и повторные попытки нужны, как обеспечить идемпотентность запросов, как провести нагрузочные проверки и какие метрики добавить для наблюдаемости.

Распространённая ошибка: «разработчики отвечают только за код»

Если Developers считают, что тестирование — исключительно зона QA, релиз — зона DevOps, а требования — зона аналитика, команда может произвести много локальных результатов, но не создать готовый Increment. Scrum не отменяет специализацию, но делает команду совместно ответственной за достижение результата.

Scrum Master: эффективность Scrum, а не администрирование встреч

Scrum Master подотчётен за эффективность Scrum Team. Он помогает всем понять и применять Scrum в соответствии с Scrum Guide, а также улучшать способ работы команды в рамках фреймворка.

Это лидерство без административного контроля над людьми. Scrum Master не обязан быть руководителем команды по должности и не должен превращаться в «менеджера, который следит, все ли заняты».

Его работа обычно проявляется в трёх направлениях.

Работа со Scrum Team

Scrum Master помогает команде:

развивать самоуправление и кросс-функциональность;
фокусироваться на создании ценных Increment, соответствующих Definition of Done;
выявлять и устранять препятствия прогрессу;
проводить Scrum-события продуктивно и в установленных временных рамках.

Важно: Scrum Master способствует устранению препятствий, но не обязан лично решать каждую проблему. Если команда не может получить доступ к тестовому стенду, Scrum Master помогает сделать препятствие прозрачным, найти владельцев, организовать эскалацию и улучшить системный процесс. Но техническое решение может оставаться за Developers, а приоритетная развилка — за Product Owner.

Работа с Product Owner

Scrum Master помогает Product Owner:

эффективнее формировать и доносить Product Goal;
улучшать управление Product Backlog;
делать элементы бэклога достаточно ясными и компактными;
применять эмпирическое планирование в условиях неопределённости;
выстраивать продуктивное взаимодействие со стейкхолдерами.

Это не значит, что Scrum Master становится аналитиком или заместителем Product Owner. Он помогает создать условия, в которых Product Owner может качественно выполнять свою подотчётность.

Работа с организацией

Многие препятствия лежат за пределами одной команды: длительные согласования безопасности, отсутствие среды для тестирования, конфликтующие KPI, зависимость от внешнего поставщика, обязательные ручные операции перед релизом. Scrum Master помогает организации увидеть эти ограничения и работать с ними.

Scrum Essentials in Under 10 Minutes

Посмотрите короткий фрагмент «Scrum Essentials in Under 10 Minutes» от Scrum Alliance. Он компактно связывает состав Scrum Team с тремя ключевыми подотчётностями.

Посмотрите Scrum Team. Обратите внимание на три формулировки: Developers создают работающий результат, Product Owner оптимизирует ценность и управляет Product Backlog, Scrum Master повышает эффективность команды через корректное применение Scrum.

Как эти подотчётности работают вместе: пример из кредитной платформы

Представим задачу: снизить число заявок на автокредит, которые пользователи бросают после этапа загрузки документов.

У Product Owner есть данные аналитики и обратная связь от операторов. Он формулирует продуктовую цель и упорядочивает возможные решения: сохранение черновика, подсказки по форматам документов, сокращение числа полей, информирование о статусе проверки. Его подотчётность — не в том, чтобы заранее назначить разработчика на каждую историю, а в том, чтобы команда работала над наиболее ценным следующим шагом.

Developers исследуют текущий пользовательский путь, проверяют технические ограничения, обсуждают критерии качества и формируют реалистичный план на Sprint. Они могут обнаружить, что функция сохранения черновика требует шифрования части данных, изменений в модели хранения и дополнительного мониторинга. Это не «сопротивление бизнесу», а необходимая профессиональная информация для создания действительно готового результата.

Scrum Master наблюдает не за личной загрузкой людей, а за тем, способна ли команда эффективно достигать цели. Например, он может заметить, что на Sprint Planning команда постоянно приходит с неясными элементами бэклога, или что каждое решение по безопасности ожидает согласования две недели. В первом случае нужно улучшить взаимодействие Product Owner и Developers до начала Sprint. Во втором — сделать зависимость видимой и работать с организационным препятствием.

В результате зоны подотчётности можно выразить так:

Product Owner: «Мы уверены, что делаем наиболее ценное следующее?»
Developers: «Можем ли мы создать качественный Increment и как именно это сделаем?»
Scrum Master: «Помогает ли наш способ работы эффективно достигать цели и применять Scrum?»
Вся Scrum Team: «Создали ли мы полезный и пригодный к использованию Increment?»

Где здесь Project Manager или Technical Project Manager

Scrum не определяет отдельную подотчётность Project Manager. Поэтому наличие PM в компании не отменяет Product Owner, Scrum Master и Developers и не даёт оснований забрать их решения в одну управленческую роль.

В большой среде, особенно с интеграциями, миграциями, внешними поставщиками и несколькими командами, Technical Project Manager часто ведёт работу, которая находится вокруг или между Scrum Teams:

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

Но необходимо явно договориться о границах. Например, TPM может организовать интеграционный план и подсветить риск задержки партнёрского API, но не должен в одностороннем порядке менять порядок Product Backlog вместо Product Owner или распределять технические задачи вместо Developers.

Для команды из 30 человек это различие особенно практически значимо. Scrum Guide рекомендует небольшой размер Scrum Team, обычно не более 10 человек. Если над одним продуктом работает несколько команд, им могут быть нужны общая Product Goal, единый Product Backlog и один Product Owner, но каждая команда всё равно должна сохранять способность самостоятельно создавать результат. Центральная координация полезна для зависимостей, но не должна заменять самоуправление каждой команды.

Антипаттерны и корректирующие действия

Антипаттерн	Что нарушается	Что изменить
Product Owner передаёт приоритеты как мнение «комитета»	Нет единого владельца продуктовых решений	Зафиксировать полномочия PO и прозрачный способ учёта интересов стейкхолдеров
Scrum Master ведёт только календарь и протоколы	Теряется подотчётность за эффективность Scrum Team	Использовать наблюдения о препятствиях, качестве взаимодействия и способе работы для улучшений
Технический лидер или PM раздаёт задачи Developers	Нарушается самоуправление команды	Developers сами формируют Sprint Backlog и договариваются о распределении работы
Developers принимают в Sprint элементы, которые им непонятны	Команда планирует без достаточной прозрачности и создаёт риск срыва цели	Уточнять элементы бэклога до планирования, открыто фиксировать неопределённость и зависимости
Product Owner определяет техническое решение без обсуждения с Developers	Игнорируются качество, реализуемость и технические риски	Обсуждать ожидаемый результат и ограничения совместно, оставляя выбор реализации Developers
Scrum Master скрывает системные проблемы, «чтобы не беспокоить руководство»	Препятствия становятся хроническими	Делать препятствия прозрачными, определять владельца и срок следующего действия

Итоги

В Scrum важны не названия должностей, а ясные подотчётности за результат:

Product Owner максимизирует ценность продукта и подотчётен за эффективное управление Product Backlog.
Developers создают пригодный к использованию Increment, планируют работу внутри Sprint, поддерживают качество и ежедневно адаптируют свой план.
Scrum Master подотчётен за эффективность Scrum Team и помогает команде, Product Owner и организации корректно применять Scrum.
Вся Scrum Team совместно отвечает за создание ценного, полезного Increment в каждом Sprint.

На практике сильная Scrum Team не устраняет конфликты интересов автоматически. Она делает их видимыми и направляет к правильному владельцу решения: вопросы ценности — к Product Owner, способы реализации — к Developers, а проблемы эффективности работы и организационные барьеры — в фокус Scrum Master.

В следующем уроке разберём Scrum-события как регулярные циклы прозрачности, инспекции и адаптации: зачем нужны Sprint Planning, Daily Scrum, Sprint Review и Sprint Retrospective — и почему это не просто набор обязательных встреч.