Сроки разработки: от чего зависят и как не сорвать дедлайн

Почему сроки — это вопрос не календаря, а неопределённости

Когда клиент спрашивает «за сколько вы сделаете», он ждёт дату. Но честная разработка отвечает диапазоном, потому что срок — это производная от объёма работ, доступности людей и количества неизвестных в проекте. Чем больше неизвестных, тем шире вилка. На старте проекта неизвестных всегда максимум: не уточнены интеграции, не согласован дизайн, не понятно поведение внешних API. Поэтому первая оценка — это гипотеза, а не обязательство.

На рынке Узбекистана к этому добавляются свои факторы: интеграции с платёжными системами (Click, Payme, Uzum), привязка к банковским и государственным сервисам (ЕПИГУ, soliq.uz, идентификация), требования к локализации на трёх языках. Каждый такой узел — это внешняя зависимость, скорость которой вы не контролируете. Поэтому грамотная оценка отделяет то, что зависит от команды, от того, что зависит от третьих сторон.

Как устроена оценка: от грубой вилки к плану

Серьёзная студия не называет точную цифру с порога. Оценка проходит несколько уровней детализации, и на каждом вилка сужается.

• Грубая оценка (T-shirt sizing). «Это проект на 2-3 месяца» — для решения, браться ли вообще и в каком бюджете.
• Декомпозиция. Проект разбивается на модули и задачи. Чем мельче задача, тем точнее её оценивают: задачу на 1-2 дня оценить реально, задачу «сделать личный кабинет» — нет.
• Оценка в человеко-часах с учётом рисков. К чистой трудоёмкости добавляют время на ревью, тестирование, правки и коммуникацию — это обычно 30-50% сверху, а не «накрутка».

Спринты: почему итерации защищают сроки

Двухнедельный спринт — это не дань моде, а инструмент управления риском. В конце каждого спринта есть работающий инкремент, который можно показать и проверить. Это даёт две вещи: ранний фидбэк (ошибку в логике видно на второй неделе, а не на пятом месяце) и измеримую скорость команды — velocity. Зная, сколько задач команда реально закрывает за спринт, можно прогнозировать дату завершения по фактическим данным, а не по оптимизму.

Именно поэтому опытная команда первые 2-3 спринта считает «калибровочными»: оценка уточняется, когда появляется реальная статистика. Если на старте обещали 10 спринтов, а velocity показывает 13 — лучше сказать об этом на третьем спринте, чем молчать до дедлайна.

Почему сроки сдвигаются: настоящие причины

Сдвиг сроков почти никогда не происходит из-за того, что «программисты медленные». Реальные причины системные.

• Расползание объёма (scope creep). «Давайте ещё добавим вот это» — каждая мелкая правка по отдельности безобидна, в сумме они съедают недели.
• Задержки на стороне клиента. Несогласованный контент, поздний доступ к API банка, медленные ответы по правкам. Команда простаивает, а календарь идёт.
• Внешние зависимости. Модерация в App Store и Google Play, подключение мерчанта в платёжной системе, выдача доступов госсервисом — сроки здесь не ваши.
• Недооценённая интеграция. «Подключить платежи» звучит как один пункт, а на деле это документация, тестовый контур, обработка ошибок, сверка и боевая проверка.
• Технический долг. Если торопились в начале, в середине проекта расплачиваются скоростью.

Буферы и риск-менеджмент: как закладывать запас честно

Буфер — это не «накрутка на всякий случай», а осознанный резерв под известные категории риска. Грамотный подход — не размазывать запас по каждой задаче (его незаметно «съедают»), а держать общий проектный буфер в конце фазы. Тогда видно, насколько он расходуется, и это сигнал о здоровье проекта.

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

Что может сделать заказчик, чтобы не сорвать сроки

Сроки — это совместная ответственность. Половина сдвигов возникает не на стороне разработки. Чтобы проект шёл по плану, со стороны заказчика критично: выделить одного человека с правом принимать решения, отвечать на вопросы и согласования в течение 1-2 дней, готовить контент и доступы заранее, а не в момент, когда они уже нужны, и фиксировать изменения объёма как отдельные задачи, а не «по ходу».