Ну а все-таки как быть, когда для формирования проектной команды требуются специалисты, с которыми у вас нет опыта совместной работы? Очевидно, потребуется время на проверку качеств новых участников. Но если на каждом этапе проекта мы меняем состав и структуру команды, когда такая проверка может происходить? Также стоит учитывать, что кроме проверки нужен период адаптации, когда участники должны сработаться.
Подход для решения этой задачи я назвал «железобетонным» правилом. Идея пришла мне в голову, когда я наблюдал за тем, как устроены здания. Любой элемент конструкции, будь то стена, опора или перекрытие, внутри имеет железный каркас. Технология производства заключается в том, что первоначально устанавливается арматурный каркас, который затем заливается бетоном. Ту же конструкцию невозможно получить в обратном порядке – поместить арматуру внутрь затвердевшего бетона. Нечто похожее я обнаружил, глядя на развитие проектных команд.
Возьмем, к примеру, небольшую группу программистов, каждый из которых выполняет задачи по разработке. На ранних стадиях проекта они способны самостоятельно координировать работу. По мере повышения сложности задач и увеличения состава появляется потребность в выделенном руководителе, будь то технический лидер или менеджер проекта. Типичный подход состоит в том, что такой человек приходит в уже сложившийся коллектив. Не так важно, добавляется в команду кто-то новый или функции управления поручаются одному из текущих участников. В любом случае приходится принудительно менять сформированную схему работы и «вставлять арматуру в застывший бетон».
Последствия такого подхода хорошо известны: появление нового руководителя в команде неизбежно приводит к конфронтации. Ему нужно настроить процесс под себя, чтобы ставить и распределять задачи, а потом контролировать их выполнение. Он вынужден менять привычные для участников правила работы, при этом нарушать сложившиеся схемы взаимодействия и сбивать ритм. В лучшем случае команда «перезапускается», и схема работы постепенно настраивается, но с большими издержками. В худшем – команда разваливается.
Ситуация с назначением одного из текущих участников руководителем кажется проще, но только на первый взгляд. На такую роль выбирают наиболее опытных специалистов. Но профессиональные компетенции не равны управленческим. Опыт координации группы нужно приобретать на практике, заодно иметь к этому психологические склонности. Кроме того, назначенный лидер до этого выполнял задачи по проекту. Если он был одним из сильнейших специалистов в группе, то смена его роли приведет к ощутимой потере в качестве работы. Команда будет вынуждена пройти непростой путь трансформации, связанный с перераспределением круга задач каждого участника. Все это будет усугубляться тем, что наделенный лидерскими полномочиями специалист должен будет приобретать навыки управления, одновременно настраивая работу команды в новом формате под себя. Как и в предыдущем случае, есть шанс, что за такие изменения придется заплатить высокую цену.
Идея «железобетонного» правила заключается в том, чтобы с самого начала формировать команду вокруг «несущих конструкций» – специалистов, ориентированных на техническое лидерство и координацию работы. При таком подходе описанные выше ситуации могут развиваться иначе. Лидер задает правила игры, по которым включаются новые участники команды. Получается, что ресурс для масштабирования закладывается сразу, и сложившуюся организацию работы не приходится менять.
Как и проектирование, этот подход кажется избыточным и не интуитивным, противоречащим желанию экономно продвигаться вперед, не тратить лишние ресурсы на непроверенные гипотезы и не вводить в игру более компетентных, а значит, дорогих специалистов. Но именно благодаря проектированию этот подход таким не является, потому что результаты проектирования определяют требования к будущим участникам и тем «несущим конструкциям», вокруг которых будет развиваться команда на каждом этапе проекта.
Правило многоуровневой команды
Второе правило принципа проектирования гласит: каждое решение в проекте требует своего уровня абстракции, компетенции и ответственности. Применительно к гибкому формированию команд на это можно смотреть так.
Есть роли, которые нельзя сочетать в одном человеке, так как их носители должны быть антагонистами. Например, разработчик не может одновременно заниматься тестированием. Знания об устройстве программных компонентов мешают ему построить тестовые сценарии, в которых можно найти неочевидные проблемы. Иногда результаты тестирования обескураживают и заставляют полностью пересмотреть способ технической реализации. Никто не захочет самостоятельно поставить себя в подобную ситуацию.
Такая же логика подводит к идее, что нельзя поручать одному специалисту принятие решений на разных уровнях абстракции по двум причинам. Первая – это просто невозможно! Да-да, именно так. При достаточном уровне сложности системы, чтобы охватить ее полностью и сформулировать общие принципы построения, нужно подняться на такой уровень абстракции, где многие детали станут неразличимы. В то же время эти детали важны, ведь из них состоит система. Пренебрегать ими – значит пустить создание продукта на самотек. Но постоянно переключаться между разными уровнями сложно, на это требуется много времени и сил. Сначала рассмотреть продукт на общем уровне, потом детально разобраться с каждой функцией, затем снова подняться на уровень всей системы, а после переключиться на технический уровень. Скорее всего через непродолжительное время вы сойдете с ума, либо, что более вероятно, оставите попытки. В любом случае проект пострадает.
Вторая причина связана с целями на каждом уровне. Они могут конфликтовать. Эффективность всей системы не является следствием эффективности каждой ее части. Наоборот, часто то, что отдельному специалисту на локальном уровне кажется странным и глупым ограничением, на уровне продукта оказывается оптимальным балансом. К примеру, решения дизайнера интерфейса мобильного приложения и разработчика серверных компонентов должны быть уравновешены, что можно сделать, только рассматривая систему как единое целое.
В одной из книг я наткнулся на утверждение, что главная задача менеджера при управлении проектом – быть сфокусированным. Соглашусь, в этом состоит секрет не только управления, но и проектирования, разработки, дизайна, и всего остального. Еще больший секрет – как достичь необходимой сфокусированности. Для этого нужно отбросить все лишнее, что отвлекает внимание. Поэтому, работая над сложным проектом на каждого уровне абстракции системы должен быть отдельный специалист – та самая «несущая конструкция» проекта.
Итак, если мы исходим из такой идеи, то первоначальные решения, определяющие суть будущего продукта, должны прорабатываться людьми, связанными с бизнесом. Они могут разглядеть потенциал новых технологий применительно к тому, на чем зарабатывает компания. По мере уточнения концепции продукта, а затем и самого цифрового продукта, в работу вовлекаются специалисты, способные проработать его на детальном уровне. Однако это вовсе не означает, что придумать идею использования технологий можно, обладая лишь компетенциями в бизнесе. Одновременно с этим нужны знания возможностей цифровых инструментов.
Вы никогда не задумывались, почему самые интересные и удачные решения рождаются на стыке разных дисциплин? Дело в том, что те, кто находит такие решения, обладают контролем над всеми частями создаваемой системы. В большинстве случаев, чтобы получить такой контроль, нужно владеть несколькими компетенциями. Мой любимый пример не из IT, но он все отлично показывает. Представьте дизайнера бытовых приборов. Помимо художественных навыков, в его компетенции входят в том числе и знания по технологии производства и свойствам материалов. Спроектировать, скажем, чайник невозможно без учета ограничений при литье из пластмассы. Да, можно придумать красивое и функциональное устройство, только его нельзя будет изготовить!
Если при создании цифрового продукта вы замыкаетесь в рамках одной специализации, например UX, вы не видите все части, которые в сумме создают работающую систему. Нужно выйти за пределы своей дисциплины, чтобы учесть факторы, влияющие на итоговое решение. Поэтому ключевые участники проекта должны обладать опытом в смежных дисциплинах и иметь несколько профессиональных компетенций.
Традиционно при формировании проектных команд роли участников связаны с их специализацией. Это могут быть разработчики, дизайнеры, аналитики и другие. Их опыт и профессиональные качества определяют уровень, на котором они рассматривают создаваемый продукт. Например, IT-архитектор видит систему целиком, но исключительно с технической точки зрения. За более детальный уровень отвечают выделенные разработчики с компетенциями в отдельных технологиях, таких как базы данных, нейросети, серверные компоненты, мобильные приложения, веб-сайты. Но бизнес-задачи, сценарии взаимодействия, пользовательский интерфейс – при данном подходе все это для него внешние требования по отношению к технической реализации.
Аналогичным образом обстоят дела и с другими специалистами. Продуктовый дизайнер определяет общее видение цифрового продукта с точки зрения взаимодействия с пользователем на уровне интерфейса. Для детальной проработки отдельных экранов мобильных приложений или веб-сайта подключаются графические дизайнеры и UX-проектировщики. Дальше результаты работы передаются разработчикам в расчете, что они решат, как технологически будет реализован продукт.
Бизнес-администрирование тоже можно считать проектной специализацией, потому что его представители, как и участники команды, отвечающие за технические аспекты, традиционно не выходят за границы своих организационных задач. Руководитель компании или подразделения рассматривает цифровой продукт на верхнем уровне абстракции и редко погружается в детали, учитывает только его общее назначение, бюджет и сроки разработки. Уровнем ниже менеджеры компании детализируют это в функциональные требования, не учитывая остальные аспекты. Фактически они смотрят на то, что продукт «должен делать», и оставляют вопрос «как» на исполнителей – менеджера проекта, IT-архитектора, продуктового дизайнера и остальных участников команды.