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

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

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

Итак, начнём с первого принципа.

1. Принцип толерантной иерархии

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

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

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

Пример и методологическая связка

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

Это можно сравнить с телесериалом: каждая серия обладает собственным динамичным сюжетом, но при этом через весь сериал проходит единая сюжетная линия.

На практике такой подход позволяет совместно использовать накопленный опыт PMBOK и динамику Scrum. Более того, именно так проекты обычно и ведутся — просто это редко фиксируется явно. Частые планёрки классического подхода можно рассматривать как предтечу гибких методик; в то же время agile-команда, планируя спринт, всегда опирается на структуру WBS.

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

Формулировка принципа и ограничение

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

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

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

2. Принцип уважения к критериям

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

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

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

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

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

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

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

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

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

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

3. Принцип сквозных сегментирований

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

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

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

В нашем примере «классика / гибкость» оба сегментирования являются сквозными. Это означает, что к проекту можно одновременно и почти без ограничений применять как весь функционал классических методологий PMBOK, так и инструменты Scrum. Методологии не мешают друг другу, поскольку каждая из них поддерживается непрерывно на протяжении всего проекта.

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

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

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

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

4. Принцип инкапсуляции

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

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

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

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

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

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

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

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

5. Принцип ограничения перекрытий

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

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

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

Кодекс сегментации

В качестве итога сформулируем пять базовых принципов сегментирования проектов:

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

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

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

Полезные хлопоты: кодекс сегментации проекта