Кто и как на самом деле управляет сроками в Project Management
Сроки в ИT-проектах не срываются, они изначально формируются системой так, что становятся недостижимыми.
В первой части мы разобрали, почему Project Manager не управляет сроками, несмотря на процессы, опыт и инструменты. Но тогда возникает более неудобный вопрос: если не он, то кто на самом деле определяет, когда будет готов продукт?
Интуитивным ответом будет — команда, оценки, планирование, а вот рациональным — все намного сложнее. В современных ИT-проектах сроки не являются результатом точного расчета, они появляются как побочный эффект системы: множества зависимостей, ограниченной загрузки, постоянно меняющихся приоритетов и неизбежной неопределенности.
Мы продолжаем думать о сроках как о цели, достижимой при достаточном контроле, но на практике срок — это результат взаимодействия факторов, которыми никто полностью не управляет. Именно поэтому проекты с опытными командами, зрелыми процессами и внедренным Agile продолжают системно сдвигаться.
Во этой статье я разберу, как на самом деле формируются сроки и почему попытки «управлять ими напрямую» почти всегда приводят к противоположному результату.
Иллюзия: сроки как результат планирования
В классическом представлении сроки — это логичный результат планирования: команда оценивает задачи, формируется roadmap, фиксируется дедлайн как цель, к которой нужно прийти.
Эта модель выглядит убедительно, потому что она проста: есть оценка, план и ожидаемый результат. Но в реальности такая цепочка не работает. Оценки создаются в условиях неполной информации:
- неизвестны все зависимости
- не учтены будущие изменения
- игнорируются внешние факторы
В результате оценка превращается из прогноза в гипотезу на момент времени.
Roadmap, в свою очередь, воспринимается как план, но фактически является лишь визуализацией текущих ожиданий, которые неизбежно изменятся.
Дедлайн становится не следствием расчетов, а фиксированной точкой давления, к которой начинают подгонять систему.
В итоге происходит подмена:
- оценки ≠ реальность
- план ≠ система
План существует отдельно от того, как на самом деле работает проект. И чем сложнее система, тем быстрее этот разрыв становится критическим.
Реальность: сроки формируются системой
Если отказаться от представления, что сроки — это результат планирования, то можно увидеть, как они формируются на самом деле.
Формула срока:
срок = зависимости + загрузка + неопределенность + приоритеты
Любой современный ИT-проект — это не набор задач, а система взаимосвязанных факторов, каждый из которых влияет на итоговый срок.
Первый фактор — зависимости
Проект всегда представляет собой сеть связей: между командами, компонентами системы, внутренними и внешними сервисами. Каждая такая связь — потенциальная точка задержки. И чем сложнее система, тем выше вероятность, что именно зависимость, а не скорость работы команды определит итоговый срок.
Второй фактор — загрузка
Планируемая загрузка почти никогда не совпадает с реальной. В процессе появляются срочные задачи, баги, поддержка, команды вынуждены переключаться между приоритетами. В результате фактическая скорость выполнения системно оказывается ниже ожидаемой.
Третий фактор — неопределенность
Не все можно предсказать заранее: требования меняются, возникают технические сложности, внешние системы ведут себя непредсказуемо. Значительная часть работы становится понятна только в процессе, что автоматически влияет на сроки.
Четвертый фактор — приоритеты
Бизнес постоянно меняет фокус: появляются новые инициативы, срочные задачи, пересматриваются стратегические цели. Это приводит к перераспределению ресурсов и неизбежному сдвигу сроков.
В итоге срок не «назначается» и не «контролируется», а является результатом взаимодействия всех этих факторов.
Они не существуют изолированно, а усиливают друг друга, формируя систему, в которой итоговый срок возникает динамически. Именно поэтому попытки управлять сроками напрямую почти всегда приводят к ошибке: управление происходит не на уровне причины, а на уровне симптома.
Как только один из факторов увеличивается, система начинает терять предсказуемость:
- Больше зависимостей — больше блокеров и эффект домино.
- Выше загрузка — медленнее реакции и длиннее цикл выполнения.
- Больше неопределенности — оценки устаревают почти сразу.
- Частая смена приоритетов — план перестает отражать реальность.
И тогда правильный вопрос, который нужно задать, звучит как не «когда мы закончим», а «какой из факторов сейчас разрушает предсказуемость и что с ним можно сделать».
Возвращение к кейсу
Вернемся к кейсу запуска платежной системы на рынке Латинской Америки.
На первый взгляд ситуация выглядела типично: несколько команд, четкий дедлайн, понятный объем работ. Все двигалось по плану до момента, когда система начала проявлять себя.
Ключевой фактор — зависимость от внешнего провайдера.
Именно она стала точкой, после которой вся система потеряла устойчивость. Изменение API со стороны провайдера добавило неопределенность, которую невозможно было заранее учесть в оценках.
В этот момент включился следующий фактор — загрузка. Команды уже работали на высокой загрузке, параллельно решая другие задачи, и возможности быстро переработать интеграцию просто не было.
И наконец, приоритеты. Дедлайн был зафиксирован бизнесом и привязан к рыночному событию. Его нельзя было сдвинуть без потерь, но и выполнить в новых условиях стало невозможно.
В результате система пришла к предсказуемому результату, где срок сдвинулся.
Важно, что в этой ситуации не было ошибки в классическом смысле. Ни одна из команд не «провалилась» и процессы работали, как задумано.
Срок сдвинулся не потому, что кто-то ошибся, а потому что система так сработала.
Именно это отличает современные ИT-проекты: результат определяется не качеством отдельных действий, а поведением всей системы.
Какие уроки дает кейс и что можно было сделать иначе
На первый взгляд в этом кейсе нет ошибки в классическом смысле: команды работали, процесс соблюдался, план существовал. Но именно такие ситуации и дают самые ценные уроки, потому что показывают границы привычного управления.
Первый урок: зависимости важнее планирования
Ключевая проблема возникла не внутри команды, а во внешнем провайдере. Это означает, что зависимость была частью критического пути, но не управлялась как риск. Project Manager мог заранее выделить такие зависимости в отдельную категорию и работать с ними иначе: фиксировать интерфейсы, закладывать буферы, планировать альтернативные сценарии интеграции.
Второй урок: загрузка определяет гибкость системы
Команды уже находились на высокой загрузке, поэтому любое изменение автоматически превращалось в задержку. Это не проблема исполнения, а проблема capacity. Чтобы снизить риск, необходимо было изначально избегать полной утилизации ресурсов: оставлять резерв под изменения, ограничивать параллельную работу и не доводить систему до состояния, где она не способна адаптироваться.
Третий урок: неопределенность нельзя игнорировать, ее нужно делать видимой
Изменение API не было предсказуемым событием, но сама возможность таких изменений была вполне предсказуема. В подобных интеграциях неопределенность должна учитываться явно: через отдельные буферы, фазу стабилизации или постепенное подключение, а не «вшиваться» в общий план как будто ее нет.
Четвертый урок: фиксированный дедлайн без управляемых факторов — это риск, а не ориентир
Если срок жестко привязан к внешнему событию, но ключевые факторы (зависимости, загрузка, неопределенность) не контролируются, то фактически это не план, а ставка.
Project Manager не мог «предотвратить» сдвиг полностью, но мог изменить поведение системы. Именно это и есть реальное управление сроками, где важно не давление на результат, а работа с условиями, в которых этот результат формируется.
Почему velocity и оценки не работают
В Agile-среде принято считать, что сроки можно контролировать через метрики: velocity, story points, прогнозирование по спринтам. Эти инструменты действительно создают ощущение управляемости, но только на уровне отдельной команды.
Velocity — это локальная метрика
Она показывает, с какой скоростью конкретная команда выполняет задачи в стабильных условиях, но проект редко ограничивается одной командой. Как только появляются зависимости между командами, сервисами или внешними системами, то velocity перестает быть индикатором реального срока.
Story points — это абстракция
Они помогают оценивать относительную сложность задач, но не учитывают внешние факторы: блокеры, интеграции, изменения требований. В результате оценка становится удобной для планирования внутри команды, но мало что говорит о сроках на уровне проекта.
Главная проблема в том, что ни velocity, ни оценки не учитывают системные зависимости. Они измеряют производительность отдельного элемента, игнорируя поведение всей системы. Именно поэтому команды могут стабильно выполнять спринты, а вот проект в целом будет продолжает сдвигаться.
Если перевести это на операционный уровень, то картина становится гораздо яснее.
Работа с зависимостями — это не про «уменьшить их количество» в целом, а про критический путь.
На практике это означает:
- убирать кросс-командные зависимости из критического пути, даже если они остаются в системе
- фиксировать интерфейсы и контракты заранее, чтобы снизить риск изменений в последний момент
- по возможности изолировать части системы, чтобы команды могли двигаться независимо
Ограничение нагрузки — это не про «работать меньше», а про управление потоком.
Конкретные действия здесь выглядят так:
- вводить WIP-лимиты (Work In Progress) на уровне команды и проекта
- ограничивать количество параллельных задач, даже если «все срочно»
- явно резервировать capacity под баги, поддержку и непредвиденные задачи
Разница здесь принципиальная: абстрактные рекомендации создают ощущение контроля, а операционные действительно меняют поведение системы.
И именно на этом уровне управление сроками начинает работать не через давление, а через настройку самой системы.
Почему даже опытные менеджеры не могут «ускорить» проект
Идея о том, что сильный Project Manager способен «разогнать» проект, глубоко укоренилась в индустрии. Предполагается, что за счет опыта, давления или оптимизации процессов можно сократить сроки и вернуть проект в график.
На практике это почти никогда не работает.
Во-первых, нельзя ускорить bottleneck — узкое место системы.
Если задержка возникает в одной точке, вся система будет ждать именно ее. Ускорение других частей не влияет на общий результат.
Во-вторых, невозможно ускорить внешние зависимости.
API провайдеров, подрядчики и другие команды работают по своим приоритетам и вне зоны прямого контроля.
В-третьих, нельзя ускорить хаос.
Когда в системе высокая неопределенность, постоянные изменения и перегруженные команды, любые попытки «ускорения» приводят лишь к дополнительным сбоям.
В результате усилия менеджера не сокращают срок, а перераспределяют задержки внутри системы.
Что на самом деле можно контролировать
Если сроки формируются системой, а не планом, это не означает, что управлять ими невозможно. Это лишь означает, что меняется сам объект управления.
Вместо попытки контролировать конечный срок, имеет смысл работать с факторами, которые на него влияют.
Прозрачность системы
Понимание реальных зависимостей, загрузки команд и текущих ограничений позволяет видеть, где возникают риски, а не узнавать о них постфактум.
Их нельзя устранить полностью, но можно сокращать их количество, упрощать взаимодействие и снижать критичность отдельных точек отказа.
Нагрузка
Перегруженная система теряет гибкость. Ограничение количества параллельной работы повышает предсказуемость и снижает вероятность сбоев.
Приоритеты
Хотя они задаются бизнесом, их можно обсуждать, пересматривать и выравнивать с реальными возможностями системы.
При этом важно признать ограничения. Невозможно управлять полной предсказуемостью, контролировать внешние изменения или «ускорить» всю систему целиком. И чем лучше настроена система, тем выше вероятность того, что срок будет достигнут не за счет давления, а за счет устойчивости.
KPI: когда управление противоречит системе
Если сроки действительно формируются системой — зависимостями, загрузкой, неопределенностью и приоритетами, — то логично ожидать, что и KPI будут отражать эту реальность, но на практике происходит обратное.
Метрики по-прежнему завязаны на фиксированные сроки. Дедлайны превращаются в обязательства, планы — в контракт, а любое отклонение — в повод для давления. Команды оцениваются не по устойчивости системы, а по точности попадания в заранее заданную дату.
Здесь возникает фундаментальное противоречие.
С одной стороны, живая, динамическая среда, где сроки являются результатом множества меняющихся факторов.
С другой — метрики, которые требуют, чтобы этот результат был известен заранее и строго соблюден.
Система не может выполнить это требование напрямую и начинает адаптироваться.
- оценки занижаются, чтобы создать «буфер»
- риски скрываются, чтобы не портить прогноз
- команды перегружаются, чтобы удержать срок любой ценой
- качество становится переменной, которой жертвуют первой
Формально показатели могут выглядеть лучше, но фактически система теряет устойчивость и накапливает напряжение.
И здесь важно перейти от общих наблюдений к конкретным выводам.
Если KPI усиливают перегрузку и скрывают риски, значит проблема не в командах, а в самих метриках. Более того, это объясняет, почему срывы сроков повторяются: они не являются исключением, они встроены в модель управления.
В этот момент меняется сам вопрос, он звучит не «как заставить команды работать быстрее», а «какие метрики искажают поведение системы», «где KPI поощряют локальную оптимизацию вместо системного результата» и «какие сигналы мы игнорируем, потому что они портят картину».
И отсюда следует ключевой вывод: проблема сроков — это не проблема исполнения, это проблема того, как устроено управление.
Пока KPI требуют предсказуемости там, где есть неопределенность, система будет искажать реальность, чтобы им соответствовать. И чем сильнее давление через сроки, тем ниже прозрачность и выше накопленная перегрузка.
Снаружи это выглядит как дисциплина, а внутри как системная ошибка.
В следующей статье мы разберем, почему KPI сверху системно ломают delivery и как именно они создают перегрузку, которую затем пытаются «лечить».
Опубликовано 09.07.2026
