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

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

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

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

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

Проще всего разобрать этот подход по шагам.

Шаг 1. Анализ и декомпозиция

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

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

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

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

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

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

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

Итогом первого шага должны стать:

чётко сформулированные цели проекта;
детальная декомпозиция задач;
требования к составу команды, её численности и зрелости;
анализ слабых мест команды и проекта.

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

Шаг 2. Построение плана проекта и температурного профиля

После декомпозиции строится базовый план проекта. Ключевое значение на этом этапе приобретают временные PERT-оценки задач: именно они ложатся в основу температурного профиля.

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

Итогом второго шага должны стать:

предварительный план-график проекта;
рассчитанный температурный профиль.

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

Подробнее о нагреве проекта и его температурной шкале можно узнать в предыдущей статье.

Шаг 3. Размещение управляющих активностей и оптимизация воздействий

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

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

На этом этапе решаются две задачи:

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

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

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

Итогом этого шага должны стать:

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

На практике именно здесь проектируется контур охлаждения проекта: определяется, где, в каком объёме и какими средствами управление должно компенсировать нарастающую неопределённость.

Шаг 4. Формирование первичной сегментации и классификация сегментов

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

На этом этапе становится видно, как проект распадается на участки:

с разным характером накопления неопределённости;
с разными требованиями к координации;
с разными допустимыми формами локального управления.

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

Итогом шага становятся:

структура сегментации проекта;
классификация составляющих её сегментов.

Именно здесь вопрос о выборе методики впервые ставится по-настоящему предметно. Не вообще «что лучше: Scrum или PMBOK?», а какой режим управления уместен в этой части проекта и на этой стадии его прохождения.

Шаг 5. Утверждение финальной структуры сегментации и её настройка под локальные методики управления

После первичной сегментации проект собирается во вторую, уже более инженерную конфигурацию.

На этом этапе:

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

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

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

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

Шаг 6. Старт проекта и исполнение

После этого начинается собственно проектная работа.

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

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

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

Шаг 7. Реконфигурация

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

Это означает, что ошибка может находиться в разных местах:

в самой модели;
в оценке зрелости команды;
в структуре сегментации;
в интенсивности управляющих воздействий;
в неверном понимании текущей фазы проекта.

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

По сути, возможны два базовых типа реконфигурации:

горячая — когда проект управляется хуже, чем должен по расчётной модели;

холодная — когда им управляют плотнее, чем это реально необходимо.

Перегрев и горячая реконфигурация

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

Его признаками могут быть:

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

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

В такой ситуации требуется горячая реконфигурация, как средство экстренного охлаждения. Она может включать:

ограничение или частичную остановку проектной активности;

переоценку целей;
новую декомпозицию;
новую сегментацию;
пересборку управления.

По сути, это локальный перезапуск проекта или его части.

Переохлаждение и холодная реконфигурация

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

Его признаками могут быть:

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

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

В этом случае требуется холодная реконфигурация. Она может включать:

повторную оценку зрелости команды;
временное ослабление или сокращение управляющих воздействий;
наблюдение за естественным нагревом проекта;
пересмотр температурного профиля;
перестройку сегментации и профиля управления под более зрелый режим.

Здесь перезапускается не проект как таковой, а сама система управления.

Обоснованное управление

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

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

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

Иными словами, речь идёт не о выборе «правильной» методики. Речь идёт о выборе правильного места и правильной меры для каждой из них.

Пошаговые хлопоты: термодинамический рабочий процесс