Какой командный процесс вы заметно улучшили: planning, daily, retro, refinement или release flow?

Процесс, который я изменил: refinement

Когда я пришёл в команду, refinement выглядел так: PM зачитывал тикет, команда молча кивала, кто-то называл цифру story points, остальные соглашались. Итог — постоянные неожиданности в спринте: «мы не учли X», «оказалось, что Y зависит от Z».

Диагностика проблемы

Я провёл ретроспективу, сфокусированную на одном вопросе: «Почему задачи оказываются сложнее, чем мы оценили?» Выяснилось три системных причины:

• Команда не задавала уточняющих вопросов — культура «не хочу выглядеть глупо».
• Технические зависимости не выявлялись на refinement — только в процессе работы.
• Story points ставились на основе «как у похожей задачи», без разбора этой конкретной задачи.

Что изменил

Ввёл структурированный шаблон для каждого тикета перед refinement. PM заполнял его заранее:

• What: что нужно сделать.
• Why: зачем это нужно пользователю или бизнесу.
• Acceptance criteria: как мы поймём, что готово.
• Out of scope: что явно не включено.

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

Также добавил явный шаг «технические зависимости»: перед оценкой команда называет всё, от чего зависит задача (API, схема БД, сторонний сервис). Если зависимость неясна — задача уходит на доуточнение, а не оценивается.

Результат

Через два месяца: процент задач, завершённых в спринте без переноса, вырос с 62% до 81%. Команда начала сама защищать процесс — «подожди, мы ещё не разобрали зависимости».

Что не сработало

Я пробовал вводить формальные оценки в часах вместо story points. Команда тратила время на точные цифры там, где нужна была лишь относительная оценка. Откатил через месяц.

Подводные камни

• Менять процесс без объяснения причин — команда воспринимает изменения как бюрократию, а не как улучшение.
• Вводить слишком много изменений одновременно — невозможно понять, что именно помогло.
• Не измерять эффект изменения — без данных нельзя ни подтвердить успех, ни обосновать дальнейшие эксперименты.
• Игнорировать сопротивление команды — если люди против нового процесса, нужно понять почему, а не продавливать силой.
• Оптимизировать refinement без улучшения качества тикетов на входе — шаблон для PM оказался критически важным.
• Считать, что улучшенный процесс будет работать вечно без поддержки — через квартал без напоминаний команды возвращаются к старым привычкам.
• Не давать команде участвовать в выработке нового процесса — чужой процесс всегда хуже своего.

• Копировать Scrum-практику без причины.
• Менять процесс слишком широко и сразу.
• Не убрать практику, если она не помогает.

• Думает о процессе как об инструменте.
• Может внедрять изменения постепенно.
• Оценивает эффект по поведению команды.