Первая версия увеличила производственный цикл в три‑четыре раза. Мы продолжили

История провалившегося алгоритма планирования — и того, что на самом деле создаёт проектный менеджер

Детали производства частично обезличены из‑за NDA. Диалоги восстановлены по памяти, логика событий и численные параметры сохранены.

— Это не программируется. Я сам не могу объяснить, почему двигаю именно эту операцию. Просто смотрю на план и вижу.

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

Технологи с самого начала предупреждали, что производственные программы почти не повторяются, а каждый новый план приходится продумывать заново. Разработчики реализовали ровно то, что мы им дали. А я четырьмя месяцами раньше объяснял директору по производству, что алгоритм планирования — понятная инженерная задача.

---

Формально корректный план

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

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

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

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

Первая версия системы появилась через четыре‑пять месяцев после начала разработки. Программа выполнялась без ошибок, распределяла операции по рабочим центрам и соблюдала формальную последовательность переделов.

Технологи поняли, что план непригоден, за несколько минут.

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

На разборе одного из таких планов присутствовали технолог, аналитик, разработчик и я. Технолог посмотрел на график и повторил то, о чём говорил с самого начала:

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

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

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

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

Аналитик спросил, почему технолог выбрал именно эту операцию и почему передвинул её именно на тридцать минут.

— Не могу объяснить. Это не программируется. Просто смотрю на план и вижу.

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

У каждой стороны появились основания остановиться. Технологи получили подтверждение, что линейная модель не понимает производство. Разработчики реализовали согласованные требования и не получили новых однозначных правил. Бизнес уже оплатил несколько месяцев работы над системой, которая планировала хуже Excel.

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

Последний раз, когда я слышу слово «почти»

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

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

Он согласился без энтузиазма:

— Хорошо. Но это последний раз, когда я слышу от вас слово «почти».

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

У проверки была ближняя граница. Если каждую ручную корректировку можно объяснить только уникальным сочетанием обстоятельств, а аналитики не находят признаков, повторяющихся на разных планах, гипотеза о формализуемой логике не подтверждается. Проект останавливается.

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

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

Как аналитик нашёл алгоритм в чужой интуиции

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

Первый разобранный план доказывал только то, что принятое решение можно объяснить задним числом. Для продолжения проекта требовалось найти механизм, воспроизводимый на разных производственных программах.

Перелом произошёл во время очередного разбора. Аналитик решил, что технолог начинает с места, где на графике возникает простой:

— Вы видите пустое окно и двигаете ближайшую предыдущую операцию, чтобы его закрыть?

Технолог покачал головой:

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

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

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

Когда аналитик сформулировал это правило, технолог некоторое время смотрел на график, а затем сказал:

— Получается, да. Только я никогда так это не называл.

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

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

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

Один из них ответил коротко:

— Мы сделали ровно то, что было в требованиях.

Он был прав. Требования собирал не он.

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

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

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

Где заканчивается экспертиза эксперта

Технологи были правы в оценке сложности. Они были правы и в том, что фиксированная последовательность не сможет планировать постоянно меняющееся производство.

Но их мнение о принципиальной невозможности формализовать собственные решения не являлось экспертным заключением.

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

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

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

Именно так менеджеры и разрушают проекты: игнорируют предупреждения инженеров, называют объективные ограничения сопротивлением изменениям, а после провала обвиняют команду в недостаточной гибкости.

Такое происходит постоянно. Есть руководители проектов, чья работа сводится к переносу встреч, покраске статусов и вопросу «ну что там?». Они не создают ценность. Они потребляют время специалистов, превращают работу в отчётность и первыми выходят на сцену, когда нужно рассказать об успехе.

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

В нашем проекте после провала первой версии каждый участник сделал профессионально обоснованный вывод. Технологи увидели, что система не понимает производство. Разработчики не получили правил, которые можно реализовать. Бизнес увидел расходы и непригодный результат.

Никто не ленился и не саботировал проект. Каждый был прав внутри своей области ответственности.

Сумма этих правильных выводов давала общее поражение.

Проектное управление требуется именно там, где сумма локально правильных выводов приводит к общему поражению.

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

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

Менеджер ничего не создаёт

Разработчик может показать код. Архитектор — схему. Аналитик — модель. Технолог — правила, без которых система не заработает. Руководитель проекта редко способен предъявить собственный вклад так же наглядно.

Нельзя положить на стол разговор, после которого проект не закрыли. Нельзя открыть в системе момент, когда первая неудача перестала считаться доказательством невозможности. Со стороны всё это выглядит как совещания, переписка и напоминания.

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

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

Моим решением было продолжить поиск после того, как первая версия дала основания всё остановить, и определить условия, при которых продолжение имеет смысл.

Можно ли считать это созданием результата?

Я считаю, что да.

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

Это не делает руководителя проекта главным автором и не даёт ему права присваивать чужой труд. Технологи создали знания. Аналитики помогли превратить их в модель. Разработчики сделали модель исполняемой.

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

Все задачи завершены, а мир остался прежним.

Цена результата, который нельзя назвать своим

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

Это даёт быстрое и понятное профессиональное удовлетворение: сделал, проверил, увидел результат.

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

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

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

За возможность отвечать за целое приходится отдавать личное авторство.

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

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

Если вы никогда этого не делали, вы пока не знаете, нужна ли вам профессия руководителя проекта. Новая должность сама по себе этого не покажет.

После проекта

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

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

Пользователь просмотрел результат и продолжил работать.

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

Никакого восторга, никакой церемонии, никаких разговоров о цифровой трансформации. Просто ещё одна рабочая операция.

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

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