Быстрый запуск и глубокая подготовка часто подаются как противоположности, хотя на деле это две разные стратегии работы с риском. Быстрый запуск хорош там, где важно быстро получить реальный сигнал от рынка, проверить гипотезу и не тратить месяцы на то, что потом никому не нужно. Глубокая подготовка нужна там, где цена ошибки высока, а последствия могут быть дорогими: данные, безопасность, деньги, репутация, сложная интеграция. Ошибка команд часто в том, что они выбирают не подход к задаче, а эмоциональное ощущение - либо “давайте скорее”, либо “надо еще месяц доработать”. И оба перегиба могут быть одинаково вредными.
Быстрый запуск не должен быть синонимом сырости, а глубокая подготовка - синонимом бесконечной задержки. Когда команда умеет видеть, где нужен быстрый тест, а где нужен серьезный допуск к запуску, она перестает тратить ресурсы на неправильные вещи. Это и есть зрелость: не делать лишнего, но и не недооценивать последствия ошибки.
В технических проектах я бы разделял две категории рисков - обратимые и необратимые. Если действие можно быстро откатить, быстрый запуск часто оправдан. Если ошибка может повлиять на данные, доступы, деньги или безопасность, торопиться опасно. Тогда нужна глубжея подготовка, тестирование и сценарии отката. Проблема обычно в том, что команды смешивают эти два типа задач в одну кучу и получают либо лишнюю задержку, либо слишком ранний релиз.
Если переделка на раннем этапе дешевая, лучше проверять быстрее и чаще. Если переделка уже тяжелая, то подготовка должна быть глубже. Это хороший критерий, потому что он убирает спор “кто любит скорость, а кто перфекционизм”. Вопрос не в характере команды, а в том, где ошибка обойдется дороже всего.
Очень важно, чтобы команда одинаково понимала, где у нее “минимально достаточно” и где уже начинается халтура. Если эти границы не проговорить, один человек будет считать работу готовой слишком рано, а другой - бесконечно докручивать детали. Поэтому я бы заранее закрепляла критерии: что обязательно до запуска, что можно отложить, что надо добрать после первых данных. Это резко снижает споры.