Собеседование с мастером гибкой разработки (Scrum Master) быстро показывает, перед вами фасилитатор для календаря встреч или человек, который умеет вытаскивать команду из заторов. Нужны вопросы про реальные случаи: сорванные спринты, спорные роли, метрики, конфликты и пользу для продукта.
Какие вопросы сразу показывают опыт кандидата
Опыт мастера гибкой разработки виден по тому, как он описывает рабочие ситуации: без общих лозунгов, с участниками, ограничениями, ошибками и итогом. Сильный кандидат говорит не про «ритуалы», а про то, что изменилось в команде после его вмешательства.
Начать разговор удобно с прошлого проекта. Не с названия компании и не с красивой должности, а с устройства команды: сколько людей было в разработке, кто ставил задачи, как часто выпускали изменения, где ломался процесс. В этих деталях обычно и лежит правда. Человек, который жил внутри команды, быстро вспоминает конфликт между владельцем продукта и разработчиками, перегруженный бэклог, странные оценки, бесконечные переносы задач. Тот, кто наблюдал со стороны, чаще уходит в лекцию о ценностях скрама.
А ведь скрам в компаниях редко выглядит как учебная схема. Где-то владелец продукта занят продажами и приходит раз в неделю. Где-то тестирование отстаёт на два спринта. Где-то руководитель отдела каждый день меняет приоритеты через личные сообщения. Поэтому вопрос должен тащить кандидата в конкретику.
- С какой самой тяжёлой проблемой в команде вы работали и чем она закончилась?
- Что вы изменили в процессе за первые два месяца на последнем проекте?
- Как команда поняла, что ваши действия дали результат?
- Какая ваша идея не сработала и почему?
- Кто чаще всего сопротивлялся изменениям и как шёл разговор?
Особенно ценен вопрос про неудачу. В нём быстро исчезает глянец. Опытный специалист не стесняется признать, что ретроспективы какое-то время были пустыми, метрики выбрали не те, а попытка поменять доску задач вызвала раздражение. Дальше он объяснит, что сделал после этого. Вот там и начинается профессиональный разговор.
Как проверить работу со спринтами, встречами и бэклогом
Мастера гибкой разработки надо спрашивать не о том, знает ли он события скрама, а о том, как он возвращает им смысл. Планирование, ежедневные встречи, обзор и ретроспектива полезны только тогда, когда помогают выпускать понятный результат и быстрее видеть проблемы.
На собеседовании часто звучит безобидная фраза: «Я вёл все церемонии». За ней может скрываться что угодно — от сильной фасилитации до пересылки приглашений в календаре. Поэтому просите разобрать один спринт по шагам. Как команда выбирала цель? Что происходило, если задач набрали слишком много? Кто резал объём? Как фиксировали договорённости? Ответы покажут, умеет ли кандидат защищать фокус команды или просто наблюдает за хаосом.
| Зона проверки | Что спросить | Что слушать в ответе |
|---|---|---|
| Планирование | Как команда решала, сколько задач брать в спринт? | Связь с целью, прошлой скоростью, рисками и доступностью людей |
| Ежедневная встреча | Что вы делали, когда встреча превращалась в отчёт начальнику? | Перенастройка разговора на препятствия, зависимости и помощь внутри команды |
| Ретроспектива | Как вы добивались действий после ретроспективы? | Один-два измеримых пункта, владелец действия, проверка на следующем цикле |
| Бэклог | Что происходило, если задачи приходили сырыми? | Работа с владельцем продукта, критерии готовности, отказ от мусорного входа |
Есть простой приём: попросите кандидата назвать один пример, когда встречу пришлось отменить или переделать. Слабый специалист держится за форму, сильный — за смысл. Если обзор спринта не даёт обратной связи от бизнеса, его формат надо менять. Если ежедневная встреча не выявляет блокеры, значит, люди не понимают, зачем пришли. И это уже зона работы мастера гибкой разработки, а не «особенность команды».
Как понять, справится ли специалист с конфликтами
Работа с конфликтами — одна из самых честных проверок мастера гибкой разработки. Он не обязан быть психологом, но обязан замечать напряжение, выводить его в рабочий разговор и не давать сильным участникам задавить остальных.
В продуктовых командах конфликт редко выглядит как громкая ссора. Чаще он прячется в молчании на планировании, сарказме на ретроспективе, вечном «мне всё равно» от разработчика или в задачах, которые возвращаются из тестирования третий раз. Здесь кандидат должен говорить про наблюдения, вопросы, правила разговора и границы ответственности. Если он сразу ищет виноватых, будет беда.
Хорошо работает сценарный вопрос. Например: владелец продукта требует добавить срочную задачу в середине спринта, разработчики против, руководитель давит сроком. Что будет делать мастер гибкой разработки? Внятный ответ обычно включает разговор о цели спринта, цене переключения, вариантах замены задач и прозрачном решении для всех участников. Не героизм. Просто взрослая работа с последствиями.
- Как вы действуете, если один человек постоянно перебивает остальных?
- Что делаете, когда владелец продукта приносит задачу без критериев приёмки?
- Как разговариваете с руководителем, который раздаёт поручения мимо бэклога?
- Как помогаете команде обсуждать ошибки без поиска виноватого?
Между прочим, по этим вопросам видно и отношение кандидата к власти. Мастер гибкой разработки не командует разработчиками и не подменяет руководителя. Его сила в другом: он делает договорённости видимыми, вытаскивает противоречия наружу и помогает команде договориться о правилах игры. Если кандидат обещает «заставить всех работать по скраму», собеседование уже дало нужный сигнал.
Какие метрики и результаты обсуждать на финальной встрече
На финальной встрече спрашивают про метрики, которые кандидат реально использовал: скорость команды, предсказуемость спринта, время прохождения задачи, долю возвратов, выполнение договорённостей после ретроспектив. Цифры нужны не для отчёта, а для разговора о поведении команды.
Метрики легко превращаются в дубинку. Если специалист гордится только ростом скорости, надо уточнить, что происходило с качеством, переработками и объёмом незавершённой работы. Быстрая команда, которая каждую пятницу чинит последствия спешки, не стала сильнее. Она просто научилась красиво страдать в таблице.
Просите кандидата объяснить одну метрику на примере. Допустим, время прохождения задачи выросло с трёх дней до восьми. Что он проверит? Размер задач, очередь на ревью, загрузку тестирования, внешние зависимости, смену приоритетов. Такой ответ показывает системное мышление. Если звучит только «надо мотивировать команду», пользы от такого анализа мало.
| Метрика | О чём говорит | Опасная трактовка |
|---|---|---|
| Скорость | Сколько объёма команда закрывает за спринт | Сравнивать разные команды между собой |
| Время прохождения задачи | Где работа ждёт, а не движется | Давить на людей вместо поиска узкого места |
| Возвраты задач | Проблемы с требованиями, тестами или пониманием результата | Считать виноватым последнего исполнителя |
| Действия после ретроспектив | Способность команды менять процесс | Писать длинные списки без владельцев и срока проверки |
Финальный блок вопросов можно сделать почти деловым разбором. Какой результат кандидат считает своим самым сильным? Чем он это подтверждает? Что изменилось в поведении команды? Что осталось нерешённым? В ответах ищите связку между процессом и продуктом: быстрее проверили гипотезу, сократили очередь задач, убрали зависимость от одного человека, перестали начинать работу без критериев приёмки.
Выбор мастера гибкой разработки редко решается одним блестящим ответом. Нужна цепочка признаков: конкретные истории, уважение к ролям, умение спорить без шума, работа с метриками без поклонения цифрам. Такой специалист не обещает чудес за две недели, зато умеет замечать, где команда теряет время, доверие и смысл работы.
На собеседовании держитесь ближе к реальности проекта. Дайте кандидату конфликт, сорванный спринт, сырой бэклог и уставшую команду. Пусть покажет ход мысли. Именно там становится ясно, перед вами ведущий встреч или человек, который поможет команде работать взрослее.