Сроки проекта

Алексей Воронцов

Сроки проекта

Введение. Почему срок срывается раньше, чем наступает дедлайн

Есть ощущение, знакомое почти каждому руководителю проекта: срыв срока чувствуется задолго до того, как приходит сама дата дедлайна. Календарь ещё показывает, что времени достаточно. Заказчик ещё не звонит с вопросом «как у нас дела». Команда ещё не паникует. А внутри уже холодок — вы знаете, что не успеете, но пока молчите. Даже себе не признались до конца.

Именно в этой точке срок и срывается. Не в день дедлайна — тогда происходит только фиксация факта. Срок срывается в момент, когда становится ясно, что план не соответствует реальности, а решение отложено «на потом, разберёмся по ходу».

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

Руководитель проекта редко ошибается в арифметике. Он умеет складывать дни и недели, умеет читать диаграмму Ганта, умеет посчитать, сколько задач осталось. Ошибка почти никогда не в расчётах. Она в самообмане — в готовности поверить в удобную версию реальности, а не в проверенную.

«Должны успеть» — это не план. Это надежда, одетая в костюм плана. И проблема не в надежде — надеяться не грех. Проблема в том, что надежда часто заменяет проверку. Руководитель смотрит на календарь, видит, что даты вроде бы сходятся, и не задаёт следующий вопрос: а что должно произойти, чтобы это было правдой? Какие условия должны выполниться, каких рисков не должно случиться, что должно пойти без сбоев?

Возьмём простой пример. Есть задача на пять дней. Исполнитель говорит: «Пять дней, должен успеть». Руководитель ставит в план пять дней. Проходит три дня — исполнитель ещё работает, но не отчитывается, потому что «пока рано, доделываю». Проходит пять дней — задача не готова, потому что оценка не учитывала интеграцию с другим модулем, который тоже задерживается. Руководитель узнаёт об этом на шестой день, когда уже поздно перестраивать план без потерь.

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

Управление сроками часто путают с составлением графика. Составить график — не сложно: открыл таблицу, расставил даты, нарисовал стрелочки зависимостей, показал заказчику красивую диаграмму. Задача управления сроками начинается не в момент составления графика, а в момент, когда график начинает расходиться с реальностью — а это происходит почти всегда, и почти сразу.

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

Здесь и рождается разница между руководителем, который «держит календарь», и руководителем, который «отчитывается по календарю». Первый видит расхождение на третий день и меняет объём работ, привлекает ресурс или честно предупреждает заказчика. Второй видит расхождение на пятнадцатый день, когда уже нужно либо врать, либо оправдываться, либо героически спасать проект авралом, выдавая это за нормальную практику.

Аврал — отдельная тема этой книги, потому что аврал — это не признак усердия. Это признак того, что срыв срока управлялся неправильно на всех предыдущих этапах. Когда команда работает по ночам за неделю до сдачи — это не подвиг, а последствие того, что раннее предупреждение не сработало, либо его не было вовсе.

Вы держите четвёртую книгу серии «Профиль руководителя проекта». Первая книга была посвящена коммуникациям с заказчиком — тому, как договориться о результате. Вторая — целям и результату, тому, как довести проект до проверяемого итога. Третья — содержанию проекта, тому, как удержать границы работ и не утонуть в изменениях. Эта книга — логичное продолжение: когда результат определён, а границы содержания удержаны, остаётся главный практический вопрос — когда это будет готово. И, что важнее, как узнать заранее, если «когда» начинает смещаться.

Управление сроками — это не про пунктуальность и не про строгость календаря самого по себе. Это про честность с самим собой, с командой и с заказчиком относительно того, сколько времени реально нужно, и про готовность вовремя сказать вслух, если реальность расходится с планом.

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

Прежде чем двигаться дальше, задайте себе один вопрос, который будет сопровождать всю книгу: если бы сегодня кто-то спросил вас, успеваете ли вы к сроку, вы бы ответили правду — или удобную версию правды?

Суть компетенции «Управление сроками проекта»

Срок как договорённость о реальности

Срок в проекте часто воспринимается как цифра в календаре: 15 сентября, конец квартала, «через два месяца». Но по сути своей срок — это не дата. Срок — это договорённость о том, каким будет мир в этот момент времени: что будет готово, что можно будет показать, что можно будет использовать.

Когда заказчик слышит «сделаем к 15 сентября», он слышит не абстрактную дату. Он слышит обещание конкретной реальности: к этому дню будет работающий продукт, обученные пользователи, закрытые вопросы. Руководитель проекта, который называет дату, на самом деле подписывается под этой картиной будущего — целиком, а не только под цифрой.

Отсюда следует важное практическое правило: срок нельзя обсуждать в отрыве от объёма и качества. «Успеем ли к 15 сентября» — вопрос без смысла, если не уточнено, к какому именно результату. Успеть можно почти всегда, если снижать требования к результату по ходу дела. Вопрос в том, готовы ли стороны договориться об этом явно, или снижение объёма произойдёт тихо, а потом всплывёт как неприятный сюрприз.

