Сроки сдвигаются: разбор системных причин, о которых редко говорят

В предыдущей статье я писала о нерабочих процессах в продуктовой команде и о том, как они постепенно накапливают проблемы. Эти проблемы редко возникают внезапно, чаще всего им предшествуют сигналы.

Один из таких сигналов - это сдвиг сроков. Причём довольно поздний. Как температура при простуде: мы замечаем её, когда процесс уже давно запущен.

Где на самом деле начинается срыв сроков

Возьмём условную команду N. В ней работает менеджер проектов Фёдор - опытный, ответственный, его любит команда.

Фёдор понимает: срыв сроков почти никогда не начинается в момент, когда разработчик не закрыл задачу вовремя. Он начинается гораздо раньше - на этапе формулирования результата и сбора требований.

Когда от CEO поступает очередная идея с формулировкой вроде "сделать удобный сервис"/"запустить новый функционал" или "улучшить UX", команда начинает работать не с целью, а с абстракцией. В этот момент закладывается первая трещина: нет границы, где работа считается завершённой. В итоге появляется постоянное уточнение требований, расширение объёма, "давайте ещё это добавим" - и календарь начинает медленно разъезжаться.

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

Иллюзия точного планирования

Знакомьтесь, это Василий - продакт команды N. Василий - добрый и отзывчивый, а еще он много работает на благо компании. Василий глубоко уважает CEO, поэтому любую его идею сразу берет в оборот дабы максимально показать свою лояльность.

Продакт оказывается в сложной позиции: нужно быстро отреагировать на инициативу бизнеса, показать, что есть движение по задаче, не затягивать процесс проработки.

Идея уходит в требования и оценку. Всё формально сделано правильно, но допущения, на которых строится оценка, редко проговариваются как риски, они превращаются в “план”.

И тут вторая контрольная точка системной ошибки - вера в точность предварительной оценки.

Оценка почти всегда строится на предположениях: о сложности, о зависимости от других систем, проектов, о доступности людей, о скорости согласований. Но в плане эти предположения быстро превращаются в факты. А дальше начинается цепная реакция.

Стоит одному допущению не подтвердиться и план начинает жить своей жизнью. Но вместо пересмотра модели проекта на этом этапе мы пытаемся "оптимизировать исполнение". Добавляем контроль, созвоны, пингуем со статусом по задаче, увеличиваем давление.

Сроки продолжают ехать, потому что проблема не в скорости, а в исходной модели.

Аналитик бизнес-требования прописал, по ним команда сделала оценку - все это быстро-быстро, потому что инициатор торопит: у него еще вагон идей, некогда тут топтаться на месте.

Обычно до официального “сдвига сроков” в проекте уже происходят характерные изменения. Требования уточняются по ходу работы, появляются дополнительные зависимости. Часть задач “временно” упрощается, чтобы не тормозить процесс.

Формально дедлайн остаётся прежним, но модель проекта уже изменилась. И именно в этот момент уже можно предположить, что будет сдвиг.

Проблема не в скорости, а в том, что изначальные допущения перестали соответствовать реальности.

Сдвиг как индикатор перегруженной системы

Есть ещё одна причина, которую редко проговаривают: перегруженность самой системы управления.

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

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

В такой среде даже хорошо спланированный проект начинает терять предсказуемость. Не потому что команда N работает мало или плохо, а потому что вся система целиком нестабильна. Продакт не проработал как следуют идею, а взял ее в сыром виде, наспех прописали требования и оценили. Сроки начинают “плыть” как естественная реакция на турбулентность.

Почему борьба со сроками редко помогает

Что делать? Интуитивная и первая реакция - усилить контроль. Добавить промежуточные дедлайны, увеличить частоту отчётности, детализировать задачи, трекать время и пр. Потому что на очередной планерке с CEO Феденьке придется отвечать почему проект не укладывается в намеченные сроки. В этот момент редко обсуждают системные причины. Фокус смещается на оперативное управление - нужно “показать контроль”.

Иногда это действительно помогает. Но если проблема системная, контроль становится только дополнительной нагрузкой. Команда тратит больше времени на синхронизацию, чем на работу. Становится некомфортно работать под давлением всей команде, включая Федора. Растет негатив. Симптом усиливается, а причина остаётся.

Усиление контроля создаёт ощущение управляемости, но системная эффективность может снижаться, потому что энергия команды уходит в обслуживание процесса.

Что действительно стоит диагностировать

Когда сроки начинают сдвигаться, полезнее задать не вопрос “кто не успел”, а вопрос “где модель расходится с реальностью”. Результат сформулирован достаточно конкретно? Границы объёма зафиксированы? Допущения пересматриваются или считаются неизменными? Приоритет проекта стабилен или постоянно меняется? А что делать с изменениями в требованиях? Чаще всего ответы лежат именно там.

Про зрелость процесса

Я думаю, когда сроки начинают “плыть”, проблема почти никогда не в скорости работы команды. Почти всегда это управленческое допущение, которое вовремя не пересмотрели.

В зрелых командах сдвиг сроков не становится трагедией, он становится сигналом. Его анализируют не на уровне конкретной задачи, а на уровне проектной конструкции.

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

Это не быстрые решения, но они снижают вероятность повторения симптома.

Сдвиг сроков - это лишь видимая часть, вершина айсберга. Реальные причины почти всегда находятся глубже, в устройстве системы.

Почему это важно менеджеру

Менеджер Федя, который борется только с датами, остаётся координатором календаря. Ему приходится играться с постоянной перестановкой дат, лавировать умело между валом срочных задач так, чтобы уложиться во все сроки, не разочаровать команду и не выслушивать потом от бизнеса почему в разработке сидят такие некомпетентные люди.

Сдвиг сроков - это всегда неприятно. Но это один из самых честных индикаторов качества управления и стабильности системы, и зрелости компании. Он показывает, насколько проект управляется реальностью, а не ожиданиями. И если сроки регулярно “едут”, возможно, дело не в людях и не в оценке. Возможно, система стабильно производит иллюзии.