У каждого успешного Agile-проекта наступает момент, когда MVP перестаёт быть безопасной игрушкой для команды и попадает в руки реальных пользователей. Именно тогда заканчивается комфортная стадия и начинается новая проектная реальность.
Сначала перемены почти незаметны. Владельцы продукта и маркетологи осторожно подправляют требования под рынок. Планы слегка качаются, но ещё держатся. Затем продуктовый аппетит растёт, однако развернуться в полную силу ему не дают баги: сначала мелкие и нелепые, ускользающие от тестов, потом — уже не всегда мелкие. Иногда критические.
И вот телегу проекта уже рвут в три стороны: первоначальный план развития продукта, давление рынка и требования к качеству. Если такая развилка не была заложена в план заранее, конструкция начинает трещать.
Scrum-мастера отгораживаются спринтом. Владельцы продукта требуют догонять конкурентов. Менеджер по качеству считает потерянных из-за багов клиентов.
Кто прав? Что делать?
Как всегда — правы все. А прежде чем что-то делать, нужно разобраться с сутью проблем. Причины, как всегда, не на виду, отмотаем время назад.
Соломинкой, которая в итоге ломает хребет верблюду, то есть нашему плану, как правило, становятся ошибки продукта — они проявляются далеко не сразу. Месяцами работая над прототипом, команда добавляет в него не только новые функции и возможности, но и ошибки. Вот только для учёта новых функций у нас придуманы метрики, и мы охотно меряемся скоростью их прироста. А вот метрик, измеряющих количество ошибок в продукте, у нас нет, хотя сами ошибки неизбежно есть. Трудно измерять то, чего не видно.
Ошибка в коде подобна элементарной частице: на неё сложно указать, проще описать вероятность её появления. В коде она частица, а в проде — волна. Любой технолог старой закалки укажет: по тому, как вёлся проект, можно предположить, насколько вероятны проблемы с качеством продукта. Если у нас есть два одинаковых двигателя, но один смазан и качественно обслужен, опытный механик быстро вычислит, какой именно. Для него это очевидно: обслуженный двигатель будет меньше нагреваться. Температура — быстрый показатель качества работы.
В теории термодинамической сегментации проектов (T-TOPS) температура проекта понимается не как образ, а как инструментальная мера накопленной неопределённости. Подробно я разбираю это в отдельной статье, а здесь важен только базовый принцип.
Любые производительные усилия неизбежно вносят в проект ошибки и повышают его неопределённость, то есть температуру. Проектная среда нагревается. Управляющие активности — встречи, совещания, тестирования, обучение и так далее — снижают неопределённость и охлаждают проект.
Следует принять как данность: в продукте всегда есть ошибки, неопределённость и трение. По этой причине продукт, а вместе с ним и весь проект, всегда немного нагреты.
Когда мы совещаемся, мы не работаем — в том смысле, что не производим продукт. В этот момент можно сказать, что проект останавливается. И это оправданно: на совещаниях мы меняем направление его движения, а когда сильно крутишь рулём, лучше не жать изо всех сил на газ. Ведь мы все ответственные водители, не так ли?
Таким образом, управляющие активности нарезают монолитное тело проекта на отдельные управляемые сегменты, внутри которых накапливается неопределённость. Здесь каждая остановка — граница сегмента.
И вот случается долгожданный запуск продукта. Мы надеемся, что это не слишком повлияет на природу проекта, — и сильно ошибаемся. Потому что в этот момент происходит глобальный сдвиг в его термодинамике, хотя мы этого ещё не видим.
Все ошибки, накопленные продуктом к этому моменту, до поры лежали в нём как потенциальная энергия. Но стоило запустить его в прод, как каждая маленькая неопределённость, неувязка и рассогласование начали работать ежедневно, изо дня в день, порождая новые неопределённости.
Теперь проект нагревается не только командой, но и самим продуктом, рынком, пользователями. Это меняет всё.
Двигатель, который прежде лишь время от времени запускали на стенде, теперь беспрерывно работает в пустыне, под изнуряющим зноем, захлёбываясь песком. Надеюсь, этот контраст достаточно нагляден и смена перспективы ощущается.
Пара советов из разряда «вода мокрая», но их всё равно стоит проговорить — именно потому, что вода действительно мокрая.
Любое время, затраченное на подготовку к запуску продукта, поможет избежать проблем в будущем. Не слишком доверяйте маркетинговой спешке: оптимальное время для выхода на рынок всегда было вчера, а вчера — это уже позавчера. Запускайте продукт только тогда, когда готовы к этому.
Не ждите, что после запуска продукта сможете работать как прежде. Нет. Первые полгода будут сложными, а потом станет ещё труднее, но уже иначе.
Параллельная сегментация: когда проект уже не один
Допустим, я вас убедил, что с запуском продукта в проекте существенно меняется структура накопления неопределённости и рисков. Картинка нарисована. Но что дальше? Как всем этим управлять?
Простого решения у такой проблемы нет, поэтому дальше текст станет строже — в расчёте на тех, кто хочет найти практический подход к описанной ситуации. Если не перейти здесь к более строгой схеме, весь разговор так и останется жалобой на пострелизный хаос.
А начинается решение, как всегда, с понимания самой ситуации. Проект изменился: теперь в нём несколько источников системного накопления неопределённости, и каждый такой источник нагрева требует собственного подхода к управлению.
Обновлённый проект теперь включает не один сложный процесс, а несколько разнородных процессов, идущих одновременно в общем контексте. Они могут быть связаны единым продуктом, одной командой, общей инфраструктурой или общим управленческим полем, однако по своей природе и по способу реагирования на сигналы остаются различными.
Так возникает параллельная сегментация. В этом случае проект распадается уже не на одну последовательную линию сегментов, а на несколько параллельных контуров, каждый из которых требует собственной логики управления. Один контур может быть ориентирован на создание нового результата, другой — на рыночную конкуренцию, третий — на сопровождение эксплуатации или выполнение внешних обязательств.
Формально всё это относится к одному проекту или программе работ, но практически не может качественно управляться как единый однородный поток.
Разработка естественным образом тяготеет к продуктовой, ресурсной или ритмичной сегментации. Здесь важны гипотезы, инкременты, архитектурные решения, а также накопление и своевременное снятие неопределённости. Разработка стремится удерживать темп и фокус — быть в ресурсном потоке.
Эксплуатационная поддержка устроена иначе: она реагирует на инциденты, отклонения, запросы на вмешательство, ограничения по времени реакции и риски нарушения устойчивости.
Рыночная конкуренция живёт по другой логике. Она следует за спросом, тенденциями и модой и на первый взгляд кажется чем-то промежуточным между разработкой и поддержкой. Но это опасное заблуждение. Работа с рынком — это исследовательская деятельность, а значит, у неё собственный ритм и свой подход к управлению.
Возможны и другие конфигурации — практика всегда богаче схемы.
Параллельная сегментация позволяет признать, что внутри одного проекта могут одновременно сосуществовать разные режимы управляемости. Это не отменяет общей координации, но требует явного разведения контуров: у каждого из них должны быть свои границы, свои правила реакции, свои точки контроля и собственный допустимый уровень отклонения.
Именно в этом случае совмещение процессов становится не источником хаоса, а управляемой архитектурой. Сегментация здесь оказывается не просто способом описать проект, а способом не смешивать несовместимые режимы управления.
Кодекс параллельных контуров
Как и при всякой сегментации, для параллельных сегментов должны соблюдаться принципы кодекса сегментирования. Параллельный случай не отменяет кодекс сегментирования, а лишь проявляет его в новой форме.
1. Принцип толерантной иерархии
Принцип толерантной иерархии означает, что подходы к управлению разными сегментами могут и должны различаться. У них могут быть разные типы входящих сигналов, разный горизонт реакции, собственные критерии успеха и иной ритм контроля. Иными словами, мы признаём право разных контуров жить в разных управленческих временах: один может требовать реакции в часах, другой — в днях, третий — в неделях.
Здесь мы естественным образом переходим к следующему принципу.
2. Уважение к критериям
Уважение к критериям означает, что один контур управления должен с вниманием и уважением относиться к логике другого. Нужно принять, что среди параллельных сегментов нет главного: все они взаимозависимы. Продукту одинаково важны и функции, и пользователи, и рынок.
При этом у каждого контура есть свои базовые и свои второстепенные критерии. Базовые критерии должны учитываться всеми контурами, даже если это требует жертвовать собственными второстепенными приоритетами.
Разработка хуже всего переносит потерю фокуса.
Поддержка — медленную реакцию.
Рыночный контур — ложную уверенность.
Например, базовым критерием контура поддержки является непрерывность пользовательского опыта, и в ряде ситуаций это важнее второстепенных критериев разработки, таких как архитектурное единство или замкнутый цикл тестирования.
Уважение к критериям означает готовность локально уступать чужому базовому критерию, если твой собственный в данной ситуации второстепенен.
3. Принцип сквозных сегментирований
Принцип сквозных сегментирований для параллельного случая тривиален: единство управления должно сохраняться на всём протяжении каждого управленческого контура. Он существует только тогда, когда его критерии, ритм и точки контроля сохраняются непрерывно, а не вспоминаются от случая к случаю.
4. Инкапсуляция
Инкапсуляция требует, чтобы каждый параллельный контур управления проектом имел чётко определённые условия входа, критерии завершения и процедуру оценки результата. Связанные с ним риски должны локализоваться внутри контура, не расползаясь на проект в целом.
Если инцидент поддержки мгновенно ломает ритм разработки, а рыночная паника — архитектурные решения, значит контуры не инкапсулированы и проект фактически управляется как хаотическая масса.
Из этого напрямую следует важное ограничение: каждая базовая активность проекта должна входить только в один контур управления. Даже если разработка новой функции одновременно исправляет старую ошибку и повышает рыночную привлекательность продукта, сама работа по её реализации должна вестись в одном потоке, одной командой и под единым управлением.
Одна работа может удовлетворять нескольким контурам, но управляться должна только из одного.
5. Ограничение перекрытий
Ограничение перекрытий требует, чтобы сегменты по возможности не накладывались друг на друга. На первый взгляд может показаться, что параллельная сегментация самой своей формой противоречит этому принципу. Однако это противоречие лишь внешнее.
Суть принципа в том, чтобы сегменты не накладывались друг на друга в пределах одного контура управления. Если же в проекте одновременно существуют несколько контуров, то параллельная сегментация становится естественной формой их организации. Иными словами, ни суть принципа, ни его дух здесь не нарушаются.
Координация — не прерывание
Но если сегменты вообще не пересекаются по активностям и никак не накладываются друг на друга, возникает другая, не менее абсурдная ситуация: в одном контексте сосуществуют несколько никак не связанных между собой систем управления. Это уже явно противоречит практике. Как же тогда должны взаимодействовать контуры?
Ответ, по сути, очевиден. Если проект управляется в точках управляющих активностей, то и взаимодействие контуров управления должно происходить именно в них. Эта логика имеет глубокие последствия: сегменты управляются совместно, но исполняются независимо и изолированно.
Изоляцию здесь не следует понимать буквально: речь идёт об управленческой изоляции. Все участники проекта могут свободно обмениваться контекстом исполнения задач, информацией о продукте, пользователях и рынке, а технические вопросы исполнения можно и нужно обсуждать без ограничений. Однако управленческие решения, влияющие на обязательства команд или изменяющие конфигурацию проекта, должны приниматься либо организованно — в рамках выделенных общих управляющих активностей, — либо изолированно, в пределах компетенции соответствующего сегмента. Систематическое возникновение таких решений вне контура управления служит признаком теневого управления и фактического перегрева проекта.
Если один контур вынужден вмешиваться в течение другого вне контрольных точек, возникает прерывание — экстренный запрос на управление проектом. Прерывания неизбежны, но всегда обходятся дорого: они ведут к потере фокуса, росту задержек, разрушению ритма и переносу рисков между контурами. Поэтому задача управления состоит не в полном устранении прерываний, а в их локализации, учёте и снижении частоты.
Управляемое пересечение контуров в ходе запланированных управляющих событий — это координация. Неуправляемое пересечение — это прерывание. Если кратко: исполнение должно быть локальным, а координация — общей.
Управление прерываниями — сложный механизм, в чём-то напоминающий работу процессоров и контроллеров, и эта тема заслуживает отдельного анализа. Сейчас важно другое: любое прерывание без чётко обусловленных внешних причин — это брак управления, а частые прерывания — признак плохой архитектуры проекта.
Авария в проде, регуляторное требование, критический пользовательский инцидент — внешние причины. Хаотическое обещание, непрояснённый приоритет, несогласованное решение — внутренние. Хорошее управление не устраняет все прерывания, но делает почти каждое внутреннее прерывание поводом для подозрения.
Почему двигатель не работает на одной системе
В заключение стоит отметить, что управление — это накладный ресурс, который должен использоваться как ответ на появление новых источников неопределённости. Когда возникают новые источники нагрева, появление новых контуров управления становится естественной организационной реакцией.
Попытка управлять разными потоками из одного контура, как правило, ведёт к резкому росту проектной команды и общих издержек, а также сопровождается снижением качества работ и самого управления. Правильное понимание эволюции структуры проекта — одно из ключевых требований к управлению проектом.
Эта статья — лишь введение в проблему. За её пределами осталась общая термодинамика параллельных контуров: то, как они сосуществуют в одной системе, нагревают и охлаждают друг друга, перераспределяя неопределённость между собой. В полной версии модели конфликт базовых критериев разных контуров разрешается через инженерное правило: приоритет у того контура, чей нагрев в данный момент выше. Общий принцип здесь состоит не в поиске компромисса ради гармонии, а в снижении нагрева, потому что чем меньше неопределённости, тем ниже потребность в управлении и тем меньше издержки. Но это уже тема для отдельного, более технического разговора.
Везде, где политическое согласование удаётся заменить инженерным правилом, издержки на управление снижаются, а сам конфликт переводится в техническую плоскость.
Ваш проект — это двигатель. Scrum, как поршень, производит движение и управляется ритмично. Система охлаждения работает по термостату. Система смазки зависит от оборотов, а подача топлива происходит непрерывно. Сразу несколько разных стилей управления обслуживают один и тот же процесс. Задумайтесь, что произойдёт с проектом, если откажет хотя бы одна из этих систем.
Не существует единого «правильного» стиля управления сложным проектом, так же как в двигателе нет одной системы, которая могла бы заменить все остальные.