Три ответственности: Product Owner, Scrum Master, Developers

В предыдущей статье — https://courses.digitable.life/post/scrum-master/02-scrum-guide/ — мы прочитали Scrum Guide построчно. Теперь возьмём самую конфликтную его часть: людей. Не потому, что она сложная в тексте (там всего полторы страницы), а потому, что именно здесь Scrum сталкивается с реальной оргструктурой компании, где уже есть проектные менеджеры, тимлиды, аналитики и «главные по качеству». Экзамен PSM I проверяет эту тему жёстко: около трети вопросов так или иначе крутится вокруг того, кто за что отвечает и кто чего делать не должен.

Проблема, которую решают три ответственности

Представьте команду из восьми человек без явных ответственностей. Что происходит?

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

Решения о «как» принимаются снаружи. Архитектор из соседнего отдела говорит, что надо использовать шину сообщений. Тимлид уже пообещал заказчику дату. Команда, которая будет это делать и потом сопровождать, узнаёт о решении последней — и не чувствует ответственности за результат.

Никто не отвечает за то, что процесс работает. Дейли превратилось в отчёт менеджеру, ретроспективы отменили «из-за загрузки», Definition of Done нигде не записан. Каждый отдельный человек видит проблему, но чинить её — ничья работа.

Три ответственности Scrum — это ответ ровно на эти три провала. Одна ответственность за ценность продукта, одна за создание инкремента, одна за работоспособность самого способа работы. Между ними нет иерархии: это не начальник, зам и подчинённые, а три разных предмета отчётности.

Accountability, а не role: почему это не придирка к словам

В версии Scrum Guide 2020 слово role («роль») исчезло. Осталось accountability — «ответственность, за которую спросят». Это не косметика, и на экзамене формулировки подобраны так, чтобы разницу поймать.

Role — это набор занятий: «Product Owner пишет пользовательские истории», «Scrum Master ведёт дейли». Если понимать так, то первый же вопрос «а можно ли, чтобы истории писал аналитик?» ставит в тупик.

Accountability — это предмет спроса. Product Owner отвечает за то, что продукт приносит ценность. Кто физически напишет текст истории — вопрос второй; Scrum Guide прямо разрешает делегировать работу, но подчёркивает: ответственность остаётся на Product Owner. То же и с Developers: они отвечают за качество инкремента, а не за то, что каждый из них лично написал код.

Так написано в Scrum Guide: «The Product Owner may do this work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.» — Scrum Guide 2020, The Product Owner

Практический вывод: не спрашивайте «кто это делает». Спрашивайте «с кого спросят, если это не сделано». Первый вопрос порождает споры о должностных инструкциях, второй — проясняет структуру.

Scrum Team как целое: рамка, в которой живут три ответственности

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

• Scrum Team — одна команда: один Product Owner, один Scrum Master и Developers. Обычно 10 человек или меньше суммарно. Не «10 разработчиков плюс PO и SM».
• Внутри нет подкоманд и иерархий. Никаких «команды фронтенда» и «команды QA» внутри одной Scrum-команды.
• Команда самоуправляемая (self-managing): сама решает кто, что и как делает. В 2020 году формулировку сменили с self-organizing именно чтобы подчеркнуть: команда управляет и своей работой, а не только организуется внутри чужого плана.
• Команда кросс-функциональная: у неё есть все навыки, чтобы создавать ценность каждый спринт, не бегая за согласованиями наружу.
• Команда отвечает за все продуктовые активности: исследование, проектирование, разработку, тестирование, эксплуатацию — за всё, что нужно, чтобы был работающий инкремент.
• Один Product Backlog, одна Product Goal, одна Sprint Goal, один инкремент за спринт.

Отсюда важный тезис, который экзамен любит проверять: ответственность за то, что за спринт получился рабочий инкремент, лежит на всей Scrum-команде. Developers создают инкремент, но провал спринта — это не «косяк разработчиков», а событие для всей команды.

Product Owner: ответственность за ценность

Одна фраза Руководства: Product Owner accountable for maximizing the value of the product resulting from the work of the Scrum Team. Ценность — не объём выпущенных фич, а то, зачем этот продукт вообще существует.

Конкретная зона отчётности — Product Backlog Management, а это четыре вещи:

1. Разработать и явно сообщить Product Goal. Не «дорожная карта на год», а формулировка следующего значимого состояния продукта.
2. Создавать и явно доносить элементы Product Backlog. «Явно» — ключевое слово: элемент, смысл которого понятен только его автору, не выполняет свою функцию.
3. Упорядочивать элементы бэклога. Не «расставлять приоритеты по важности», а именно создавать линейный порядок: что делается раньше, что позже.
4. Обеспечивать, чтобы бэклог был прозрачным, видимым и понятным.

