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

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

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

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

Сегодня мы мыслим инкрементами. Обновления выпускаются с немыслимой прежде скоростью — Scrum, DevOps и сам современный темп работы сформировали этот подход. Менять архитектуру стало некогда: в инкремент это не укладывается, за спринт — не разрабатывается. В результате продукты всё чаще превращаются в корабли Тесея: после множества мелких правок в системе не остаётся ни одной «старой доски». Формально корабль полностью новый — все элементы заменены, — но по сути он изменился куда меньше, чем кажется.

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

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

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

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

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

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

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

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

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

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