Сроки часто обсуждают как вопрос «успеем, не успеем». Но в реальной разработке срок - это не дата. Это распределение риска.

Когда обязательство перед заказчиком появляется раньше технической оценки, происходит деформация процессов. Работа начинает выстраиваться не вокруг реальной сложности, а вокруг обещаний👇

❗️ Обещание фиксируется до понимания архитектурной глубины. ❗️ Риск переносится с бизнеса на команду. ❗️ Давление становится инструментом компенсации неопределённости. ❗️ Технический долг начинает закладываться в момент продажи.

В прикладной работе почти не бывает «просто сделать».

За любой «небольшой доработкой» могут стоять 👇

❗️ Изменения контрактов API. ❗️ Влияние на архитектуру и существующие зависимости. ❗️ Нагрузочные и нефункциональные требования. ❗️ Регресс и каскадные побочные эффекты. ❗️ Риски, которые проявляются только после интеграции.

Самая опасная иллюзия - считать сложность управляемой без её декомпозиции.

Вторая - верить, что если команда раньше «героически справилась», то это и есть нормальная модель работы.

Системный подход выглядит иначе 👇

❗️ Сначала техническая оценка и выявление рисков. ❗️ Затем диапазон сроков, а не красивая фиксированная дата. ❗️ Потом честный диалог с заказчиком о компромиссах.

Потому что срок - это всегда выбор! Либо управлять неопределённостью, либо перекладывать её на инженеров.

И здесь уже вопрос не в скорости. Вопрос в зрелости управления. #проекты