Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

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

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

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

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

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

Правило многоуровневой команды

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

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

Такая же логика подводит к идее, что нельзя поручать одному специалисту принятие решений на разных уровнях абстракции по двум причинам. Первая – это просто невозможно! Да-да, именно так. При достаточном уровне сложности системы, чтобы охватить ее полностью и сформулировать общие принципы построения, нужно подняться на такой уровень абстракции, где многие детали станут неразличимы. В то же время эти детали важны, ведь из них состоит система. Пренебрегать ими – значит пустить создание продукта на самотек. Но постоянно переключаться между разными уровнями сложно, на это требуется много времени и сил. Сначала рассмотреть продукт на общем уровне, потом детально разобраться с каждой функцией, затем снова подняться на уровень всей системы, а после переключиться на технический уровень. Скорее всего через непродолжительное время вы сойдете с ума, либо, что более вероятно, оставите попытки. В любом случае проект пострадает.