Буксующий проект спасают не добавлением людей и не новым сроком, а сужением объёма. Процедура занимает три недели: пять рабочих дней на аудит, неделя на сокращение объёма до одного сценария и переоформление границ, неделя на приёмочный прогон с измеримым критерием. Всё остальное — новые требования, доработки, идеи с прошлого совещания — замораживается на этот срок письменно и с датой возврата.
Выглядит буксующий проект спокойно. Ничего не упало, подрядчик отвечает, встречи идут. Просто плановый срок был четыре месяца, а идёт шестой; из одиннадцати сценариев работают три; через систему проходит меньше четверти заявок, а остальные по-прежнему ведутся в таблице и в почте. При этом никто внутри компании не может сказать, что именно должно случиться, чтобы проект считался законченным.
Модельный проект для всех расчётов ниже: договор на 1 240 000 ₽, оплачено 780 000 ₽, остаток 460 000 ₽, плановый срок четыре месяца, идёт шестой. Одиннадцать сценариев в объёме, три работают. Поток — 640 заявок в месяц, через систему проходит 23 %, то есть 147 заявок. Открытых дефектов 34, из них девять старше двух месяцев. Последняя запись в журнале изменений сделана пять недель назад.
Пять дней аудита: шесть зон и артефакт на выходе
Аудит нужен не для того, чтобы найти виноватого, а чтобы получить материал для решения. Поэтому у каждого дня есть артефакт — документ или таблица, которые остаются у компании и после перезапуска. Проводить аудит может внешний инженер, не участвовавший в проекте, или руководитель, если он готов задавать неудобные вопросы всем сторонам, включая себя.
| День | Зона | Что смотрим | Артефакт на выходе | Красный флаг |
|---|---|---|---|---|
| 1 | Сценарии и объём | Все одиннадцать сценариев: статус, кто ими пользуется, сколько раз в месяц срабатывает каждый | Таблица «сценарий — статус — пользователь — частота» | У сценария нет названного пользователя, только «отдел» |
| 2 | Данные | Дубли, пустые обязательные поля, форматы телефонов, справочники, на которые опираются сценарии | Шесть чисел по состоянию базы | Сценарий опирается на поле, заполненное у 12 % записей |
| 3 | Интеграции | Что и куда передаётся, с какой периодичностью, что происходит при отказе приёмника | Схема на одну страницу и список необработанных сбоев | Нигде не видно, что обмен не прошёл — сбой обнаруживается по жалобе |
| 4 | Доступы и журнал изменений | На кого оформлены узлы, кто имеет доступ, что и когда выкатывали за три месяца | Карта узлов и восстановленный журнал | Последняя запись в журнале старше месяца |
| 5 | Реальное использование | Доля потока через систему, число активных пользователей за 14 дней, число обходных путей | Три числа и список мест, где ведётся параллельный учёт | Систему открывает только руководитель и только по понедельникам |
Схема из шести блоков в ряд с подписями: «сценарии и объём», «данные», «интеграции», «доступы», «журнал изменений», «реальное использование». Под каждым блоком — маленький прямоугольник артефакта с подписью: «таблица 11 сценариев», «шесть чисел по базе», «схема на страницу», «карта узлов», «журнал за 3 месяца», «три числа использования». Справа общий блок «Решение: спасать, сузить или остановить». Сверху полоса «5 рабочих дней». Чертёжный стиль, подписи по-русски.
Второй день чаще всего оказывается самым результативным. Проверки состояния базы — дубли, пустые обязательные поля, форматы телефонов — делаются одной выгрузкой за полдня, и они регулярно объясняют, почему сценарий формально готов, а работает через раз. Полный набор проверок и порогов мы разбирали в материале про то, как дубли и пустые поля срывают внедрение.
Правило сужения: один сценарий вместо одиннадцати
Главное решение перезапуска принимается на основании первого дня аудита. Из таблицы сценариев берётся тот, который закрывает наибольшую долю потока, и он остаётся единственным на три недели. В модельном проекте это регистрация и распределение входящей заявки — 390 обращений из 640, то есть 61 % потока. Остальные десять сценариев не отменяются, а переносятся в список «после перезапуска» с датой возврата к обсуждению.
- 1Считаем долю, а не важность. Сценарий выбирается по числу срабатываний в месяц, а не по тому, чей руководитель громче его защищает. Доля берётся из выгрузки обращений за последние 30 дней.
- 2Сценарий должен доходить до конца. Оставляем тот, что закрывает путь заявки от появления до назначенного ответственного. Половина пути даёт половину пользы и полную путаницу.
- 3У сценария есть один названный пользователь. Не «отдел продаж», а конкретные три человека, которые в понедельник начнут работать в системе и с которыми проводится приёмочный прогон.
- 4Остальное замораживается письменно. Список из десяти пунктов с датой возврата. Устная заморозка отменяется первым же совещанием.
- 5Дефекты сортируются по выбранному сценарию. Из 34 открытых дефектов к оставшемуся сценарию относятся 11 — только они попадают в работу, остальные 23 уходят в список вместе со своими сценариями.
Сравнение в две колонки. Левая «Было»: «11 сценариев в объёме», «работают 3», «34 открытых дефекта», «срок не назван», «23 % потока через систему». Правая «Три недели перезапуска»: «1 сценарий — 61 % потока, 390 заявок из 640», «11 дефектов в работе», «критерий приёмки: 70 % две недели подряд», «дата приёмки назначена». Между колонками стрелка с подписью «десять сценариев и 23 дефекта — в список «после перезапуска» с датой возврата». Чертёжный стиль.
Разговор с текущим подрядчиком: артефакты вместо претензий
Цель разговора — новый предмет работ, а не признание вины. Претензия «вы сорвали сроки» даёт спор о причинах, в котором обе стороны правы наполовину и никто не двигается. Предложение «сокращаем объём до одного сценария, вот критерий приёмки, вот дата» даёт решение, которое подрядчику обычно выгоднее вашего: он тоже сидит в проекте без конца.
- 1Показать артефакты, а не оценки
Таблица одиннадцати сценариев со статусами, три числа реального использования, список из 34 дефектов с датами. Это факты, с которыми не спорят. Ощущение «всё идёт медленно» оспаривается легко, таблица с датами — нет.
- 2Предложить новый предмет письменно
Один сценарий, критерий приёмки числом, дата. Оформляется приложением к договору на одну страницу, а не устной договорённостью на созвоне. Приложение подписывают обе стороны до начала трёх недель, иначе через неделю объём начнёт возвращаться.
- 3Договориться о судьбе остатка
460 000 ₽ невыбранного остатка — предмет отдельного решения: часть переносится на замороженные сценарии со сроком 12 месяцев, часть возвращается, часть остаётся резервом на доработку по итогам приёмки. Главное — записать это в том же приложении, а не оставить на «потом разберёмся».
- 4Зафиксировать ритм на три недели
Одна встреча в неделю на тридцать минут, повестка из трёх пунктов: что сделано, что мешает, что нужно от заказчика. Письменное резюме в тот же день. Ежедневные созвоны на буксующем проекте не помогают — они заменяют работу обсуждением работы.
Отдельно про смену подрядчика. Она уместна, когда аудит показал не отставание, а невозможность продолжать: нет исходников, нет доступов, ответы идут через единственного человека. Тогда к сроку и смете добавляется подхват чужого решения — по нашей оценке это 30–60 % стоимости написанного, и как эта цифра считается, разобрано отдельно в материале про то, что делать, если подрядчик исчез. Менять исполнителя только из-за просрочки, не проверив остальные пять зон аудита, — способ потерять ещё три месяца.
Заморозка требований и как её объяснить внутри
Заморозка — самая непопулярная часть процедуры и самая необходимая. Буксующий проект почти всегда буксует не от сложности, а от того, что объём растёт быстрее, чем закрывается: каждое совещание добавляет требование, и подрядчик добросовестно принимает его в работу. Три недели без новых требований — единственный способ увидеть, с какой скоростью команда действительно закрывает задачи.
Открытый список «после перезапуска» ведётся в одном месте, доступном всем: требование, автор, дата поступления, дата возврата к обсуждению. Отказов в нём нет — есть очередь. Это снимает главный конфликт заморозки: человек не борется за своё требование, если видит, что оно записано и у него есть дата. Заморозка без открытого списка воспринимается как «наши задачи никому не нужны» и разваливается за неделю.
Если после заморозки выясняется, что закрывать нечего, потому что решения принимать некому, проблема не в объёме. Роль, без которой перезапуск не работает, разобрана отдельно — владелец процесса и его полномочия; без неё три недели пройдут в согласованиях и закончатся тем же, чем начались.
Новая точка приёмки: 70 % заявок две недели подряд
Критерий приёмки должен быть числом, сроком и способом проверки. «Система работает стабильно» проверить нельзя, поэтому такой формулировкой заканчивается любой затяжной проект. Рабочая формулировка для модельного случая: через систему проходит не менее 70 % входящих заявок в течение двух календарных недель подряд, что при потоке 640 заявок в месяц означает 224 заявки из 320. Сейчас проходит 23 %, то есть 74 заявки за те же две недели.
- Основной критерий — доля потока. 70 % две недели подряд. Считается выгрузкой из системы и сверяется с числом обращений во всех каналах, а не только в системе.
- Вспомогательный критерий — время до назначения ответственного. Не более 15 минут в 90 % случаев. Без него долю можно набить, заводя заявки задним числом в конце дня.
- Ограничение по поддержке — не более трёх обращений на 100 заявок. Если пользователи спрашивают чаще, сценарий не освоен, и доля потока держится на административном ресурсе.
- Способ проверки назван заранее. Кто делает выгрузку, из какого отчёта, в какой день. Иначе приёмка превращается в спор о методике счёта в день приёмки.
График за восемь недель. Горизонтальная ось — недели, вертикальная — доля входящих заявок, прошедших через систему, в процентах. Линия начинается на 23 % и растёт к 70 %. Горизонтальная пунктирная линия на 70 % подписана «критерий приёмки». Последние две недели графика выделены штриховкой с подписью «две недели подряд выше линии — приёмка пройдена». Сбоку подпись «поток 640 заявок в месяц: 70 % за две недели — это 224 заявки из 320». Единицы подписаны.
Три недели по дням и во что они обходятся
Календарь перезапуска короткий и жёсткий: неделя аудита, неделя доработки под один сценарий, неделя приёмочного прогона на боевом потоке. Растягивание любой из недель обнуляет эффект — заморозка требований дольше месяца не удерживается ни в одной компании.
Горизонтальная лента на три недели. Неделя 1 «Аудит»: пять отметок по дням — сценарии, данные, интеграции, доступы и журнал, использование; на выходе «решение и приложение к договору». Неделя 2 «Сужение и доработка»: подписи «1 сценарий из 11», «11 дефектов из 34», «инструкция на две страницы». Неделя 3 «Приёмочный прогон»: подписи «боевой поток», «замер доли по дням», «обучение — два прогона по 90 минут». Под лентой полоса «заморозка требований, открытый список с датами возврата». Чертёжный стиль.
Доработка самого сценария в эту сумму не входит: она уже оплачена в составе 780 000 ₽ и делается в рамках действующего договора. Строка появляется только при смене подрядчика — тогда добавляется подхват. Сравнивать 293 700 ₽ нужно не с нулём, а с продолжением по-старому: остаток 460 000 ₽ по договору и, по фактическому темпу — три сценария за пять месяцев, — ещё около 13 месяцев на оставшиеся восемь. Именно эта пара чисел, а не ощущение усталости, обычно и убеждает всех участников.
Три случая, когда перезапуск не поможет
Перезапуск лечит перегруженный объём и потерянный фокус. Он не лечит ошибку в выборе задачи и отсутствие людей, которые принимают решения. В трёх случаях три недели и 293 700 ₽ будут потрачены впустую, и лучше узнать об этом на пятый день аудита, а не на двадцать первый.
- Выбран не тот процесс. Автоматизируется участок, который срабатывает четыре раза в месяц, или процесс, который в компании ещё не устоялся. Перезапуск здесь только ускорит движение не туда; лечение другое — вернуться к выбору задачи, как в разборе про то, почему сначала нужен порядок в процессе.
- Нет владельца процесса. Решения принимает то один руководитель, то другой, а чаще никто. Тогда сужение объёма не удержится: через неделю в работу вернутся три замороженных сценария, потому что их некому оставить в списке.
- Процесс отменяется или перестраивается. Меняется структура, уходит направление, компания переходит на другую схему работы. Автоматизировать нечего, и это нормальный исход — вопрос только в том, чтобы забрать данные и наработки.
Если после пяти дней аудита ни один сценарий не закрывает существенной доли потока, а реальное использование близко к нулю, перезапускать нечего. Это уже другая развилка, и считается она иначе: сопоставляются предстоящие расходы и предстоящая польза, а вложенные деньги в решении не участвуют. Признаки и арифметику этой развилки мы разобрали отдельно — когда проект пора остановить.
Буксующий проект спасают не скоростью, а вычитанием: пока в объёме одиннадцать сценариев, не будет закончен ни один.
