Эта статья на HabrВ начале почти любого проекта приходится решать, как именно им управлять. Выбор сегодня огромен: от классического PMBOK до Kanban и гибких подходов. Но на практике этот выбор слишком часто определяется не логикой самого проекта, а личными предпочтениями, корпоративной инерцией или очередной управленческой модой.
Проблема в том, что методика не бывает нейтральной. Она не просто помогает организовать работу, а накладывает на проект собственную рамку: выделяет одни аспекты, ослабляет другие, открывает одни возможности и закрывает другие. Ошибка в этом выборе может обойтись дороже, чем кажется, — особенно в тот момент, когда реальные очертания проекта ещё только проявляются.
Практика термодинамической сегментации предлагает другой ход. Она позволяет не выбирать одну универсальную схему управления заранее, а обоснованно собирать архитектуру управления под конкретный проект — с учётом его структуры, состава команды и характера накопления неопределённости.
Иначе говоря, вопрос здесь не в том, как правильно управлять проектами вообще, а в том, какие режимы управления, где, в каком объёме и на каких основаниях нужны именно этому проекту.
Сразу стоит оговорить границы метода. Он не сводит управление к механическому расчёту и не отменяет профессионального суждения. Часть процедуры здесь расчётная, часть экспертная, а часть требует последующей калибровки уже по ходу проекта. Но даже в таком виде метод даёт важную вещь: он позволяет заменить ритуальный выбор методики обоснованной настройкой управления.
Проще всего разобрать этот подход по шагам.
Оглавление
- Шаг 1. Анализ и декомпозиция
- Шаг 2. Построение плана проекта и температурного профиля
- Шаг 3. Размещение управляющих активностей и оптимизация воздействий
- Шаг 4. Формирование первичной сегментации и классификация сегментов
- Шаг 5. Утверждение финальной структуры сегментации и её настройка под локальные методики управления
- Шаг 6. Старт проекта и исполнение
- Шаг 7. Реконфигурация
- Обоснованное управление
Шаг 1. Анализ и декомпозиция
Лев Толстой заметил: «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». В применении к проектам этот принцип можно переформулировать так: успешные проекты обычно начинаются сходным образом, тогда как каждый провал развивается по собственной траектории.
Поэтому первый шаг почти всегда одинаков: анализ целей, ресурсов и имеющихся компетенций с последующей декомпозицией задач.
Это делается независимо от того, какая методика будет выбрана позже. Но именно здесь часто закладывается первая ошибка: анализ и декомпозиция с самого начала подстраиваются под уже полюбившийся способ управления. В результате проект ещё не успевает проявить собственную структуру, а управление уже начинает навязываться ему извне.
Разница здесь похожа на планирование путешествия, когда можно действовать по двум стратегиям. Первая — заранее определить интересующие места и спланировать их посещение. Вторая — уже на месте, по ходу знакомства с городом, формировать список того, чему стоит уделить внимание. В обоих случаях что-то можно упустить: либо то, что не попало в предварительный план, либо то, что просто не оказалось в поле зрения.
Важно, что выбранная стратегия заранее определяет и способ подготовки к поездке. В одном случае придётся детально изучать место назначения, в другом — достаточно понять, как добраться до центральной улицы и с чего начать ориентироваться на месте.
С проектами происходит нечто похожее. В классическом подходе подробная детализация выступает ключевым элементом начального планирования, тогда как в гибких методиках она служит лишь отправной точкой для дальнейшего уточнения.
Если метод управления ещё не выбран, на старте разумно ориентироваться на наиболее требовательный к качеству исходного анализа сценарий. Это позволяет не потерять основания для последующего выбора и не подменить понимание проекта удобной, но преждевременной управленческой схемой.
Итогом первого шага должны стать:
- чётко сформулированные цели проекта;
- детальная декомпозиция задач;
- требования к составу команды, её численности и зрелости;
- анализ слабых мест команды и проекта.
Смысл этапа прост: проект нельзя корректно настраивать по внешнему шаблону, пока не ясны его собственные цели, структура работ и характеристики команды.
Шаг 2. Построение плана проекта и температурного профиля
После декомпозиции строится базовый план проекта. Ключевое значение на этом этапе приобретают временные PERT-оценки задач: именно они ложатся в основу температурного профиля.
Такой профиль показывает, где и с какой интенсивностью проект накапливает неопределённость. Проще говоря, он позволяет заранее увидеть участки естественного нагрева и понять, где управление с высокой вероятностью потребует усиления.
Итогом второго шага должны стать:
- предварительный план-график проекта;
- рассчитанный температурный профиль.
В этот момент план перестаёт быть просто последовательностью работ. Он становится картой ожидаемого нагрева проекта, то есть картой его потенциальной дестабилизации.
Подробнее о нагреве проекта и его температурной шкале можно узнать в предыдущей статье.
Шаг 3. Размещение управляющих активностей и оптимизация воздействий
После построения профиля нагрева в проект вводятся управляющие активности. Их задача — удерживать итоговый комбинированный профиль в пределах рабочих температур.
Здесь важно не впасть в привычную ловушку: управление нужно не для воспроизведения ритуалов и не для обслуживания методологии ради неё самой. Его задача — снимать накопившуюся неопределённость там, где это действительно необходимо.
На этом этапе решаются две задачи:
- определить, где вмешательство действительно нужно;
- минимизировать число и масштаб управляющих воздействий так, чтобы они сами не стали отдельным источником издержек.
Иначе говоря, управление вводится не по календарной привычке, а на содержательном основании.
Именно здесь менеджер проявляет инженерное чутьё: определяет состав воздействий, их область действия, длительность, характер и круг участников. При прочих равных предпочтение следует отдавать активностям с наиболее локальной зоной воздействия и минимально необходимым числом участников.
Итогом этого шага должны стать:
- комбинированный план-график проекта, включающий производительные и управляющие активности;
- структура управленческих мероприятий;
- комплексный температурный профиль.
На практике именно здесь проектируется контур охлаждения проекта: определяется, где, в каком объёме и какими средствами управление должно компенсировать нарастающую неопределённость.
Шаг 4. Формирование первичной сегментации и классификация сегментов
Когда ключевые управляющие активности уже расставлены, начинают проявляться естественные границы первичной сегментации проекта.
На этом этапе становится видно, как проект распадается на участки:
- с разным характером накопления неопределённости;
- с разными требованиями к координации;
- с разными допустимыми формами локального управления.
После этого сегменты классифицируются: определяется, какие из них являются локальными, какие — сквозными, какие возникают естественно, а какие требуют искусственного управленческого выделения.
Итогом шага становятся:
- структура сегментации проекта;
- классификация составляющих её сегментов.
Именно здесь вопрос о выборе методики впервые ставится по-настоящему предметно. Не вообще «что лучше: Scrum или PMBOK?», а какой режим управления уместен в этой части проекта и на этой стадии его прохождения.
Шаг 5. Утверждение финальной структуры сегментации и её настройка под локальные методики управления
После первичной сегментации проект собирается во вторую, уже более инженерную конфигурацию.
На этом этапе:
- фиксируется финальная структура сегментов;
- для каждого сегмента выбираются соответствующие режимы и методики управления;
- план проекта пересобирается в соответствии с принятой архитектурой управления.
Это один из ключевых моментов метода. Он не пытается заново изобрести правила управления, а обоснованно опирается на уже существующие подходы там, где они действительно уместны. Благодаря этому метод не превращается в ещё одну универсалистскую догму.
Существенную роль здесь играет управленческая эрудиция команды. От неё зависит, какие методики не только подходят проекту в теории, но и реально доступны команде на практике. Выбирать поэтому нужно не из всего теоретически допустимого набора, а из того, что команда способна применять квалифицированно и осмысленно.
На этом этапе сегменты соотносятся не только с абстрактно подходящими режимами управления, но и с реальными возможностями команды эти режимы поддерживать.
Шаг 6. Старт проекта и исполнение
После этого начинается собственно проектная работа.
Но теперь проект реализуется не просто по плану и не просто в логике выбранной методики, а в рамках заранее собранной архитектуры сегментации и управления. На этом этапе важно не только выполнение работ, но и проверка того, насколько фактическое поведение проекта соответствует ожидаемому температурному профилю.
Полевая оценка текущей температуры проекта сама по себе представляет отдельную и достаточно сложную задачу, достойную отдельного разбора. Но уже на базовом уровне должен вестись мониторинг наблюдаемого нагрева с сопоставлением фактических и плановых значений.
Именно здесь модель впервые проверяется реальностью. Если расхождение между ожидаемым и наблюдаемым становится устойчивым, возникает основание для следующего шага — реконфигурации.
Шаг 7. Реконфигурация
Реконфигурация запускается не потому, что расчётная температура сама по себе оказалась высокой или низкой. Основание другое: фактическое поведение проекта устойчиво расходится с тем, что предсказывал его температурный профиль.
Это означает, что ошибка может находиться в разных местах:
- в самой модели;
- в оценке зрелости команды;
- в структуре сегментации;
- в интенсивности управляющих воздействий;
- в неверном понимании текущей фазы проекта.
Здесь метод окончательно проявляет себя не как статическая схема настройки, а как замкнутый управленческий цикл.
По сути, возможны два базовых типа реконфигурации:
- горячая — когда проект управляется хуже, чем должен по расчётной модели;
- холодная — когда им управляют плотнее, чем это реально необходимо.
Перегрев и горячая реконфигурация
Перегрев проявляется не только в тех случаях, когда расчётная температура оказывается высокой. Он может возникать и тогда, когда при формально допустимом профиле в проекте фактически начинается управленческий хаос.
Его признаками могут быть:
- межкомандное согласование выходит за пределы выделенного контура управления;
- растёт число теневых договорённостей;
- решения становятся неустойчивыми;
- усиливается горизонтальное согласование, не приводящее к ясной управленческой фиксации.
Иными словами, проект начинает выглядеть менее управляемым, чем должен был бы выглядеть согласно расчётной модели.
В такой ситуации требуется горячая реконфигурация как средство экстренного охлаждения. Она может включать:
- ограничение или частичную остановку проектной активности;
- переоценку целей;
- новую декомпозицию;
- новую сегментацию;
- пересборку управления.
По сути, это локальный перезапуск проекта или его части.
Переохлаждение и холодная реконфигурация
Переохлаждение возникает тогда, когда управленческий контур оказывается избыточным по отношению к зрелости команды и реальному темпу накопления неопределённости.
Его признаками могут быть:
- управляющие активности продолжаются, но не приводят к содержательным решениям;
- обсуждения всё чаще заканчиваются подтверждением уже известного;
- управленческая плотность остаётся высокой, а полезная отдача снижается.
Иначе говоря, команда уже способна выдерживать больший объём естественной неопределённости без такого числа вмешательств. Важно, что это не «хорошая новость» сама по себе, а другая форма рассогласования между проектом и системой управления.
В этом случае требуется холодная реконфигурация. Она может включать:
- повторную оценку зрелости команды;
- временное ослабление или сокращение управляющих воздействий;
- наблюдение за естественным нагревом проекта;
- пересмотр температурного профиля;
- перестройку сегментации и профиля управления под более зрелый режим.
Здесь перезапускается не проект как таковой, а сама система управления.
Обоснованное управление
Основная идея метода проста: управление должно вытекать из природы проекта и меняться вместе с ним. Цели, задачи и ресурсы определяют структуру необходимого контроля, а уже из структуры управленческих воздействий можно выбирать уместную методику управления. Такой контур можно назвать естественным.
В этом смысле метод действительно образует метауровень проектного управления — и в этом же его слабое место. Чтобы применять его полноценно, менеджеру желательно ориентироваться в разных режимах управления проектами, понимать их ограничения и возможности и уметь не механически переключаться между ними, а осмысленно их сочетать.
Но даже на этом уровне польза метода не исчерпывается. Даже если команда уверенно работает в основном в рамках классического подхода, само построение естественного контура управления помогает лучше понять проект, его реальные точки напряжения и меру необходимого управленческого вмешательства.
Иными словами, речь идёт не о выборе «правильной» методики. Речь идёт о выборе правильного места и правильной меры для каждой из них.