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

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

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

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

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

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

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

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

Что может быть общего у забронзовевшего Waterfall и «выскочки» Agile? Как оказалось — очень многое.