Дальше — три ограничения, которые вырезаны в камне:

• Product Owner — один человек, а не комитет. Комитет может влиять на его решения, но решает и отвечает один. Хотите изменить порядок бэклога — убеждайте Product Owner.
• Решения Product Owner видны в содержании и порядке Product Backlog и в инкременте, который команда показывает на обзоре. Это и есть механизм подотчётности: не отчёт начальнику, а публичная прозрачность.
• Чтобы Product Owner работал, организация должна уважать его решения. Никто — включая генерального директора — не может напрямую сказать Developers работать по другому набору требований.

Ещё два факта, которые почти гарантированно встретятся на экзамене:

• Отменить спринт может только Product Owner. Причина отмены одна: Sprint Goal устарел. Не «команда не успевает», не «поменялись люди».
• Product Owner решает, выпускать ли инкремент. Инкремент может быть готов по Definition of Done, но выйти к пользователям позже — это нормально и это решение Product Owner.

Что ломается без сильного Product Owner

Антипаттерн «PO-диспетчер» (proxy PO). Настоящий заказчик — где-то наверху, а внутри команды сидит человек, который переносит его пожелания в Jira. У такого «Product Owner» нет мандата сказать «нет» и нет ответственности за результат. Команда быстро понимает, что переговоры бесполезны, и переключается в режим исполнителя.

Антипаттерн «PO-комитет». Приоритеты определяются на еженедельном совещании руководителей. Формально Product Owner есть, фактически он секретарь. Решения меняются между спринтами, потому что у решений нет одного владельца.

Что делать Scrum-мастеру. Не «жаловаться на PO». Работать с двумя вещами: во-первых, делать видимой цену проблемы (сколько раз за квартал приоритет менялся посреди спринта и сколько работы это выбросило), во-вторых, добиваться у руководства явного мандата: у одного человека есть право сказать «нет» — и это право защищено. Подробнее про переговоры с организацией — в статье https://courses.digitable.life/post/scrum-master/08-coaching-and-conflicts/.

Developers: ответственность за инкремент

Developers — это все, кто создаёт любой аспект пригодного к использованию инкремента. Не «программисты». Тестировщик, дизайнер, аналитик, DevOps-инженер, технический писатель — если человек участвует в создании инкремента, он Developer в терминах Scrum. Никаких титулов внутри команды Scrum Guide не признаёт.

Их отчётность — ровно четыре пункта:

1. Создание плана на спринт — Sprint Backlog. План принадлежит Developers. Никто снаружи не наполняет Sprint Backlog.
2. Внедрение качества через следование Definition of Done. Качество не «обеспечивается отделом тестирования», оно встроено в определение готовности.
3. Ежедневная адаптация плана в направлении Sprint Goal. Это и есть смысл Daily Scrum.
4. Взаимная требовательность как профессионалов. Не Scrum Master приходит и спрашивает «почему задача висит третий день» — это делают сами Developers.

Из этого следуют вещи, которые в обычной компании звучат почти революционно:

• Сколько работы взять в спринт — решают Developers. Не Product Owner, не менеджер. Product Owner может объяснить, почему ему важно больше, — но не может назначить объём.
• Оценку даёт тот, кто будет делать работу. Оценка, спущенная сверху, — это не оценка, а обязательство, к которому исполнитель не имеет отношения. Про техники оценки — https://courses.digitable.life/post/scrum-master/06-product-backlog/ и, шире, https://courses.digitable.life/post/project-management/03-estimation-and-planning/.
• Внутри спринта Sprint Backlog меняется свободно. Developers обнаружили, что нужен ещё один шаг, — добавили. Неизменен только Sprint Goal.
• Технические решения принимает команда. Внешний архитектор может консультировать, устанавливать ограничения на уровне организации — но не проектировать за команду.

Что ломается без самоуправления Developers

Классика: скрытая иерархия. Формально команда самоуправляемая, фактически тимлид раздаёт задачи на дейли. Симптомы легко заметить: люди на планировании смотрят на одного человека и молчат; в Sprint Backlog у каждого «своя» задача и никто не смотрит в чужие; на ретроспективе обсуждают только то, что разрешено обсуждать.

