Как говорится, первый блин всегда комом. Но на то это и правило, чтобы там были исключения.🙂 Я четко помню как создавал и внедрял свой первый продукт. Тот, который сам спроектировал, составил план релиза, рассчитал сроки, экономику. Помню, что насмотревшись на ошибки в других продуктах, на регулярную замену(даже не изменение) требований, я решил упороться в подготовительный этап. Было потрачено около 2 мес на проектирование архитектуры, на бфт, прототипирование и т.д. Как итог, это дало свои плоды: разработка шла без остановок на уточнение требований, рефакторинг был минимален. А сам продукт сделали очень отказоустойчивым - он не работал только если падал сервер и в момент восстановления не срабатывал скрипт управления. За 5 лет работы к ручному восстановлению прибегали лишь дважды. Помимо прочего, там были учтены требования и хотелки на годы вперёд. При этом речь не идёт о том, что это был waterfall, что требования не менялись. Возникали идеи в процессе разработки, обсуждали, что то брали, что то отметали, т.к. уже была запланировано более оптимальное решение. Важно то, что разработке всегда было что делать, а новые требования не затрагивали текущую разработку. В чем суть поста: а суть проста - иногда для того, чтобы ускорится; надо замедлится. Это звучит противоестественно, но это так. Дополнительное время на более детальную проработку требований к разработке сэкономит в разы больше времени на последующих этапах, что даст общее снижение стоимости разработки.

*Все изображения из открытых источников