PMP vs Scrum Master vs Agile Coach: Какой тест выбрать

Три роли, три разных сигнала

PM руководит на уровне организации. Scrum Master коучит один коллектив. Agile Coach помогает организациям масштабировать фреймворки. Они используют общую лексику, но требуют совершенно разных навыков. Однако большинство команд оценивают их одинаково — или хуже, путают роль.

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

Три роли определены

Project Manager

Отвечает за результат конкретного проекта или инициативы. Имеет полномочия (или может их получить) для распределения ресурсов, принятия решений о компромиссах и координации между командами. Отвечает за сроки, объём и часто бюджет.

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

Scrum Master

Коучит один agile коллектив. Убирает препятствия, проводит церемонии, помогает коллективу улучшить его процесс. Не имеет полномочий над продуктом или наймом; это задача product owner и лида команды.

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

Agile Coach

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

Ключевое суждение: «Организация имеет три коллектива, использующих разные практики оценки. Предложу общую таксономию, пилоту с одним коллективом, если работает, разверну на всех трёх».

Почему традиционный PMP не подходит для Scrum Master

Project Management Professional (PMP) сертификация тестирует предсказуемое планирование, управление рисками, контроль затрат и интеграцию заинтересованных лиц на всём жизненном цикле проекта. Она предполагает, что PM имеет полномочия и определённый объём.

Работа Scrum Master другая: убирай блокеры для одного коллектива, улучшай скорость итераций, проводи церемонии. У них нет полномочий переназначать ресурсы или менять объём продукта. PMP учит неправильную модель мышления.

Если вы нанимаете PMP для роли Scrum Master: Они захотят контролировать объём, будут спорить с product owner, попытаются предсказать то, что нельзя предсказать в agile работе.

Если вы нанимаете Scrum Master для роли PM: Они будут облегчать дискуссии, но не принимать решения. Спросят команду «как нам с этим справиться?», когда должны решать сами.

Оценка по ролям

Для Project Manager: Принятие решений + ориентирование в политике

Тестируйте то, что важно:

1. Сценарий-проблема (30 мин): Могут ли они принять чёткое решение о компромиссах в условиях ограничений?
2. Проблема приоритизации (20 мин): Могут ли они различить важное от срочного и защитить ранжирование?
3. Оценка риска (15 мин): Могут ли они выявить межкомандные зависимости и смягчить их заранее?
4. Поведенческое интервью (30 мин): Ориентировались ли они в политике, переустанавливали ожидания, сообщали плохие новости?

Планка найма: Балл 4+ по принятию решений и риск-суждению. Балл 3,5+ по влиянию на заинтересованных лиц. Ниже по церемониям или знанию процесса.

Для Scrum Master: Коучинг команды + дизайн процесса

Тестируйте то, что важно:

1. Проблема препятствий (20 мин, живая): «Ваша команда медленна в стендапах, уточнение хаотично, два инженера конфликтуют по цели спринта. Что вы делаете?»

   • Высокий сигнал: Сначала уточняющие вопросы («Что означает медленно — мы разговариваем 45 минут, когда должны 15?»). Предложите конкретные вмешательства, привязанные к проблеме. Не предполагайте, что можете уволить кого-то или исключить члена команды.
   • Низкий сигнал: «Улучшу общение» или «Буду проводить лучшие церемонии».

2. Ответ на ретроспективу (15 мин, живая): «Ваша команда провела ретро и выявила, что их блокирует API другой команды. Они разочарованы. Как вы им помогаете двигаться дальше?»

   • Высокий сигнал: «Помогу им сформулировать конкретное препятствие, потом организую сессию с лидом другой команды, чтобы разблокировать». (Владение через влияние, не полномочия.)
   • Низкий сигнал: «Эскалирую» или «Скажу им просто обойти это».

