Сервисы, считающие деньги сегодня, выжили — методология встала на паузу

Контекст

Группа испытательных лабораторий, открывающая новые площадки в нескольких городах. Работа идёт с середины 2025 года.

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

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

Что болело

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

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

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

В предметной части болело другое. Отраслевые расчёты для клиентов делались вручную на стороннем калькуляторе, и путаницу усиливало то, что одновременно действовали две редакции нормативной базы с разными ставками и разными основаниями расчёта. Клиенты компании ждали, пока эксперт посчитает и перепроверит.

Как подходил

Работа шла по пяти направлениям одновременно, и это сознательный выбор: методология без инструментов остаётся презентацией, а инструменты без методологии — набором ботов.

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

Методология. Устав, установочная встреча с руководителями, курс «Современные методы проектного управления в различных организационных культурах» — введение и семь модулей с конспектами и презентациями.

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

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

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

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

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

Что мешало и что не получилось

Это самый содержательный такт кейса.

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

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

Ассистент руководителя не выполнил задание — и это сформулировали лучше, чем сформулировал бы я. Со стороны клиента прозвучало: бот «не выполняет ключевой функции — он не ассистирует РУКОВОДИТЕЛЯ, он делает отчёт по задачам одного человека. Это облегчает жизнь, но не выполняет ТЗ». Разбор развилки — привязывать команду к руководителю или привязывать очереди задач — был сделан, а переработка приостановлена вместе со всем остальным.

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

Дисциплина фиксации не прижилась. В рабочем инструменте были заведены типы записей «гипотеза» и «инцидент» — ровно для того, чтобы накапливать знание о том, что сработало и что сломалось. За весь проект ими не воспользовались ни разу. Честнее иллюстрации того, почему методология не доживает до практики, я не встречал.

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

Двойной провал одной идеи. Попытку автоматически переносить снимок физической доски с заметками в цифровую пробовали двумя разными способами; в результатах обоих записано «не заработало». Ветку закрыли, потраченное время осталось.

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

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

Итоговая документация по сервисам была оформлена спустя месяцы после активной разработки, задним числом.

Что стало

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

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

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