11 советов как продакт-менеджеру заранее предотвращать срывы сроков разработки (и что делать, если они срываются)
0. Всегда умножай оценки сроков х2-3. А при коммуникации со стейкхолдерами давай диапазоны вместо точных дат.
1. Не критикуй разрабов за пессимистичные прогнозы разработки – пусть лучше они честно скажут, что это займёт месяц, чем под давлением пообещают 2 недели и завалят всё на 2 месяца.
3. Декомпозируй задачи до уровня обнаружения в ней любых возможных блоков через 2-3 дня её разработки.
Если задачу нельзя разбить до такого уровня, значит задача недостаточно тобой детализированна.
4. Помни про Critical path - последовательность задач, в которой задержка любой задачи сдвигает всю дату релиза.
Выделяй сеньоров на критический путь + всегда имей прозапас запасного участника такого уровня для критической части.
5. Включай в сессии по оценке сроков разарботки не только сеньоров, но и мидлов. Именно мидлы пишут код и именно их оценки самые реалистичные.
6. Требуй тех. задание от лид-инженера перед началом разработки.
Оно заставляет команду разработки продумать архитектуру, выявить зависимости и определить точки интеграции ДО написания кода.
7. Стендапы нужны для выявления блокеров и отклонений. Нет блокеров и отклонений – не мучайтесь с командой ежедневными созвонами, они ведут к выгоранию, которое ведёт к потере чувства времени и сроков.
Вместо них можно ведите автоматизированный стендап в Slack с указанием % готовности задач и уведомлениями о превышении запланированных сроков и объяснением причин и новой оценкой времени со стороны тимлида.
Что делать, если сроки срываются?
8. Red Room – экстренный режим работы с ежедневными встречами всех ключевых участников для быстрого принятия решений и устранения блокеров.
Если Red Room длится более одной недели, значит проблема сроков разработки носит стратегический характер и требует структурных кадровых/культурных решений, а не разовых фиксов/припарок.
Урезай фичу до версии, которая всё ещё решает основную пользовательскую проблему и приносит ценность юзерам/бизнесу
Урезанная версия идёт по 3 сценариям с чёткими критериями: время vs scope vs качество.
И если вы не можете убрать 30% скопа без потери основной ценности, значит изначальное решение было over-engineered.
Всегда документируй такие решения для избежания вопросов со стороны заинтересованных лиц (и конфликтов в будущем).
10. Перераспределение ресурсов с менее критичных задач и привлечение дополнительных разрабов работает только при наличии:
а) чёткой и описанной архитектуры;
б) возможностей для параллелизации задач;
в) разрабов с опытом в конкретной области/стэке;
г) наличии 1-2 недель на их онбординг.
11. Регулярные post-mortem после каждого релиза позволяют команде учиться на своих ошибках и повышать точность планирования. Если одни и те же проблемы повторяются в нескольких post-mortem, это снова про систематическую ошибку и кардинальные решения по её исправлению.
Каждая фаза разработки должна приносить ценность для пользователя и бизнеса, а не быть очередным спринтом-забегом на время для команды разработки.
0. Всегда умножай оценки сроков х2-3. А при коммуникации со стейкхолдерами давай диапазоны вместо точных дат.
1. Не критикуй разрабов за пессимистичные прогнозы разработки – пусть лучше они честно скажут, что это займёт месяц, чем под давлением пообещают 2 недели и завалят всё на 2 месяца.
Поощряй и стимулируй в команде точность и предсказуемость поставки, а не скорость и оптимистичные оценки
3. Декомпозируй задачи до уровня обнаружения в ней любых возможных блоков через 2-3 дня её разработки.
Если задачу нельзя разбить до такого уровня, значит задача недостаточно тобой детализированна.
4. Помни про Critical path - последовательность задач, в которой задержка любой задачи сдвигает всю дату релиза.
Выделяй сеньоров на критический путь + всегда имей прозапас запасного участника такого уровня для критической части.
5. Включай в сессии по оценке сроков разарботки не только сеньоров, но и мидлов. Именно мидлы пишут код и именно их оценки самые реалистичные.
6. Требуй тех. задание от лид-инженера перед началом разработки.
Оно заставляет команду разработки продумать архитектуру, выявить зависимости и определить точки интеграции ДО написания кода.
Если лид не может написать ТЗ за 3 часа, значит задача УЖЕ недостаточно понятна для реализации
7. Стендапы нужны для выявления блокеров и отклонений. Нет блокеров и отклонений – не мучайтесь с командой ежедневными созвонами, они ведут к выгоранию, которое ведёт к потере чувства времени и сроков.
Вместо них можно ведите автоматизированный стендап в Slack с указанием % готовности задач и уведомлениями о превышении запланированных сроков и объяснением причин и новой оценкой времени со стороны тимлида.
Что делать, если сроки срываются?
8. Red Room – экстренный режим работы с ежедневными встречами всех ключевых участников для быстрого принятия решений и устранения блокеров.
Если Red Room длится более одной недели, значит проблема сроков разработки носит стратегический характер и требует структурных кадровых/культурных решений, а не разовых фиксов/припарок.
9. Урезание функционала это про чёткое понимание текущих приоритетов и их влияния на бизнес-цели, а не сокращение/навёрстывание сроков
Урезай фичу до версии, которая всё ещё решает основную пользовательскую проблему и приносит ценность юзерам/бизнесу
Урезанная версия идёт по 3 сценариям с чёткими критериями: время vs scope vs качество.
И если вы не можете убрать 30% скопа без потери основной ценности, значит изначальное решение было over-engineered.
Всегда документируй такие решения для избежания вопросов со стороны заинтересованных лиц (и конфликтов в будущем).
10. Перераспределение ресурсов с менее критичных задач и привлечение дополнительных разрабов работает только при наличии:
а) чёткой и описанной архитектуры;
б) возможностей для параллелизации задач;
в) разрабов с опытом в конкретной области/стэке;
г) наличии 1-2 недель на их онбординг.
Если добавление разрабов не ускоряет доставку кода через 2 недели, правильным решением будет их отозвать и не мучать
11. Регулярные post-mortem после каждого релиза позволяют команде учиться на своих ошибках и повышать точность планирования. Если одни и те же проблемы повторяются в нескольких post-mortem, это снова про систематическую ошибку и кардинальные решения по её исправлению.
Каждая фаза разработки должна приносить ценность для пользователя и бизнеса, а не быть очередным спринтом-забегом на время для команды разработки.