3. Поведенческое интервью (30 мин): Коучили ли они людей, разрешали конфликты в команде, гнали улучшения процесса?

   • Хорошие примеры: «Заметил, что команда неправильно оценивает размер истории, провел сессию по story pointing и заметил, что мы стали намного быстрее».
   • Плохие примеры: «Рассказал команде следовать Scrum фреймворку» или «Эскалировал проблему PM».

Планка найма: Балл 4+ по коучингу и эмпатии. Балл 3,5+ по дизайну процесса. Ниже по стратегическому мышлению или влиянию на уровне организации.

Для Agile Coach: Организационный дизайн + облегчение

Тестируйте то, что важно:

1. Проблема масштабирования (30 мин, живая): «Организация имеет четыре коллектива. Два используют Scrum, один Kanban, один использует кастомный waterfall-agile. Они выпускают на разных циклах, и лидерству сложно отслеживать прогресс между коллективами. Как вы их помогаете выравниться?»

   • Высокий сигнал: «Сначала пойму, почему каждый коллектив выбрал свой подход (разные типы продуктов? разное лидерство? разная зрелость?). Потом предложу общий кадент — не общий фреймворк — чтобы все коллективы проверяли прогресс каждые две недели. Это даёт лидерству отслеживание между коллективами при уважении автономии на уровне коллектива».
   • Низкий сигнал: «Скажу им всем использовать Scrum» или «Это сложно».

2. Разрешение конфликта (15 мин, живая): «PM хочет, чтобы коллектив обязался на дату. Scrum Master говорит, что вы не можете обязаться в agile, только прогнозировать. Как вы мост наводите?»

   • Высокий сигнал: «Разделю задачи: можем сделать план ёмкости (прогноз), и отдельно можем выявить риски бизнеса и встроить буфер в план (обязательство). PM получает дату для использования с клиентами; коллектив получает реалистичные ожидания».
   • Низкий сигнал: «Agile не делает обязательства» или «PM нужно учить agile».

3. Поведенческое интервью (30 мин): Гнали ли они организационные изменения, масштабировали фреймворки, разрешали конфликты между коллективами?

   • Хорошие примеры: «Два коллектива имели несовместимые определения готовности, что блокировало handoffs. Провёл рабочую группу, чтобы определить стандарт, пилотировал с одним коллективом, потом разверну на всех».
   • Плохие примеры: «Обучил людей agile» или «Создал документ процесса».

Планка найма: Балл 4+ по организационному мышлению и управлению изменениями. Балл 3,5+ по облегчению. Ниже по практическому коучингу команды.

Частые ошибки найма

Ошибка 1: Публикация на роль «Project Manager/Scrum Master». Это разные работы. Если вы строите маленький коллектив, вам нужен Scrum Master, не PM. Если вы выпускаете большую инициативу, вам нужен PM.

Ошибка 2: Использование одной оценки для всех трёх ролей. PM должны быть протестированы на принятие решений. Scrum Master на коучинг. Agile Coach на системное мышление. Переиспользование одного теста — как оценивать инженеров и дизайнеров одинаково.

Ошибка 3: Перевес на сертификации. PMP, CSM, и CAL хорошо показывают, что кто-то учил фреймворки. Они не показывают суждение. Если кто-то говорит «у меня есть PMP, значит я могу управлять всем», будьте скептичны. Тестируйте их на роль, которая у вас на самом деле есть.

Матрица сравнения

Как выбрать, какая роль вам нужна

Вам нужен Project Manager если: Вы запускаете новый продукт, интегрируете два коллектива или выпускаете инициативу, охватывающую несколько коллективов с жёстким дедлайном.

Вам нужен Scrum Master если: У вас есть один коллектив, который страдает с исполнением спринта, уточнением или конфликтами внутри коллектива.

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

Многие организации нанимают PM и Scrum Master. Оба полезны, но разные. Оценивайте их по-разному, нанимайте на разные сильные стороны, устанавливайте разные метрики успеха.