Второй вариант: подкоманды внутри команды. Аналитики делают спецификации в спринте N, разработчики пишут код в N+1, тестировщики проверяют в N+2. Формально Scrum-события есть, фактически это водопад с шагом в две недели — то, что называется мини-водопадом (разбор — в https://courses.digitable.life/post/scrum-master/10-antipatterns/). Диагностика простая: посмотрите, есть ли в конце спринта инкремент, соответствующий Definition of Done. Если готовность наступает через два спринта после начала работы — у вас подкоманды.

Scrum Master: ответственность за то, что всё это работает

Формулировка Руководства двойная, и обе половины важны:

Так написано в Scrum Guide: Scrum Master «is accountable for establishing Scrum as defined in the Scrum Guide» и «is accountable for the Scrum Team’s effectiveness». — Scrum Guide 2020, The Scrum Master

Первая половина — про внедрение Scrum: помогать всем понять теорию и практику как внутри команды, так и в организации. Вторая — про эффективность команды: помогать ей улучшать свои практики в рамках фреймворка.

Scrum Guide описывает Scrum-мастера как true leader who serves — лидера, который служит. Служение развёрнуто на три контура, и мы уже видели их в https://courses.digitable.life/post/scrum-master/00-overview/:

Отдельно стоит запомнить то, что Руководство говорит явно:

• Scrum Master отвечает за то, чтобы события проходили, были позитивными, продуктивными и укладывались в тайм-бокс.
• Scrum Master устраняет препятствия — но «устраняет» здесь чаще означает «делает видимыми и добивается решения на нужном уровне», а не «сам чинит».
• Scrum Master обучает Developers самоуправлению и кросс-функциональности.
• Scrum Master помогает Product Owner с техниками формулирования Product Goal, управления бэклогом и выстраивания работы со стейкхолдерами.
• Scrum Master работает с организацией: обучает, снимает барьеры между командами и стейкхолдерами.

Чего Scrum Master не делает

Здесь набор самых частых ловушек на экзамене и в жизни:

• Не назначает задачи. Ни на планировании, ни на дейли.
• Не является менеджером Developers. Не проводит performance review как часть роли, не решает вопросы найма и увольнения от лица Scrum.
• Не ведёт Daily Scrum. Daily Scrum — событие Developers. Scrum Master обеспечивает, что оно происходит и укладывается в 15 минут; он может даже не присутствовать.
• Не отвечает за содержание бэклога и не решает за Product Owner.
• Не «менеджер команды по процессам», который вместо команды заполняет доску и пишет отчёты о статусе.

Так делают на практике (и это допустимо): Scrum Master фасилитирует планирование, обзор и ретроспективу, ведёт разговор о препятствиях с руководителями, помогает Product Owner готовить структуру бэклога. Всё это — служение, а не управление.

Так делать не стоит: быть «секретарём доски». Признак — если Scrum Master уходит в отпуск и процесс разваливается, значит он не построил самоуправление, а подпёр его собой. Хорошая метрика зрелости от обратного: чем меньше команде нужен Scrum-мастер в повседневности, тем лучше он сработал.

Карта прав решения

Соберём всё вместе. Эту схему полезно повесить рядом с доской команды: девять из десяти споров о границах снимаются взглядом на неё.

Обратите внимание на нижние две строки: Sprint Goal и Definition of Done не принадлежат никому лично — это работа всей Scrum-команды. Sprint Goal формулируется на планировании совместно; Definition of Done создаётся командой, если в организации нет собственного стандарта, а если стандарт есть — команда обязана следовать ему как минимуму и может сделать строже. Подробнее — в https://courses.digitable.life/post/scrum-master/05-artifacts/.

Практическая эвристика для маршрутизации любого вопроса:

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

Куда деваются привычные должности

Самый частый вопрос на внедрении: «а куда денется наш проектный менеджер / тимлид / аналитик?» Ответ: должность в оргструктуре может остаться, но её функции раскладываются по трём ответственностям, а часть просто исчезает.

Важные уточнения:

• Scrum Guide ничего не говорит про должности в компании. Он описывает ответственности внутри Scrum-команды. Человек может иметь должность «ведущий разработчик» в HR-системе и быть Developer в Scrum-команде — противоречия нет.
• Совмещение ответственностей формально не запрещено, кроме одного случая: Product Owner — один человек. Но совмещение Scrum Master + Product Owner на практике почти всегда плохо: у этих ответственностей конфликтующие оптимизации (успеть больше ценности против устойчивого темпа и здоровья процесса). Если совмещать приходится — сделайте конфликт явным для команды.
• Отчётность о статусе перед менеджментом растворяется в прозрачности. Не нужен еженедельный отчёт, если инкремент показывают на обзоре спринта, а бэклог открыт.

Три сценария из жизни и разбор

Сценарий 1: стейкхолдер приходит напрямую к разработчику

Середина спринта. Руководитель отдела продаж пишет разработчику в мессенджер: «Сделай, пожалуйста, маленькую правку в отчёте, это на полчаса, клиент завтра смотрит». Разработчик делает.

Что здесь не так. Не «разработчик нарушил правило». Проблема системная: у стейкхолдера нет работающего канала, поэтому он идёт коротким путём. Полчаса — не беда; беда — что таких «получасов» в спринте набирается тридцать процентов ёмкости, и никто не понимает, почему команда «медленная».

Что делает Scrum Master. Не ставит запрет и не идёт ругаться со стейкхолдером. Делает невидимое видимым: заводит счётчик незапланированной работы и приносит цифру на ретроспективу и обзор. Дальше помогает Product Owner выстроить канал, в котором срочное решается быстро, но осознанно. Про измерение таких вещей — https://courses.digitable.life/post/scrum-master/09-empiricism-and-metrics/.

Сценарий 2: Product Owner требует взять больше работы

На планировании Product Owner говорит: «В прошлый раз вы сделали восемь историй, значит в этот раз возьмите двенадцать, релиз горит».

Разбор. Объём берут Developers. Это не предмет для голосования и не компромисс «давайте десять». Но и просто сказать «нет» — плохо: за требованием стоит реальная проблема с датой.

Что делает Scrum Master. Помогает разделить два вопроса, которые смешались:

1. Сколько мы можем сделать — отвечают Developers, и ответ не меняется от давления.
2. Что нам сделать в первую очередь, если времени мало — отвечает Product Owner, и здесь простор огромный: сузить скоуп историй, отложить второстепенное, найти более дешёвую гипотезу.

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

Сценарий 3: команда просит Scrum-мастера «просто решить»

Два разработчика третью неделю спорят, какую библиотеку взять. Приходят к Scrum-мастеру: «Решите вы, вам виднее со стороны».

Разбор. Технические решения принадлежат Developers. Приняв решение, Scrum Master на неделю снимет напряжение — и навсегда закрепит паттерн «спорные вопросы решает Scrum-мастер». В следующий раз к нему придут с более крупным решением.

Что делает Scrum Master. Отдаёт решение обратно вместе с механизмом: помогает сформулировать критерии выбора, предлагает ограничить спор экспериментом (сделать прототип на обеих библиотеках в рамках одного дня), задаёт срок принятия решения. Предмет работы Scrum-мастера — не выбор библиотеки, а то, что команда три недели не умела закрывать спор. Инструменты для этого — в https://courses.digitable.life/post/scrum-master/07-facilitation/.

Антипаттерны трёх ответственностей на одной картинке

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

Читать так: правый край — вмешательство в чужую ответственность, нижний левый угол — отказ от собственной. Здоровый Product Owner сдвинут вправо законно: содержание продукта — его предмет. Здоровый Scrum Master держится левее: он активен, но его активность направлена на способ работы, а не на содержание.

Жизненный цикл отношений Scrum-мастера с командой

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

Главная ошибка новичка — застрять в режиме «Обучение» навсегда: команда уже всё знает, а Scrum-мастер продолжает объяснять правила и напоминать про дейли. Вторая частая ошибка — прыгнуть сразу в «Коучинг» с командой, которая ещё не понимает базовых правил: вопросы вместо ответов в такой ситуации выглядят издевательством.

Вопросы в формате PSM I с разбором

Экзаменационные вопросы намеренно опираются на точные формулировки Руководства. Тренируйте привычку: сначала вспомнить текст, потом уже здравый смысл.

Вопрос 1. Кто отвечает за то, что элементы Product Backlog понятны команде?

• A. Developers
• B. Product Owner
• C. Scrum Master
• D. Бизнес-аналитик

Правильный ответ: B. Product Owner отвечает за прозрачность, видимость и понятность Product Backlog. Ловушка в том, что понятность «проверяется» на стороне Developers — но отчётность за неё лежит на Product Owner. Вариант D вообще вне Scrum: такой ответственности во фреймворке нет.

Вопрос 2. Кто определяет, сколько элементов Product Backlog войдёт в спринт?

• A. Product Owner
• B. Scrum Master
• C. Developers
• D. Совместное решение большинством голосов Scrum-команды

Правильный ответ: C. Только Developers определяют объём: они выполняют работу и они же отвечают за инкремент. Вариант D выглядит «командно» и потому соблазнителен, но Scrum не использует голосование для этого решения. Product Owner влияет через порядок бэклога и объяснение целей — не через объём.

Вопрос 3. Product Owner в отпуске две недели, спринт начинается завтра. Что делать?

• A. Отложить спринт до возвращения Product Owner
• B. Scrum Master выполняет обязанности Product Owner на время отпуска
• C. Product Owner должен обеспечить, чтобы его ответственность была закрыта — например, делегировав работу, но оставаясь accountable
• D. Developers сами выбирают, что делать, и спринт идёт как обычно

Правильный ответ: C. Работа может быть делегирована, ответственность — нет. Вариант A нарушает непрерывность спринтов, B создаёт конфликт ответственностей, D оставляет продукт без владельца ценности.

Вопрос 4. Кто отвечает за управление ходом Daily Scrum?

• A. Scrum Master
• B. Product Owner
• C. Developers
• D. Наиболее опытный член команды

Правильный ответ: C. Daily Scrum — событие Developers, и они же им управляют. Scrum Master учит команду укладываться в тайм-бокс и обеспечивает, что событие происходит, но вести его не обязан и может не присутствовать. Вариант D противоречит отсутствию иерархий внутри команды.

Вопрос 5. Спринт идёт пятый день из десяти. Sprint Goal явно потерял смысл: конкурент выпустил функцию, ради которой всё затевалось. Кто может отменить спринт?

• A. Scrum Master
• B. Developers большинством голосов
• C. Product Owner
• D. Стейкхолдер, который финансирует разработку

Правильный ответ: C. Отменить спринт может только Product Owner, и единственная причина — устаревание Sprint Goal. Это ровно тот случай. Обратите внимание: он может отменить, а не обязан.

Вопрос 6. Организация решила, что каждая Scrum-команда должна отчитываться менеджеру проекта о ходе спринта еженедельно. Как должен поступить Scrum-мастер?

• A. Организовать еженедельный отчёт, это требование организации
• B. Запретить команде участвовать в отчётах, это противоречит Scrum
• C. Работать с организацией: объяснить, какие потребности закрывает отчёт, и показать, как их закрывают прозрачные артефакты и обзор спринта
• D. Делать отчёты самостоятельно, чтобы не отвлекать команду

Правильный ответ: C. Ответственность Scrum-мастера включает работу с организацией: помогать понять эмпирический подход и снимать барьеры. Вариант B — конфронтация без работы с причиной, D — подпорка, которая маскирует проблему и превращает Scrum-мастера в администратора.

Мини-итог и чеклист

Что стоит унести из статьи:

• Accountability ≠ должность. Вопрос всегда «с кого спросят за результат», а не «кто выполняет работу».
• Product Owner отвечает за ценность, один человек, решения уважаются, отменяет спринт только он.
• Developers отвечают за инкремент: свой план, свой объём, своё качество через Definition of Done, взаимная требовательность.
• Scrum Master отвечает за внедрение Scrum и эффективность команды — служением, а не управлением; ни одно решение внутри чужой ответственности он не забирает.
• Sprint Goal и Definition of Done принадлежат всей команде, а не кому-то одному.
• Границы нужны не ради чистоты фреймворка, а потому что каждая размытая граница через месяц превращается в конкретную дисфункцию: скрытая работа, неучтённые приоритеты, команда-исполнитель.

Чеклист для быстрой диагностики команды:

• Есть ли один человек, который может сказать стейкхолдеру «нет» и его решение устоит?
• Кто-нибудь вне Developers определяет объём спринта?
• На дейли команда разговаривает друг с другом или отчитывается кому-то?
• Появляется ли в спринте работа, которой нет в Sprint Backlog?
• Есть ли внутри команды подкоманды по специализациям?
• Что сломается, если Scrum-мастер уйдёт на две недели?

Источники

• The Scrum Guide 2020 — первоисточник, разделы Scrum Team, Product Owner, Developers, Scrum Master. Читать в оригинале.
• Scrum.org: What is a Scrum Master? и What is a Product Owner? — официальные разъяснения от организации, которая проводит PSM I.
• Professional Scrum Competencies — карта компетенций, полезна для планирования собственного развития.
• Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process — главы про роли, с подробным разбором совмещений и типичных искажений.
• Geoff Watts. Scrum Mastery: From Good to Great Servant-Leadership — про поведение Scrum-мастера на разных стадиях зрелости команды.
• Обзорный материал портала: https://courses.digitable.life/post/project-management/01-agile-and-scrum/ — Scrum в контексте других подходов к управлению; https://courses.digitable.life/post/management/task-delegation/ — про делегирование как управленческую практику вне Scrum.

Что дальше

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

События Scrum: спринт, планирование, дейли, обзор, ретроспектива