Дедлайны есть во всех без исключения проектах и практически во всех продуктовых процессах разработки. В проектном управлении дедлайны легко напрямую связать с выручкой, но для продуктов всё несколько сложнее. Какую роль играют дедлайны при развитии продукта? Можно ли без них обойтись?

_{По мотивам статьи Джона Катлера. Публикуется с его разрешения для обсуждения и обмена опытом.}

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

Это следствие злоупотребления искусственными дедлайнами. Большинство дедлайнов в продуктовой экосистеме (в отличие от проектной) — именно искусственные.

Зачем они бывают нужны:

• Ограничить затраты. На фичу/гипотезу нет смысла тратить больше чем Х ресурсов
• Создать здоровую атмосферу срочности. Команда, держащая «темп» и находящаяся в тонусе, работает эффективнее
• Стимулировать срезание скоупа. Полировка фичи быстро снижает предельную полезность работы
• Предотвращать «загулы» команды. Свободное плавание без бизнес-ориентиров неэффективно
• Поощрять целеполагание и сфокусированность. Повышает эффективность каждого члена команды
• Координировать зависимости. Мы договорились, что команда Х сможет начать работу после xx.xx.xxxx. Перепланирование и перерезервирование ресурсов неэффективно
• Координировать бизнес-активности. Старт продаж запланирован на xx.xx.xxxx. К этому времени может быть выделен бюджет или спланированы маркетинговые активности
• Создать измеримую ответственность. Если понятно, кто за что отвечает, то понятно и как/когда поощрять — прозрачность обратной связи
• Создать ощущение предсказуемости и спокойствия у бизнес-овнеров. Доверие бизнес-подразделений позволяет упростить коммуникацию и строить более эффективные процессы

Иногда искусственные дедлайны используются уместно, иногда нет. В любом случае полезно понимать и честно афишировать их истинное назначение в конкретный момент.

Примеры неоптимального использования искусственных дедлайнов:

• Спринты без юзабельного результата. Если заранее известно, что по итогам спринта смотреть будет не на что, и ничего нового в сервис интегрировано не будет, то оверхед на прерывание работ (конец/начало спринта), вероятно, не окупится
• Квартальные/годовые продуктовые планы. Из-за огромного количества недетерминированных элементов вероятность значительных ошибок как в планировании, так и в продуктовых гипотезах, близится к 100%, что дискредетирует такие отложенные дедлайны
  
• Дедлайн на основании оценки. Решает ряд проблем и очень популярен, но содержит изъяны:
  
  
  • стимулирует «преждевременную сходимость» — выбирается локально оптимальное решение, хотя глобально оптимальное могло быть совсем недалеко
  • может не зависеть от команды, так как оценка не включает внешние факторы
  • фокусирует команду на работе «в срок» вместо работы «на результат», что повышает число ошибочных решений
  
  

Предложения возможных улучшений:

• «Правильные» таймбоксы. Общий ориентир/инициатива на несколько недель. Внутри этого периода короткие спринты с проверяемыми гипотезами реализации. Дедлайн фиксирован, скоуп произволен и многократно пересматривается
• Управление потоком. Моделируем работу как поток (например: Reinertsen, ToC, kanban), оптимизируем его. Параллельно ищем способы проводить частые интеграции (автоматические ретро для активностей длиннее X дней, CI/CD, SAFe IP/PI и т. п.)
• Если использовать дедлайны, то явно указывать, какую задачу они решают

Главная идея: думать на уровень выше. Пытаться искать решение конкретных бизнес-проблем (мотивация, координация и т. п.), а не вкорячивать костыли в виде дедлайнов в любой непонятной ситуации.

Обсуждение: Какие ещё бывают юзкейсы у дедлайнов? Какие альтернативные подходы могут быть использованы вместо дедлайнов?