Довольно часто возникают такие ситуации:
- У нас есть идея проекта, который по расчетам должен принести много денег.
- Наше руководство сильно заинтересовано в выполнении этого проекта как можно быстрее, оно дает нам свободу действий и приоритет в использовании ресурсов компании, чтобы сделать его как можно быстрее.
- Сроки, как обычно, очень сжаты.
- Мы собираем команду «суперзвезд», чтобы выполнить этот проект в срок.
- И... Сроки проекта сильно выбиваются из запланированных.
Давайте обсудим, почему так происходит.
Если не успели — значит, плохо работали
Самый распространенный миф — если не успели, значит, плохо работали/слабая команда и тому подобное.
Я видел сильные команды, которые:
- писали чистый код и быстро;
- работали по 10 часов в день;
- закрывали задачи быстрее среднего
…и всё равно стабильно не попадали в дедлайны.
Срывы сроков проекта — это чаще всего системные проблемы в процессах, планировании и коммуникациях. Множество мелких задержек и проблем, оставленных без контроля, имеют свойство накапливаться и приводят к каскадным системным сбоям.
Даже сильная команда может стабильно нарушать сроки разработки, когда сама система работает против нее!
Частые причины нарушения сроков
❌ Размытые цели и scope
Цель сформирована нечетко («Запустить MVP» или «Сделать продукт удобным»). Нет четких критериев готовности, сами постановки задач размыты. А вдобавок постоянно меняются или добавляются/удаляются требования.
❌ Оптимистичные оценки и давление на них
Люди в большинстве своем склонны недооценивать сроки, даже зная прошлые задержки и провалы, стараясь фокусироваться на идеальном сценарии, поэтому в большинстве своем оценки будут оптимистичны. Сюда же накладывается давление со стороны руководства и менеджеров («Ну что там делать так долго, это же всего пара форм?!»). В итоге и без того оптимистичные сроки становятся совсем невыполнимыми.
❌ Скрытые зависимости
В задачах появляются зависимости от других команд и интеграции со сторонними API. Выполнение нескольких задач блокируется одной, которую может делать в данный момент времени только один человек (развертывание инфраструктуры или подобные задачи). Иногда задачи подвисают по независящим от разработки причинам, например по технологическим, процессным или юридическим.
❌ Перегрузка команды и мультизадачность
Люди работают сразу над несколькими инициативами или в работе есть другие параллельные активности (например, SRE-дежурства или дежурства в поддержке, собеседования и т. п.). Появляется множество срочных «влеташек» — небольших задач/багов, которые требуют немедленного внимания. Контекст команды постоянно переключается, люди теряют фокус на текущих задачах. Производительность команды значительно снижается.
❌ Отсутствие ранней обратной связи
Результат работы команды показывается главным заказчикам большими порциями и в конце длительных итераций. Из-за этого ошибки в понимании требований обнаруживаются слишком поздно, в результате часто необходимо переделывать огромный пласт функциональности.
Как это всё связано
Эти причины редко существуют по одной. Обычно беда не приходит одна:
размытый scope → оптимистичная оценка → скрытые зависимости → перегрузка → поздний фидбек → срыв сроков
Это и есть системная проблема, а не «кто-то плохо работает».
Сталкивались с такой цепочкой в своих проектах? Какой фактор чаще всего становился «последней каплей»?
#management #processes #agile