Проект, рассчитанный на шесть недель, редко идёт год потому, что кто-то плохо работал. Он идёт год потому, что стоял. Разработка в таких проектах занимает столько же, сколько заняла бы в срок; всё остальное время уходит на ожидание доступов, людей, данных и решений — и это время в отчётах не отражается никак, потому что в нём ничего не происходит.
Ниже разобран модельный случай: автоматизация обработки заявок в компании на 90 человек, бюджет 420 000 ₽, план — шесть недель, факт — 317 календарных дней. Из них проект реально двигался 101 день, а 216 дней ждал. Это не исключительный случай и не история про плохого подрядчика: тот же инженер в том же составе на соседнем проекте уложился в срок.
Важно то, как это выглядело изнутри. Ни одна из семи пауз в момент возникновения не была ошибкой. Каждая была разумным решением, принятым разумными людьми по разумной причине. Никто ни разу не сказал «давайте задержим проект на девять месяцев» — просто семь раз подряд оказалось, что подождать неделю сейчас правильнее, чем не ждать.
Хронология: 317 дней, из которых 216 проект стоял
Порядок пауз важнее их длительности. Первые две выглядят техническими мелочами и создают ощущение, что проект «немного сдвинулся». Именно оно и разрешает третью и четвёртую: раз уж всё равно не по плану, можно и добавить требований. Дальше проект теряет статус срочного, и его начинают двигать все остальные приоритеты компании.
- 1Доступ к учётной системе — 16 дней. Запрос ушёл в обслуживающую франчайзи, там его получил не тот человек. Никто не был неправ, просто у запроса не было владельца ни с одной стороны.
- 2Отпуск владельца процесса — 21 день. Замену не назначили: «две недели подождём, всё равно без него сценарии не согласовать». Формально верно. Фактически — первый месяц без работы.
- 3Четыре новых требования от смежного отдела и пересмотр ТЗ — 34 дня. Классическая логика простоя: раз уж стоим, давайте заодно добавим то, о чём давно думали. Требования разумные, но проект стал другим.
- 4Тестовая выгрузка не получилась — 38 дней. В базе не оказалось поля, которое обе стороны считали обязательным. Пока решали, где его брать, прошло больше месяца.
- 5Смена коммерческого директора — 31 день. Новый руководитель попросил показать, что получается, и пересмотреть приоритеты. Абсолютно нормальное требование нового человека в должности.
- 6Закрытие года — 29 дней. ИТ и бухгалтерия недоступны, и это правильно: в закрытие их трогать нельзя. Плюс новогодние праздники сверху.
- 7Инженера сняли на другой проект и вернули — 47 дней. Единственная пауза на стороне подрядчика, и возникла она ровно потому, что проект стоял: свободного инженера держать на паузе никто не будет.
Подрядчик снимает инженера с проекта не из вредности, а потому что проект не двигается по причинам, на которые подрядчик не влияет. Это самая опасная точка всей хронологии: до неё простой можно было прекратить одним решением заказчика, после неё — уже нельзя, потому что нужен ещё и свободный инженер. С этого момента срок перестаёт зависеть от вас.
Горизонтальная лента времени на 317 календарных дней, размеченная по месяцам. Плотно заштрихованные отрезки — работа, суммарно 101 день: 14 дней обследования и согласований, 42 дня разработки по плану, 45 дней приёмки и доработок. Между ними семь светлых интервалов-пауз с подписями и длительностью: доступы 16 дней, отпуск владельца 21 день, новые требования 34 дня, тестовые данные 38 дней, смена руководителя 31 день, закрытие года 29 дней, инженер снят с проекта 47 дней. Внизу итог: «работа 101 день, простой 216 дней — 68 % календаря».
Где теряются недели: этап за этапом
Если разложить типовой проект на шесть недель по этапам и рядом поставить то, что каждый из них удлиняет, получается практическая таблица: по ней видно, какой именно этап у вас сейчас стоит и что нужно сделать, чтобы он сдвинулся. Разбор того, из чего вообще складывается календарь проекта и почему разработка в нём меньше половины, мы делали отдельно; здесь — только про удлинение.
| Этап | Норма в проекте на 6 недель | Что его удлиняет | Типичная добавка |
|---|---|---|---|
| Доступы к системам | 3–5 рабочих дней, если запрошены до старта | Запрос идёт через обслуживающую организацию; доступ оформлен на личную почту сотрудника | 2–3 недели |
| Обследование и карта процесса | 5 рабочих дней | Владелец процесса не выделен, на вопросы по очереди отвечают трое разных людей | 1–2 недели |
| Согласование сценариев | 3–5 рабочих дней | Согласуют больше двух человек, и ни у одного нет права принять решение | 2–4 недели |
| Тестовые данные | 2 рабочих дня на выгрузку | Нужного поля в базе нет, данные лежат в трёх местах и не сходятся | 2–5 недель |
| Разработка | 12–15 рабочих дней | Новые требования, принятые в работу без пересчёта срока | около недели на каждое требование |
| Приёмка и обучение | 5 рабочих дней | Приёмщик не назначен, акт лежит без подписи, замечания приходят порциями | 2–3 недели |
Три верхние строки — 90 % всех сорванных сроков, и все три закрываются решениями заказчика до старта, а не работой подрядчика. Отсутствие человека, который имеет право сказать «делаем так», удлиняет проект надёжнее любой технической сложности; что именно входит в роль владельца процесса и сколько часов она стоит, мы посчитали отдельно.
Что стоят перезапуски
Остановленный проект не лежит на полке бесплатно. Каждый возврат к нему стоит времени на восстановление контекста: инженер заново поднимает договорённости, перечитывает переписку, проверяет, не изменилось ли что-то в системах за месяц простоя. Владелец процесса тоже возвращается не сразу — ему нужно вспомнить, на чём остановились и что он согласовывал.
Строка отложенной экономии считается только там, где эффект от системы вообще посчитан. Если базовых замеров нет, эта сумма превращается в предмет спора, и обычно её просто не считают — а значит, простой выглядит бесплатным. Именно поэтому замер до старта окупается ещё и здесь: он даёт цену недели простоя, а с ней разговор о сроках перестаёт быть разговором об эмоциях.
Столбчатая диаграмма из трёх столбцов в одном масштабе, ось Y в рублях. Первый столбец — «Бюджет проекта, 420 000 ₽». Второй — «Дополнительные работы из-за пауз, 157 200 ₽» с разбивкой на три сегмента: 84 000 ₽ повторное погружение инженера, 25 200 ₽ повторное погружение владельца, 48 000 ₽ пересмотры ТЗ. Третий — «Отложенная экономия за 9 месяцев, 702 000 ₽». Под диаграммой подпись: «Ни одна из двух правых сумм не попадает ни в один акт и ни в один отчёт».
Срок в договоре: от чего он отсчитывается и кто за что платит
Спор о просрочке в таких проектах не имеет решения, потому что обе стороны правы: подрядчик действительно вышел за срок, заказчик действительно не мешал специально. Единственный способ его не иметь — заранее привязать срок не к дате подписания, а к исполнению встречных обязательств.
- Срок работ отсчитывается от даты, когда заказчик исполнил встречные обязательства, а не от даты подписания договора. Обязательства перечислены приложением: доступы к перечисленным системам, назначенный владелец процесса с указанием часов в неделю, тестовая выгрузка в согласованном формате, назначенный приёмщик.
- Механизм приостановки описан числом. Если встречное обязательство не исполнено, срок сдвигается день в день, и подрядчик обязан уведомить об этом письмом в течение двух рабочих дней. Уведомление, отправленное в конце проекта, не считается: смысл в том, чтобы заказчик узнал о сдвиге в момент его возникновения, а не в момент спора.
- Новые требования не отклоняются, а записываются в отдельный список с датой рассмотрения после приёмки. Процедуру проведения изменений и форму запроса мы разбирали в материале про изменения требований по ходу проекта; здесь важно только то, что новое требование обязано двигать срок явно и письменно, а не растворяться в календаре.
- Заморозка объявляется за 10 рабочих дней до приёмки этапа и снимается одним названным человеком. Без неё приёмка не наступает никогда: каждая демонстрация рождает новую правку.
| Задержка | Кто несёт | Как оформляется |
|---|---|---|
| Доступ не выдан в согласованный срок | Заказчик | Срок сдвигается день в день, письмо-уведомление в течение 2 рабочих дней |
| Владелец процесса недоступен, замена не назначена | Заказчик | То же; в договоре стоит норма 4–6 часов его времени в неделю |
| Новое требование сверх технического задания | Заказчик | Отдельная оценка, отдельный срок, допсоглашение или резерв |
| Тестовые данные не выгружаются в согласованном виде | Заказчик | Срок сдвигается; если данных нет в принципе — это отдельная работа |
| Инженер снят на другой проект | Подрядчик | Срок не сдвигается, при просрочке действует согласованная неустойка |
| Ошибка в оценке трудоёмкости | Подрядчик | Срок не сдвигается, дополнительные часы за счёт подрядчика |
| Обновление смежной системы вендором | Совместная | Срок сдвигается по факту, работа оплачивается как изменение |
Когда сдвиг срока — правильное решение
Не всякая просрочка — провал. Есть четыре случая, когда сдвинуть срок правильнее, чем уложиться в него, и умение их различать экономит больше, чем любая дисциплина календаря.
- Выяснилось, что автоматизируется не тот участок. Здесь торопиться значит быстрее приехать не туда. Правильное действие — остановиться и сузить объём до одного сценария; процедуру перезапуска буксующего проекта за три недели мы описали пошагово.
- Данные оказались хуже, чем считали на старте. Запуск на грязной базе даёт систему, которой не пользуются, и три месяца разбирательств потом. Месяц на приведение данных в порядок дешевле.
- Пришёлся сезонный пик или закрытие периода. Переключать людей на новую систему в неделю максимальной нагрузки — это гарантированный откат к старому способу работы и потерянные деньги на обеих сторонах.
- Сменился владелец процесса. Новому человеку нужны две-три недели, чтобы принять решения, за которые он будет отвечать. Продавливать сроки здесь означает получить формальное согласование и неформальный саботаж.
Сдвиг срока — это решение, у которого есть причина, автор и новая дата, записанная письмом. Дрейф — это отсутствие решения: срок не переносят, его просто перестают упоминать на встречах. Проверка одна: спросите, какая сейчас плановая дата запуска. Если у трёх участников проекта три разных ответа или ответ «когда доделаем» — у вас дрейф, и он будет продолжаться, пока кто-нибудь не назовёт дату вслух.
И общее правило, которое стоит за всей статьёй: срыв сроков — не самостоятельная болезнь, а симптом. Чаще всего под ним лежит либо отсутствие владельца процесса, либо попытка автоматизировать слишком много сразу. Лечить календарь, не тронув причину, бесполезно: следующий план будет сорван так же аккуратно и по тем же семи поводам.
