Короткий ответ
Если разработка задерживается, бизнесу важно не просто спросить “когда будет готово”, а получить проверяемую картину: что именно мешает релизу, какие решения уже приняты, какие риски остаются и что изменилось с момента прошлой оценки.
Задержка сама по себе не всегда проблема. В сложных web-проектах могут появляться новые вводные, скрытые зависимости и уточнения бизнес-логики. Проблема начинается там, где подрядчик не может объяснить задержку конкретно.
Сначала уточните факты
Перед разговором полезно отделить эмоции от фактов. Составьте список обещанных сроков, этапов, демонстраций, спорных задач и последних формулировок подрядчика. Это поможет обсуждать не общее недовольство, а конкретные расхождения.
На встрече задайте вопросы:
- какие задачи сейчас блокируют релиз;
- какие блокеры технические, а какие организационные;
- какие оценки изменились и по какой причине;
- какие решения уже согласованы, но ещё не реализованы;
- какие зависимости находятся на стороне бизнеса;
- что можно показать в текущем состоянии.
Ответы должны быть привязаны к задачам, модулям, интеграциям и критериям готовности.
Вопросы по архитектуре
Если задержка повторяется, нужно понять, не связана ли она с архитектурой проекта.
Спросите:
- какие части системы сейчас сложнее всего дорабатывать;
- есть ли модули, где каждая правка создаёт новые ошибки;
- какие интеграции требуют дополнительной проверки;
- где не хватает документации;
- какие технические решения могут ограничить развитие проекта через несколько месяцев.
Если подрядчик отвечает общими словами, возможно, нужен аудит проблемного проекта или независимый технический контроль подрядчика.
Вопросы по релизу
Важно понять, что именно команда считает готовым.
Попросите:
- список задач, которые войдут в ближайший релиз;
- критерии готовности для каждой крупной функции;
- список известных ошибок, которые команда предлагает перенести;
- план тестирования;
- дату демонстрации промежуточного результата;
- условия, при которых срок снова может измениться.
Если “готово” означает только завершение разработки без проверки бизнес-сценариев, релиз может стать новым источником проблем.
Что должно насторожить
Сигналы риска:
- подрядчик не показывает промежуточный результат;
- срок переносится без новой структуры работ;
- нет списка блокеров;
- команда не фиксирует решения письменно;
- документация откладывается “на потом”;
- каждый разговор заканчивается просьбой увеличить бюджет без объяснения причин.
В такой ситуации проект может перейти в сценарий, где подрядчик не справляется или затягивает разработку без проверяемого статуса.
Практический вывод
Правильные вопросы помогают не спорить о доверии, а управлять ситуацией. Если задержка объяснима, её можно встроить в план. Если подрядчик не может дать факты, бизнесу нужен внешний взгляд: карта рисков, проверка архитектуры и понятный план следующих действий.
