Блок 8

Управление сроками. Как не срывать дедлайны и видеть риски заранее

Почему дедлайны срываются даже в хороших командах

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

правки;
новые вводные;
задержки согласований;
болезни и отпуска;
технические проблемы;
недооценка сложности.

Поэтому задача PM — не «гарантировать сроки», а управлять вероятностью срыва сроков.

4 причины срыва дедлайнов

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

Если PM смотрит на проект только в момент дедлайна — уже поздно что-то исправлять
Нет раннего выявления рисков

Проблема обнаруживается тогда, когда её уже нельзя исправить без сдвига сроков
Слишком поздняя коммуникация с клиентом

Самая болезненная ошибка — сообщить о проблеме в последний момент

Управление сроками = управление рисками

Если упростить:

сроки = план;
риски = отклонения от плана;
PM = человек, который уменьшает отклонения.

Основная система управления сроками

Любой проект можно контролировать через 5 уровней.

1. Декомпозиция задач

Если проект не разбит на части — им невозможно управлять. Чем меньше задача, тем точнее её срок.

Неправильно
Сделать сайт — 30 дней

Правильно

аналитика — 5 дней;
дизайн — 10 дней;
верстка — 10 дней;
backend — 10 дней;
тестирование — 5 дней.

2. Контроль критического пути

Критический путь — это цепочка задач, которые напрямую влияют на финальный срок проекта.

Например:
Если задержался дизайн → задержалась разработка → задержался релиз.

PM должен всегда знать:

какие задачи критические;
какие задачи можно сдвигать;
где нет запаса времени.

3. Контроль прогресса (milestones)

Если PM смотрит только на финальную дату — он управляет вслепую. Необходимо разбивать проект на контрольные точки:

согласование прототипа;
утверждение дизайна;
готовность верстки;
готовность backend;
тестирование.

Если на 30% проекта уже есть отставание — это сигнал, а не проблема.

4. Раннее выявление рисков

PM должен постоянно задавать один вопрос: Что может пойти не так прямо сейчас?

Клиент
- долго согласует;
- меняет требования;
- не отвечает.
Команда
- перегруз;
- отпуск;
- болезнь;
- недооценка задачи.
Технические риски
- сложная интеграция;
- баги;
- несовместимости.

5. Коммуникация с клиентом

Сроки — это не внутреннее дело команды, а договорённость с клиентом.

Неправильно
Сообщать о проблеме в последний момент

Правильно
Сообщать заранее, когда:

есть риск срыва;
есть первые признаки задержки;
есть отклонение от плана.

Принцип раннего предупреждения

Чем раньше клиент узнаёт о риске — тем проще его решить. Как правильно сообщать о рисках?

Неправильно
— Мы не успеваем

Правильно
— Видим риск сдвига сроков на 2−3 дня из-за задержки согласования дизайна. Сейчас прорабатываем варианты: ускорение этапа или перераспределение задач. Вернёмся с финальным планом завтра

Буферы как инструмент управления сроками

Буфер — это не запас «на всякий случай», а обязательная часть планирования.

Где нужны буферы:

дизайн;
разработка;
согласования;
тестирование.

Например:
Оценка разработчика: 10 дней.
PM планирует: 12−13 дней.

Это не обман, а учёт реальности.

Закон плохих сюрпризов

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

Как видеть риски заранее

Задавай вопрос «Что может сломаться?»

Перед началом каждой задачи
Проверяй зависимости
- что нужно для старта задачи;
- кто даёт материалы;
- кто согласует результат.
Проверяй загрузку команды

Перегруженный специалист = высокий риск задержки
Смотри историю похожих проектов

Если раньше задача занимала 12 дней, то сейчас она не может быть сделана за 5

Типичная модель срыва сроков

Очень важно понимать цепочку.

небольшое отклонение;
игнорирование;
накопление задержки;
«всё нормально»;
резкий срыв дедлайна.

PM должен ловить проблему на шаге 1.

Красные флаги проекта

Это сигналы, что сроки под угрозой:

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

Как контролировать проект по срокам

Ежедневно
- статус задач;
- блокеры;
- прогресс.
Еженедельно
- общий статус проекта;
- риски;
- отклонения от плана.
Перед ключевыми этапами
- проверка готовности;
- проверка зависимостей;
- проверка материалов.

Как PM должен реагировать на задержки

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

Кейс

Дизайн задержался на 3 дня и разработка ещё не началась. Вы скажете: «Ничего страшного, наверстаем.», но опытный PM пересчитает сроки и оценит влияние на backend и тестирование. Сообщит клиенту апдейт по срокам и найдет возможность компенсировать задержку.

Подведём итог

Управление сроками — это не попытка «угадать дату». Это постоянный процесс:

наблюдения;
анализа;
корректировки;
коммуникации.

Опытный PM не тот, кто никогда не срывает сроки, а тот, кто заранее понимает, когда сроки находятся под угрозой, и умеет управлять ситуацией до того, как она станет проблемой.

Перейти в блок 9 | Финансы. Как считать бюджет, маржу и не работать в минус

Вернуться в предыдущий раздел