Дедлайны есть во всех без исключения проектах и практически во всех продуктовых процессах разработки. В проектном управлении дедлайны легко напрямую связать с выручкой, но для продуктов всё несколько сложнее. Какую роль играют дедлайны при развитии продукта? Можно ли без них обойтись?
По мотивам статьи Джона Катлера. Публикуется с его разрешения для обсуждения и обмена опытом.
Простейший вид дедлайна — коммерческий. Если его «пробиваешь» — наглядно теряешь много денег. Таких дедлайнов мало: обычно это либо гонка с конкурентом, либо связано с календарным событием (праздником, выставкой и т. п.). Бывает, что декларируется именно коммерческий дедлайн, но после «пробития» оказывается, что деньги не потеряны. Бывает, что декларируется вероятность потерять много денег. Это проверить сложнее, но тоже можно (статистически) — часто оказывается, то прямые потери либо переоценены, либо их нет вовсе.
Это следствие злоупотребления искусственными дедлайнами. Большинство дедлайнов в продуктовой экосистеме (в отличие от проектной) — именно искусственные.
Зачем они бывают нужны:
- Ограничить затраты. На фичу/гипотезу нет смысла тратить больше чем Х ресурсов
- Создать здоровую атмосферу срочности. Команда, держащая «темп» и находящаяся в тонусе, работает эффективнее
- Стимулировать срезание скоупа. Полировка фичи быстро снижает предельную полезность работы
- Предотвращать «загулы» команды. Свободное плавание без бизнес-ориентиров неэффективно
- Поощрять целеполагание и сфокусированность. Повышает эффективность каждого члена команды
- Координировать зависимости. Мы договорились, что команда Х сможет начать работу после xx.xx.xxxx. Перепланирование и перерезервирование ресурсов неэффективно
- Координировать бизнес-активности. Старт продаж запланирован на xx.xx.xxxx. К этому времени может быть выделен бюджет или спланированы маркетинговые активности
- Создать измеримую ответственность. Если понятно, кто за что отвечает, то понятно и как/когда поощрять — прозрачность обратной связи
- Создать ощущение предсказуемости и спокойствия у бизнес-овнеров. Доверие бизнес-подразделений позволяет упростить коммуникацию и строить более эффективные процессы
Иногда искусственные дедлайны используются уместно, иногда нет. В любом случае полезно понимать и честно афишировать их истинное назначение в конкретный момент.
Примеры неоптимального использования искусственных дедлайнов:
- Спринты без юзабельного результата. Если заранее известно, что по итогам спринта смотреть будет не на что, и ничего нового в сервис интегрировано не будет, то оверхед на прерывание работ (конец/начало спринта), вероятно, не окупится
- Квартальные/годовые продуктовые планы. Из-за огромного количества недетерминированных элементов вероятность значительных ошибок как в планировании, так и в продуктовых гипотезах, близится к 100%, что дискредетирует такие отложенные дедлайны
- Дедлайн на основании оценки. Решает ряд проблем и очень популярен, но содержит изъяны:
- стимулирует «преждевременную сходимость» — выбирается локально оптимальное решение, хотя глобально оптимальное могло быть совсем недалеко
- может не зависеть от команды, так как оценка не включает внешние факторы
- фокусирует команду на работе «в срок» вместо работы «на результат», что повышает число ошибочных решений
Предложения возможных улучшений:
- «Правильные» таймбоксы. Общий ориентир/инициатива на несколько недель. Внутри этого периода короткие спринты с проверяемыми гипотезами реализации. Дедлайн фиксирован, скоуп произволен и многократно пересматривается
- Управление потоком. Моделируем работу как поток (например: Reinertsen, ToC, kanban), оптимизируем его. Параллельно ищем способы проводить частые интеграции (автоматические ретро для активностей длиннее X дней, CI/CD, SAFe IP/PI и т. п.)
- Если использовать дедлайны, то явно указывать, какую задачу они решают
Главная идея: думать на уровень выше. Пытаться искать решение конкретных бизнес-проблем (мотивация, координация и т. п.), а не вкорячивать костыли в виде дедлайнов в любой непонятной ситуации.
Обсуждение: Какие ещё бывают юзкейсы у дедлайнов? Какие альтернативные подходы могут быть использованы вместо дедлайнов?