Командный risk-review перед сложной задачей

Когда нужен risk-review

Risk-review нужен перед задачей, где команда уже видит неопределенность: интеграция, несколько систем, новая область, чувствительные данные, спорный процесс, жесткий срок или несколько участников с разными ожиданиями.

Цель не в том, чтобы найти все риски. Цель — сделать главные риски видимыми до старта разработки.

Формат

Достаточно 30-45 минут и одного документа или карточки.

Участники:

• тимлид;
• аналитик;
• разработчик или техлид;
• владелец результата;
• при необходимости безопасность, эксплуатация или внешняя сторона.

На выходе должны появиться решения, вопросы и владельцы, а не просто список тревог.

1. Что может пойти не так

Начать лучше с простого вопроса:

Где задача может стать дороже, чем кажется сейчас?

Типовые зоны:

• непонятная цель;
• скрытая зависимость от другой команды;
• внешний сервис или поставщик;
• неочевидные данные;
• ошибки и повторные действия;
• безопасность и доступы;
• приемка без проверяемых критериев;
• срок, который не совпадает с объемом.

2. Что нужно проверить до разработки

Не каждый риск нужно закрывать сразу. Но каждый существенный риск нужно классифицировать.

Варианты:

• уточнить требование;
• сделать технический spike;
• зафиксировать решение;
• ограничить MVP;
• добавить ручной обход;
• принять риск явно;
• остановить старт задачи до ответа.

Если риск нельзя превратить в действие, он останется общей тревогой и не поможет команде.

3. Где фиксировать результат

Risk-review не должен создавать тяжелый протокол. Достаточно короткой записи:

Контекст:
Почему задача рискованная.

Риски:
1. Что может пойти не так.
2. Почему это важно.
3. Что делаем.
4. Кто владелец.

Решения:
Что уже выбрали.

Открытые вопросы:
Что нужно уточнить до старта или до конкретного этапа.

Если одно из решений влияет на API, процесс, безопасность или несколько задач, лучше вынести его в отдельную запись решения.

Сценарий на 30-45 минут

Этот формат можно провести без отдельной церемонии. Достаточно созвона, доски или одной карточки в задаче.

До встречи.

Подготовьте короткий контекст:

• цель задачи;
• что входит в первую версию;
• какие системы, роли или команды затронуты;
• какие вопросы уже кажутся рискованными;
• какое решение нужно принять до старта.

0-5 минут: рамка.

Ведущий проговаривает:

• какой результат нужен от review;
• какие решения можно принять на встрече;
• какие вопросы только фиксируются и уходят к владельцу;
• где будет лежать итоговая запись.

5-15 минут: карта рисков.

Команда по очереди называет риски. На этом шаге не спорят о решении, а собирают список неизвестных мест:

• сценарии;
• данные;
• внешние зависимости;
• ошибки и повторные действия;
• безопасность;
• сроки;
• приемка;
• эксплуатация и поддержка.

15-30 минут: решения и действия.

Для каждого существенного риска выберите один следующий шаг:

• уточнить требование;
• сделать spike;
• ограничить MVP;
• зафиксировать decision record;
• добавить критерий приемки;
• принять риск явно;
• остановить старт до ответа.

30-45 минут: владельцы.

Итоговая запись должна ответить:

• что стартует без блокера;
• что блокирует старт;
• кто владелец каждого открытого вопроса;
• где команда вернется к результату;
• какие решения нужно вынести отдельно.

Если после встречи остался только список тревог без владельцев, risk-review не завершен.

4. Как не превратить это в бюрократию

Risk-review должен быть пропорционален задаче.

Он не нужен для каждой мелкой доработки. Он нужен там, где цена неявности выше, чем стоимость короткого обсуждения.

Признаки здорового формата:

• обсуждение короткое;
• риски превращаются в действия;
• нет попытки описать все заранее;
• команда понимает, зачем это делается;
• результат можно использовать в задаче;
• часть вопросов честно остается открытой, но с владельцами.

5. Роль тимлида

Тимлид на risk-review не обязан знать ответы на все вопросы. Его задача — удержать рамку:

• не смешивать риски, задачи и мнения;
• отделять блокирующее от важного;
• следить, чтобы неизвестные места получили владельцев;
• не позволять команде стартовать с разными ожиданиями;
• фиксировать решения, которые потом нельзя будет восстановить по памяти.

Хороший результат risk-review — команда начинает работу не с полной уверенностью, а с ясным списком того, что понятно, что проверяем и какие риски принимаем.