Scrum‑мастер — это человек, который отвечает за процесс Scrum и эффективность команды, где до результата (стабильные релизы и предсказуемые спринты) обычно доходят за 2–3 месяца настройки, но ключевой риск — когда роль превращают в «секретаря созвонов» или подменяют проектным менеджером, убивая самоорганизацию.

Почему этот вопрос вообще болит

Боитесь нанять «ещё одного менеджера», который будет гонять людей по митингам, а скорость разработки не вырастет? Нормальный страх. Scrum‑мастер и Project Manager часто выглядят одинаково на диаграмме оргструктуры: оба что-то «координируют», оба говорят с людьми, оба любят таблички. Только цель разная: у одного — система, у другого — результат проекта в срок/бюджет/объём.

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

Что делает Scrum‑мастер на самом деле (и что не делает)

Роль Scrum‑мастера: владелец процесса и системных улучшений

Тезис: Scrum‑мастер отвечает за то, чтобы Scrum работал как система: события, артефакты, договорённости, улучшения, устранение препятствий.

Практический вывод: если после появления Scrum‑мастера команда стала предсказуемее (скорость/пропускная способность стабилизируются, меньше «пожаров», улучшилась прозрачность), он делает свою работу.

Подводный камень: «Scrum‑мастер = ведущий митингов». Да, он фасилитирует. Но если вся ценность роли — поставить таймер на ретро, вы купили очень дорогой секундомер.

• Фасилитация Scrum-событий (planning, daily, review, retro) — но с целью улучшения решений, а не “провести встречу”.
• Коучинг команды в самоорганизации и кросс‑функциональности (чтобы «ждать тестировщика» было стыдно, а не привычно).
• Работа с импедиментами: системные блокеры (доступы, окружения, бюрократия), а не «Вася не отвечает в чате».
• Прозрачность: DoR/DoD, договорённости, видимость незавершёнки, работа с WIP.
• Помощь Product Owner: формулировать цель спринта, качество бэклога, управлять ожиданиями стейкхолдеров (без подмены PO).

Что Scrum‑мастер не обязан делать

• Назначать задачи разработчикам и контролировать их выполнение «по часам».
• Собирать статус‑отчёты ради отчётов.
• Быть «прорабом» команды и нести персональную ответственность за сроки релиза.
• Управлять бюджетом, контрактами, закупками, людьми (оценка эффективности, увольнения).

Project Manager в IT: зона ответственности без романтики

Роль PM: управление проектными ограничениями и поставкой результата

Тезис: Project Manager отвечает за достижение целей проекта в рамках ограничений: сроки, бюджет, объём, качество, риски, зависимости, коммуникации со стейкхолдерами.

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

Подводный камень: PM пытается «рулить командой» как ресурсами, а Scrum‑мастер делает вид, что «всё самоорганизуется». Получается война двух центров власти и ноль ответственности.

• Планирование и контроль сроков: roadmap, релизы, вехи, критический путь.
• Управление рисками и изменениями: change requests, согласования, последствия.
• Управление внешними коммуникациями: заказчик, бизнес, безопасность, юристы, бухгалтерия.
• Бюджет/контракты/ресурсы (если это классический PM): кто, сколько стоит, где взять.
• Координация межкомандных зависимостей.

Где роли пересекаются и как их развести без драмы

Матрица ответственности: кто за что отвечает

Практическое правило: «одна встреча — один владелец»

Если PM ведёт daily — команда быстро начинает отчитываться, а не синхронизироваться. Если Scrum‑мастер ведёт статус‑колл с заказчиком — заказчик начинает считать его ответственным за сроки. Поэтому фиксируем: у каждого ритуала и артефакта должен быть владелец и цель.

1. Review: команда показывает инкремент, PO собирает фидбек, PM может перевести это в решения по релизам.
2. Статус проекта: PM ведёт, Scrum‑мастер помогает не скатиться в микроменеджмент и «виноватых».
3. Ретро: только команда + Scrum‑мастер (и по приглашению). Иначе ретро становится театром.

Скрытая цена неправильного разделения ролей

Если роли смешаны, вы платите не зарплатой, а потерей пропускной способности. Типичные «расходы», которые редко попадают в бюджет:

• +20–40% времени команды на отчётность и согласования (созвоны ради созвонов).
• Падение качества прогнозов: обещания строятся на хотелках, а не на данных.
• Рост незавершёнки (WIP) и «почти готово»: вы вроде бы заняты, но релизов нет.
• Выгорание: когда команда не контролирует поток запросов, она начинает «жить в аврале».

В системном анализе образовательных инвестиций это выглядит так: компания «учит людей Agile», но не меняет контуры ответственности. ROI обучения улетает в минус, потому что проблема была не в знании Scrum, а в управленческом дизайне.

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

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

Чек‑лист: 7 вопросов перед тем, как “совместить” Scrum‑мастера и PM в одном человеке

• У вас продуктовая команда (долгоживущая) или проектная (временная, под контракт)?
• Сколько внешних стейкхолдеров и зависимостей? (Если больше 5 — PM обычно не роскошь.)
• Кто принимает решения о приоритетах: PO/бизнес или «все понемногу»?
• Какие метрики важнее: flow/predictability или сроки/бюджет? (Обычно нужны обе, но не в одной голове.)
• Есть ли Engineering Manager/тимлид, который отвечает за людей и техдолг?
• Команда умеет говорить «нет» и защищать WIP, или она живёт из входящих?
• Вы готовы к тому, что “два в одном” станет конфликтом интересов: коуч vs контролёр?

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