Бесконечность на бесконечность: почему неограниченный запуск проектов = организационный хаос

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

Источник изображения: Pinterest.com

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

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

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

Правило Лопиталя решает неопределённость устанавливая функцию, которая связывает скорость роста числителя и знаменателя друг с другом. Таким образом в организации хаос лечится установлением функции, которая связывает скорость появления задач со скоростью и ёмкостью их реального исполнения — то есть системой приоритизации, ограничением объёма работы в моменте (WIP-лимиты из lean/kanban — это буквально инженерная реализация "производной", о которой говорит правило Лопиталя), и явным протоколом, кто вообще имеет право открыть новый проект и какой ресурс он под это высвобождает.

Без этой связывающей функции у компании формально "много активности" (обе бесконечности растут — выглядит как рост!), но результат остаётся математически неопределённым: он может оказаться каким угодно, потому что ничто в самой системе не заставляет его сходиться к чему-то конкретному.

Проиллюстрируем "уходит ли это в бесконечность, или остаётся ограниченным?" через фрактальную графику.

Множество Мандельброта (самый известный фрактал) строится ровно вокруг вопроса неопределённости: берётся точка c на комплексной плоскости, и к ней применяется простое рекурсивное правило — z → z² + c, снова и снова. Для каждой точки алгоритм проверяет: улетает ли последовательность в бесконечность, или остаётся ограниченной навсегда. Точки, которые остаются ограниченными, закрашиваются — это и есть само множество Мандельброта. Точки, которые улетают, — это фон.

То есть фрактал — это карта результатов применения одного и того же простого правила ко множеству разных стартовых точек, разделяющая их на "сошлось" и "разошлось".

Каждая точка c — это отдельный проект или задача, запущенная где-то в компании. У каждой точки — своя стартовая позиция: свой инициатор, свой контекст, свой первоначальный масштаб.

Правило итерации z → z² + c — это повторяющееся, применяемое на каждом шаге правило: как приоритизируется задача при столкновении с другой, что происходит при конфликте ресурсов, кто выносит эскалацию. Это правило применяется на каждой итерации жизни проекта — то есть каждую неделю, каждый спринт, каждое столкновение с другим проектом за тот же ресурс.

"Улетает в бесконечность" — это проект, который при столкновении с ограниченным ресурсом разрастается дальше: захватывает больше людей, больше времени, больше внимания руководства, пока не поглотит всё вокруг себя. Внешне это может какое-то время выглядеть как рост — совсем как последовательность z, которая по первым нескольким итерациям выглядит невинно, прежде чем сорваться в бесконечность.

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

Как фрактал самоподобен на любом масштабе, так и в организации одно и то же правило приоритизации должно работать одинаково на уровне всей компании (портфель из 50 проектов), на уровне отдела (портфель из 5 инициатив функционального руководителя) и на уровне одного человека (список его личных задач на неделю). Если правило меняется от уровня к уровню — система перестаёт быть фракталом и превращается в набор несвязанных локальных решений, которые в сумме снова дают ту самую неопределённость ∞/∞.

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

Здоровый портфель проектов — наличие устойчивого, одинакового на всех уровнях правила итерации, которое честно разделяет предложенные инициативы на "сойдётся в результат" и "разойдётся в хаос" — причём делает это не один раз при одобрении бюджета, а на каждом цикле планирования заново, потому что даже проект, который сходился вчера, может начать расходиться при изменении контекста. Возьмём пример организации где надо внедрить несколько ИТ систем: 1С, ЕРП, таск-менеджмент, документооборот:

Знаменатель (количество проектов): бухгалтерия хочет 1С, операционный директор — ERP, руководитель проектов — свой таск-менеджer, юротдел и канцелярия — СЭД, отдел продаж, скорее всего, параллельно тянет CRM. Если у каждого руководителя есть право самостоятельно инициировать внедрение своей системы — знаменатель не ограничен структурно, он растёт с числом руководителей, у которых есть бюджет и голос;

Числитель (количество задач): каждое внедрение само по себе плодит бесконечный хвост подзадач — миграция данных, доработки под специфику, интеграции с другими системами, обучение пользователей, правки после первого месяца эксплуатации. У ERP-проекта список доработок в принципе не имеет естественного предела, если не задать ему предел искусственно.

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

Как выглядит "расходящийся" сценарий:

• Клиент в CRM, в 1С и в СЭД существует как три разных, несвязанных между собой записи с разными ID

• Задача в таск-менеджере закрыта, но документ по этой же задаче в СЭД всё ещё находится "на согласовании" — потому что системы не разговаривают друг с другом

• Финансовые данные в ERP не бьются с проводками в 1С, и раз в квартал кто-то вручную сверяет их в Excel

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

  
  

Это и есть визуальный аналог точек, которые "улетают в бесконечность" на фрактальной картинке — процесс, который выглядит как активность (внедрили же три системы!), но не сходится ни к одному предсказуемому результату.

Как выглядит "сходящийся" сценарий — то самое правило, применённое на каждом уровне:

Ключевая мысль из метафоры с правилом Лопиталя и фракталом: единое правилом, которое применяется одинаково на любом масштабе — от решения о всей ERP-программе до решения одного отдела завести себе Trello.

Практически это правило обычно состоит из нескольких конкретных элементов:

1. Единая мастер-система данных — назначить, какая система является источником истины для клиента, контрагента, сотрудника (обычно это 1С или ERP), а все остальные системы (СЭД, таск-менеджер, CRM) обязаны ссылаться на её ID, а не заводить свои параллельные карточки.

2. Ограничение одновременных внедрений (WIP-лимит для ИТ-инициатив) — не пять систем сразу, а последовательность с точками синхронизации: сначала мастер-система, затем то, что к ней подключается.

3. Обязательная архитектурная проверка перед запуском любой системы — даже маленького таск-трекера для одного отдела: "с чем это должно интегрироваться, кто владелец данных, кто будет это поддерживать" — это и есть аналог правила z → z² + c, применяемого к каждой новой точке-инициативе.

4. Один орган, а не любой желающий, имеет право запустить ИТ-инициативу — то есть знаменатель (количество параллельных проектов) становится управляемым не потому, что кому-то отказали в системе, а потому что запуск проходит через одну и ту же функцию принятия решения на любом уровне организации.

   
   

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

На иллюстрации разница видна сразу:

• Слева — 1С, ERP, таск-менеджер и СЭД существуют как отдельные острова, соединённые случайными точечными связями (тонкие красные линии), а внизу — неизбежный ручной Excel, который латает то, что системы сами не состыковали.

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

Ключевая практическая мысль, которая отсюда следует: переход от левой картинки к правой — это не "заменить все системы одной", а навести правило подключения: каждая новая система (даже маленький таск-трекер для одного отдела) при запуске обязана ответить на вопрос "к какой мастер-системе я подключаюсь и чей ID использую".