Почему заказчик звонит разработчикам
Обычно причина простая: путь через разработчика короче. Заказчику кажется, что он попросит, и это сделают за час. Разработчику кажется, что просьба важная, раз её принёс заказчик. Никто из них не видит, что новая задача сдвигает другую задачу спринта, и никто не отвечает за то, что в спринте стало на одну задачу меньше.
В симуляторе это день 5. Владелец продукта со стороны заказчика, Нура, звонит backend-разработчику Радже, и тот переделывает экран фильтров. Утром техлид Сергей сообщает PM, что две задачи спринта уехали на следующую неделю, и добавляет: «Он не виноват: ему никто не сказал, что можно отказать».
Есть и вторая причина, о которой говорят реже. Владелец продукта отвечает за результат перед своим руководством, а не за очередь команды подрядчика. Если экран нужен к понедельнику для показа, звонок кажется единственным способом успеть. Правило не должно отнимать у владельца ответственность. Оно должно дать ему канал, где срочность видна всем, включая тех, кто решает, что уйдёт из спринта.
Правило одной строки: просьбы идут через PM
Правило должно быть коротким и говорить о процессе, а не о людях. Просьбы об изменении работы идут к PM или к согласованному владельцу очереди. Разработчики не берут их в работу по звонку. Решение о приоритете записывается письменно. Это не запрет общаться: заказчик может спрашивать у разработчиков о ходе работ, но менять задачи через них нельзя.
Команде это можно сказать так: «Если вам позвонили с просьбой, ответьте: передам PM, оценку дам к такому-то дню. Работу не начинайте, пока приоритет не записан».
Правило стоит записать в план коммуникаций и показать на следующем стиркоме, а не только написать в чат команды. Тогда на него можно сослаться, когда просьба придёт снова, и не нужно будет объяснять его заново.
Что записать в RACI
RACI фиксирует, кто отвечает за решение. В матрице для такого проекта обычно есть строка «Change request approval»: решение принимает комитет, PM подрядчика и PM заказчика готовят запрос, техлид только информируется. Правило простое: в каждой строке ровно один A. Если A и R совпадают, это риск: человек и согласует, и делает, и никто не проверяет.
Для правила о просьбах добавь отдельную строку, например «Просьба о новой работе со стороны заказчика». A ставь на PM подрядчика, R на владельца продукта заказчика, который формулирует просьбу, C на техлида, который оценивает, I на разработчиков. Тогда по матрице видно, что звонок разработчику в процесс не входит.
Путь для просьб не длиннее звонка
Владельцу продукта нужен ответ «когда», а не «нельзя». Поэтому путь для просьб должен быть короче звонка по времени ответа: один канал, один человек, который ставит просьбу в очередь, и понятный срок. Нура в симуляторе возражает: «Раджа делает за час. Вы будете делать за неделю. Зачем мне это?» Спорить о скорости бесполезно. Нужно показать, что будет с просьбой после письма.
Рабочая формула из четырёх шагов:
- Подтверждение получения в тот же рабочий день.
- Оценка: размер работы и что она сдвигает в текущем плане.
- Решение: владелец продукта, если это внутри скоупа, или запрос на изменение, если нет.
- Дата, когда просьба попадает в спринт или в очередь.
Что идёт в спринт, а что в запрос на изменение
Не каждая просьба требует запроса на изменение. Если работа укладывается в согласованный скоуп, например поправить подпись кнопки или порядок колонок, её ставит в очередь владелец продукта, и она попадает в следующий спринт. Если работа выходит за скоуп, например новый источник данных, она уходит в запрос на изменение с оценкой и решением комитета. Граница между этими путями записывается в устав и в RACI, иначе каждый спор начинается заново.
Как понять, что правило работает
Проверяй правило по журналу, а не по ощущениям. Раз в неделю смотри, сколько просьб пришло мимо канала, сколько из них переведено в очередь письмом и сколько задач спринта сдвинуто по просьбам заказчика и на сколько дней. Если число обходов не падает за две-три недели, путь для просьб всё ещё длиннее звонка. Его надо упростить, а не ужесточать запрет: запрет без короткого пути только переносит звонки в другое место.
Разговор с владельцем продукта
Не начинай с правила. Начни с того, что владелец продукта получает: быстрый путь, понятное время ответа и гарантию, что идея не потеряется. Решение о приоритетах остаётся за ним, это его работа. Меняется только маршрут, по которому просьба попадает в работу.
В симуляторе поддержку заказчика получают так: основной контакт Фарида, узнав о конфликте, говорит: «Она владелец продукта, менять приоритеты — её работа. Что вы предлагаете?» Эта фраза важна: если правило поддерживает сторона заказчика, оно становится её правилом, а не запретом подрядчика.
Попроси назвать две-три просьбы за последнюю неделю, которые были действительно срочными. Обычно такой список короче, чем ощущение срочности в момент звонка, и по нему легко договориться о пути: что идёт сразу, а что в очередь.
Разговор с разработчиком
Разработчик, который переделал работу по звонку, не нарушил правил, потому что их никто не сформулировал. Говори об этом прямо и без упрёка. Скажи, что с этого дня просьбы идут через тебя, и что если просьба пришла напрямую, можно ответить: передам PM.
Спроси у разработчика, что в просьбе было неясно и почему он не уточнил у PM. Чаще всего ответ простой: ему было некуда спросить, а звонящий говорил уверенно. Когда у команды есть понятный путь уточнения, вопросов становится больше, а переделок меньше.
В симуляторе Сергей напоминает, что на прошлом проекте тоже была матрица. Ответ на это не в том, что матрица поможет сама. Правило работает, если каждое решение о приоритете записано и каждый вопрос к команде проходит через одну точку.
Если заказчик всё равно звонит
Правило не работает без второго шага. Если просьба пришла мимо канала, её переводят в очередь письмом с подтверждением: что услышали, что согласовано, что будет дальше и кто владелец. Так звонок не теряется, а становится задачей с датой. Письмо может быть таким: «Здравствуйте, Нура. Спасибо за просьбу по экрану фильтров. Передаю её в очередь PM, оценку пришлю до конца дня. Пока задача не в спринте, работу не начинаем, чтобы не сдвинуть текущие задачи. Если срочно, напишите, что именно должно быть готово и к какой дате».
Если спор продолжается, используй эскалацию, которую согласовали заранее. В образце плана коммуникаций задача, открытая дольше двух недель, уходит на следующий уровень, а изменение срока или скоупа на решение спонсора. Точные уровни и сроки бери из своего плана, а не из чужого.
Если хочешь разобрать такой разговор на кейсе, в PM Simulator это день 5: RACI, план коммуникаций и разговор с Нурой проигрываются с ИИ-персонажами, а разбор делает ИИ-ментор.
Частые вопросы
Можно ли разработчикам отвечать заказчику на вопросы?
Да, если вопрос о ходе работ или о том, как устроена функция. Менять задачу или называть сроки нельзя. Ответ может звучать так: «Это вопрос к PM, он ответит сегодня».
Что делать, если владелец продукта сам принимает решения и не хочет ждать?
Договорись со спонсором о правиле изменений: обычные просьбы идут через очередь, срочные исключения одобряет спонсор письменно, с указанием, что будет сдвинуто. Так решение остаётся у владельца, а последствия видны всем.
Как не превратить RACI в бумагу, которую никто не открывает?
После каждого спорного случая смотри, совпадает ли решение со строкой матрицы. Если совпадения нет, поправь строку, а не просто запиши исключение. Матрица, которую не открывали месяц, уже устарела.
