Роли в Scrum: Product Owner, Scrum-мастер, команда

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

Три роли вместо иерархии

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

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

Это не оргструктура, а распределение полномочий. Тимлид, аналитик или менеджер по-прежнему могут существовать в компании — просто внутри спринта они играют одну из трёх scrum-ролей. Подробнее о том, как устроен сам спринт, читайте в материале что такое спринт.

Владелец продукта (Product Owner)

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

Что входит в зону ответственности:

• Формулировать и доносить цель продукта и цель спринта.
• Вести и приоритизировать бэклог продукта — список того, что нужно сделать.
• Объяснять команде, зачем нужна каждая фича (контекст, а не только задача).
• Принимать или отклонять результат по критериям готовности.
• Общаться со стейкхолдерами и балансировать их запросы.

Хороший Product Owner думает приоритетами, а не сроками: он не говорит «сделайте всё к пятнице», он говорит «вот это важнее остального, начните с него». Для формализации приоритетов и измеримых целей помогают OKR, а для понимания, кто за какие решения отвечает вне команды — матрица RACI.

Scrum-мастер

Scrum-мастер отвечает за процесс и за то, чтобы команда работала эффективно. Это не менеджер и не «старший по статусу» — это служащий лидер, который убирает препятствия и защищает команду от перегрузки и хаоса.

Что делает scrum-мастер на практике:

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

Ключевой признак сильного scrum-мастера — со временем команда нуждается в нём всё меньше. Он не контролирует, а выращивает самостоятельность. Если scrum-мастер раздаёт задачи и спрашивает статусы — это уже не scrum-мастер, а замаскированный руководитель.

Команда разработки (Developers)

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

Команда самоорганизуется и кросс-функциональна — то есть внутри неё есть все навыки, чтобы довести задачу до готового результата без передачи «через стену» в другой отдел. Что входит в их ответственность:

• Самостоятельно решать, сколько работы взять в спринт.
• Декомпозировать задачи и планировать, как их сделать.
• Оценивать сложность — например, в story points.
• Поддерживать единое определение готовности (Definition of Done).
• Каждый день синхронизироваться и корректировать план.

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

Антипаттерны и совмещение ролей

Самые частые проблемы рождаются именно из размытых ролей. Вот что встречается чаще всего:

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

Про совмещение. Допустимо: один человек может быть и Product Owner, и разработчиком в маленькой команде — но это риск, потому что приоритеты и реализация начинают конфликтовать. Спорно, но иногда работает: разработчик берёт роль scrum-мастера по очереди. А вот совмещать Product Owner и scrum-мастера почти всегда плохо — это конфликт интересов: один и тот же человек и давит на объём, и должен защищать команду от давления.

Чтобы роли работали, командам нужна общая прозрачность: единый бэклог, понятный приоритет и видимость загрузки. В TeamVector это собрано в одном месте — задачи со связью с Git (GitLab), встроенный мессенджер для синхронизации без переписки в почте, загрузка команды и спринты, — так что каждая роль видит свою часть картины без ручных отчётов.

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