Срок как договорённость о реальности означает, что руководитель проекта не просто фиксирует дату — он проверяет, совпадает ли представление о будущем у заказчика, у команды и у него самого. Часто выясняется, что не совпадает. Заказчик считает, что к сроку будет готово «всё». Команда считает, что успеет «основное». Руководитель молча надеется, что как-нибудь сойдётся. Это не договорённость — это три параллельных монолога, которые случайно происходят в одно и то же время.

Хорошая договорённость о сроке звучит конкретно: «к 15 сентября будет готов модуль оплаты с тестированием на реальных транзакциях; интеграция с бухгалтерией переносится на следующий этап». Это не расплывчатое обещание, а описание состояния мира на конкретную дату, согласованное всеми сторонами.

План, календарь, последовательность работ

План — это не список задач. План — это гипотеза о том, в каком порядке и с какой скоростью работа должна происходить, чтобы результат появился к нужному моменту. Гипотеза, а не пророчество. Именно поэтому план нужно постоянно сверять с реальностью, а не воспринимать как окончательный документ, вывешенный на стену.

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

Последовательность работ — это то, что определяет, какая задача должна закончиться, чтобы началась следующая. Здесь чаще всего рождается путаница: руководители склонны воспринимать список задач как перечень, а не как цепочку. Но задачи редко существуют независимо друг от друга. Тестирование не может начаться раньше, чем закончится разработка нужного модуля. Обучение пользователей не имеет смысла раньше, чем система стабилизируется. Согласование дизайна должно случиться раньше, чем начнётся вёрстка.

Ошибка, которая рождает сорванные сроки чаще, чем любая другая, — восприятие плана как списка дел, а не как цепочки причин и следствий. Список можно закрывать в любом порядке. Цепочка — нет. И если руководитель управляет списком, а не цепочкой, он не увидит момент, когда одна задержка автоматически сдвигает три следующих.

Зависимости

Зависимость — это связь, при которой начало или завершение одной работы влияет на возможность начать или завершить другую. Зависимости бывают внутри команды («дизайн должен быть готов до начала вёрстки»), между командами («интеграция зависит от API, который делает другой отдел»), и внешние («получение доступа к серверу зависит от службы безопасности заказчика»).

Внешние зависимости — самые опасные, потому что руководитель проекта не управляет ими напрямую. Он может договориться, попросить, напомнить — но не может заставить чужой отдел или внешнего подрядчика работать быстрее. Именно внешние зависимости чаще всего «всплывают поздно»: о них забывают в начале планирования, потому что они не в зоне видимости команды, а вспоминают о них, когда уже нужно начинать работу, а условие не выполнено.

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

Хорошая практика — задавать вопрос не «что мы должны сделать», а «от чего зависит то, что мы должны сделать». Этот второй вопрос почти всегда вскрывает то, что не попало в план с первого раза.

Буферы

Буфер — это специально выделенное время на непредвиденное. Не на лень, не на «а вдруг я не успею», а на статистически неизбежные события: задача оказалась сложнее, человек заболел, тестирование нашло больше ошибок, чем ожидалось, зависимая команда задержала свою часть.

У буфера плохая репутация в культурах, где ценится жёсткость плана. Буфер воспринимают как слабость: «если ты просишь запас времени, значит, не уверен в своей оценке». Это опасное заблуждение. Отсутствие буфера — не признак уверенности, это признак того, что весь риск проекта переносится на самый неподходящий момент — конец, когда его меньше всего можно компенсировать.

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

Контрольные точки

Контрольная точка — это момент, когда происходит осознанная проверка: где мы находимся относительно плана. Не отчёт для галочки, а честная сверка ожиданий с реальностью.

Контрольная точка отличается от обычного статуса тем, что она заранее определена как момент принятия решения. На контрольной точке руководитель проекта не просто фиксирует прогресс — он отвечает на вопрос: продолжаем по плану, или нужно что-то менять — состав работ, ресурсы, сам срок?

Частая ошибка — расставлять контрольные точки редко, «чтобы не дёргать команду». Это ложная забота. Чем реже контрольные точки, тем позже руководитель узнаёт о проблеме, и тем меньше у него остаётся возможностей на неё отреагировать. Частые контрольные точки — это не микроменеджмент. Это способ поймать расхождение, пока оно маленькое.

Оценка через диапазоны

Одна дата в оценке — это иллюзия точности. «Сделаю за пять дней» звучит уверенно, но на практике почти любая нетривиальная задача имеет разброс: минимально возможное время при удачном раскладе и реалистичное время с учётом обычных сложностей.

Оценка через диапазон («от трёх до семи дней, вероятнее — пять») звучит менее эффектно, но она честнее и полезнее. Диапазон заставляет задуматься о факторах неопределённости: что может пойти не так, какие допущения делаются, что нужно, чт��бы получился минимальный срок.