Книга и проект Вадима Митякина (Eleven)
Метод параноика

Метод параноика: принцип динамических команд

январь, 2021
#красная
О создании цифровых продуктов, Вселенной и всем остальном
Книга «Метод параноика»
Части главы (комментировать):
Команды в разных типах проектов — Сила и слабость фиксированных команд — Выбор участников динамических команд — Проектирование динамических команд — Первое правило проектирования команды — Второе правило — Третье правило — Управление динамическими командами — Коммуникации между участниками — Тезисы принципа
Глава 7 книги «Метод параноика»
Команды в разных типах проектов
Настало время посмотреть на типы проектов, описанных во второй главе, через призму их участников. Меньше всего неопределенности в «Седине», т.е. проектах, цель которых заключается в повторном использовании уже найденных и подтверждённых решений. То же самое можно сказать и о команде. Будучи единожды сформированной, она является составной частью проверенной технологии, на которую рассчитывает бизнес. Типичный пример — команда внедрения CRM-системы, включающая в себя менеджера, бизнес-аналитика, разработчиков и специалистов по внедрению. С каждым проектом она становится все более и более отлаженным механизмом, составляющим часть общей технологии.

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

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

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

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

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

Но у всего есть оборотная сторона, и в случае построения работы описанным выше образом у многих участников проекта может возникнуть сомнение в необходимости подробного документирования принятых решений. Из-за возможности хранить знания «в людях» культура поддержания модели продукта в актуальном состоянии постепенно деградирует, конечно, если она до этого была в принципе. Следствия этого хорошо известны. Когда уходит ключевой специалист, вместе с ним пропадает информация о той части проекта, за которую он отвечал. По большому счету любое изменение в команде приводит к невосполнимой потере знаний. Хочется спросить: для того ли человечество изобрело письменность, чтобы потом снова вернуться к историям, передаваемым из уст в уста?
Даже если команда крепкая и ее состав постоянен, это не спасает от главной проблемы: люди забывают. Это только кажется, что, будучи погруженным с головой в работу, ты все помнишь. В последние годы моей практики проекты достигли такого размера, что для проектирования одной части продукта приходилось тратить несколько дней, чтобы восстановить в памяти ее полную картину, конечно же, «выгрузив» информацию обо всех остальных частях. Если бы мы с командой не вели подробную документацию, то вряд ли смогли заниматься столь комплексными проектами. Короче говоря, у нас есть пределы наших физических возможностей, и они определяют границы сложности решаемых задач.

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

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

Как видите, традиционные подходы тоже имеют свои ограничения и особенности. Обычно фиксированные команды формируются в компаниях под реализацию и последовательное развитие одного продукта либо для оказания типовых услуг, например, как было сказано выше, по внедрению определенной CRM-системы. Иными словами, такая команда имеет специализацию, а как подсказывает эволюция, узкая специализация приводит к вымиранию вида. Достаточно, чтобы изменилась среда обитания, и привычные навыки перестают работать. В случае с цифровыми системами это означает, что команду, заточенную под конкретный продукт, придется переформировывать в случае изменения задач, что произойдет неизбежно.
В третьей главе я описывал циклы развития бизнеса и используемых в нем цифровых инструментов как череду проектов разных типов: вначале создание новой бизнес-модели либо заимствование существующей («Мозги» или «Седина»), а после периода постепенного развития («Процедуры») и при достижении предела возможностей связки бизнес-модель/цифровой инструмент снова создание или заимствование. Поэтому даже если вы смогли изначально сформировать и зафиксировать проектную команду, логика развития бизнеса не позволит вам ее сохранить на всем протяжении жизни компании. Команды отличаются кардинально в зависимости от типа проектов, и на разных стадиях нужно будет привлекать разных специалистов.

Вывод состоит в том, что изменений в проектных командах не удастся избежать и к этому стоит подготовиться в любом случае, и уж тем более если вы работаете над проектами типа «Мозги». Принцип динамических команд как раз и дает необходимый для этого инструментарий в виде критериев, по которым следует выбирать участников и формировать команду в целом, а также задает подходы к ее управлению.
Выбор участников динамических команд
Цель динамических команд — с одной стороны, избежать «проклятия инструмента», а с другой — обеспечить проект именно теми специалистами, которые нужны для создания конкретного цифрового продукта, и именно в те моменты, когда это необходимо. Давайте для начала разберёмся, что это за «проклятие». Когда у вас в наличии есть несколько инструментов, вы не сможете избежать искушения воспользоваться каждым из них, независимо от того, требует того задача или нет. Возможно, вы помните момент в сериале «Клиника», когда уборщик весь эпизод ходил с электрическим резаком в поисках его применения, чтобы в конечном счете распилить новый стол доктора Келсы! Точно так же происходит, когда у вас на момент запуска проекта уже сформирована команда. Так бывает, например, когда одну и ту же команду переключают с одного проекта на другой. В результате у вас еще нет понимания того, кто из
специалистов нужен, но состав команды уже начинает определять образ будущего продукта. Это ведь сработавшийся механизм с выработанными подходами, предпочтениями в технологиях и способах решения задач. У вас, кажется, были другие цели, но вы ведь не позволите простаивать каждому из участников, так?

Теперь посмотрим на цель обеспечения проекта нужными специалистами. В основе второго принципа лежит идея, что команда формируется каждый раз заново в соответствии с потребностями конкретного проекта. Более того, по ходу работы ее состав должен динамически меняться с учётом текущих задач. Это является противоположностью подхода, когда над проектом работает группа универсальных специалистов, способных в случае необходимости подменить друг друга. И это неудивительно, т.к. под каждую задачу нужны свои знания и опыт. Вряд ли можно рассчитывать на качественный результат, если специалист находится «не на своём месте» и не сфокусирован максимально на том, что у него лучше всего получается.
Вообще, универсальность является условным понятием. Если еще можно говорить о какой-либо взаимозаменяемости между разработчиками, то представить себе такое для специализаций разных типов, например дизайнеров и системных архитекторов, просто невозможно. У этого есть еще и экономический аспект, описанный во второй главе. Вряд ли стоит тратить бюджет на дорогих специалистов, имеющих компетенции в разных областях, в то время как задачи четко определены и из них следуют конкретные требования к исполнителям. Одновременно с этим бывают ситуации, когда проект требует привлечения опытных специалистов с широким профессиональным кругозором, т.к. суть задач состоит в поиске нестандартных решений либо решений, лежащих на стыке разных дисциплин.

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

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

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

В коротком пересказе это выглядит следующим образом: сотрудниками банка, не обладающими достаточным уровнем компетенции и ответственности, составляется краткое конкурсное задание, представляющее собой фрагментарный набор функциональных требований, по странной традиции именуемый техническим заданием. Подобное описание, как правило, отражает личные представления конкретных менеджеров о том, как должен выглядеть и что должен делать цифровой продукт, в данном случае голосовой ассистент. К этому добавляются
Обратите внимание, что предварительная оценка и планирование работ в примере невозможны без определения состава команды, которая будет работать над проектом. Но как уже должно быть понятно, такой подход работает только в проектах, где нет того изначального уровня неопределенности, который присущ ситуациям запуска нового бизнеса либо кардинального изменения модели работы. А расширение способов взаимодействия банка со своими клиентами как раз является подобным изменением. В таких проектах первостепенной задачей является поиск принципиальной схемы решения того, какой должна быть связка бизнес-модели с цифровыми инструментами, а не ее техническая реализация. Другими словами, требуется сформулировать концепцию бизнес-продукта. Под такую задачу и следует искать специалистов. После того как концепция будет готова и пройдёт проверку, можно будет определить требования к участникам следующих этапов проекта. Получается, что результаты работы одних специалистов являются необходимыми вводными для следующих этапов проекта, а заодно и способом определения того, как дальше должна поменяться проектная команда.
Как говорил мой друг, чтобы понять, как потратить миллион, вначале нужно потратить сто тысяч. Хотя в случае с проектами полная ясность наступает только в самом конце. Одни решения приводят к пониманию следующих шагов, но те, в свою очередь, являются новыми вопросами, на которые нужно найти ответы, и так до полной готовности продукта. Выбрав на начальной стадии специалистов, которые смогут сформулировать концепцию, им в дальнейшем нужно будет выбрать тех, кто сможет спроектировать продукт, а те должны будут определить критерии, по которым сформируется команда разработки и т.д. Иногда это одни и те же люди, выполняющие разные задачи на нескольких стадиях проекта, иногда разные. Это в равной степени относится ко всем возможным ролям в проекте: дизайнерам, разработчикам, аналитикам, тестировщикам, менеджерам, проектировщикам, художникам, системным архитекторам, копирайтерам, инженерам по развертыванию и сопровождению.

Например, в случае с банком после готовности концепции продукта все еще нельзя сформировать команду
разработки, поскольку еще не произошел окончательный выбор технологий. Если мы говорим о голосовом ассистенте, то здесь все еще сложнее, т.к. основная сложность в его реализации лежит вовсе не в технологическом аспекте. Самым сложным является написание сценариев общения пользователей с системой. И только пройдя этот путь, проектировщики взаимодействия смогут сказать, с какими внутренними сервисами банка потребуется интеграция, например, для запроса остатков на счетах клиента или проведения операций. Каждый сервис может быть реализован по-разному и потребовать для интеграции разные инструменты, а значит, и специалистов с соответствующими компетенциями.
Проектирование динамических команд
Подведем промежуточный итог. Чем сложнее проект, тем выше неопределённость. Когда речь идет о типовом внедрении CRM, бухгалтерской системы или системы документооборота, то в большинстве случаев известен требуемый состав участников и определены все стадии проектного процесса. Фиксированная команда представляет собой часть технологии, на которую рассчитывает бизнес. Так же как бизнес рассчитывает и на конкретные характеристики внедряемого или разрабатываемого продукта. Но если цель — открыть в компании направление по новой бизнес-модели или запустить стартап, опирающийся на уникальный цифровой инструмент, то под вопросом находится сам способ достижения цели. Только в процессе поиска решения можно будет прийти к пониманию того, как будет выглядеть команда и как она должна динамически меняться по ходу проекта.

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

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

Принцип динамических команд не предполагает, что мы расширяем состав участников в случае каких-либо проблем со сроками в проекте. Цель состоит в другом, а именно в том, чтобы набор специалистов соответствовал задачам на предстоящем этапе проекта. Тем не менее это не снимает вопроса о том, как проявят себя новые участники проекта, а что еще важнее, насколько они смогут дополнить друг друга, работая совместно. Может быть, всё-таки это вопрос не имеет удовлетворительного ответа?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы ответить на этот вопрос, вернемся к определению сложной системы, а создаваемый цифровой продукт как раз ею и является. Сложная система состоит из разных частей, которые, взаимодействуя друг с другом, представляют собой нечто качественно другое, чем их сумма по отдельности. Это может быть как устройство или механизм, состоящий из физических деталей, так и что-то более виртуальное, как цифровая система, построенная из программных компонентов и графических элементов. В равной степени это относится и к бизнес-продуктам, представляющим собой сочетание частей разной природы — сотрудников компании, действующих в рамках бизнес-модели, и цифровых инструментов, с которыми они взаимодействуют. Даже абстракции через взаимодействие друг с другом становятся сложной системой, как, например, пространственная структура интерфейса в сочетании с графическим стилем бренда и пользовательскими сценариями превращаются в механизм, позволяющим людям взаимодействовать с сервисом.
Отвечают в проектах за создание сложных систем как раз те самые ключевые участники. Выстраивая системы и проектируя взаимодействие их частей друг с другом, они должны иметь представление о свойствах каждой части, а значит, владеть компетенциями, связанными с ними. Таким образом требования к ролям участников проекта определяются природой тех частей, из которых состоит система, над созданием которой они работают. Например, если вернуться к предыдущему абзацу, для проектирования бизнес-продукта помимо основной технической компетенции нужны еще знания и опыт в бизнесе. Точно так же, проектируя сценарии взаимодействия пользователя с системой через голосовой интерфейс, требуется понимание технических возможностей бэкенда, равно как и голосовой платформы, на которой реализуется система. Конечно, ключевой участник проекта может и должен опираться на экспертные мнения узких специалистов в каждой из областей, но общее решение в любом случае рождается в его голове.
Части цифрового продукта, из которых он состоит, при детальном рассмотрении тоже оказываются сложными системами. Чем более комплексным является продукт, тем больше уровней абстракций необходимо, чтобы понимать его устройство. За каждым из уровней должен стоять отдельный специалист. Таким образом, динамическая команда строится и развивается вокруг ключевых участников, образующих «несущую конструкцию» проекта, и представляет собой структуру, связанную с многоуровневой моделью продукта.

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

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

Чем, по сути, от такого чиновника отличается специалист,
принимающий решения, но не несущий за них ответственность? Бизнес в результате ошибочного проектного решения может понести существенные убытки, а участник проекта, принявшей это решение, по факту не потеряет ничего. Например, когда ИТ-архитектор выбрал неудачную техническую архитектуру, которая привела к значительному перерасходу бюджета на разработку; или когда UX-проектировщик создал непонятный для пользователей интерфейс, из-за которого резко сократился объем продаж интернет-магазина; наконец, когда бизнес-аналитик ошибся в определении процессов, вследствие чего итоговый продукт не стыкуется с внутренними системами и по большому счету оказывается неработоспособным. Как видно, ситуация, при которой ключевой участник имеет возможность влиять на конечный результат, но никак не ограничен в своих действиях, чревата серьёзными последствиями, что на самом деле обычно и происходит в проектах.

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

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

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

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

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

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

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

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

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

В реальной жизни мы сталкиваемся с этим в момент, когда обсуждаем с бизнесом вопрос того, как совместить фиксированный бюджет и тот факт, что до момента окончания проектирования невозможно спрогнозировать границы проекта, в том числе и финансовые. Эту дилемму мы разрешаем тем, что предлагаем рассматривать ограничения бюджета в качестве такого же фактора, как и все остальные, например, функциональные или технические требования, которые нужно учитывать при принятии проектных решений. Гораздо хуже потратить весь доступный бюджет, но так и не получить результат, чем гарантированно получить работающий цифровой инструмент для бизнеса, хоть и не столь масштабный, как в первоначальных мечтах.
Такими же ограничениями, которые нужно учитывать при проектировании цифрового продукта, являются доступные возможности команды. Это должно отражаться на всех уровнях — функциональном, интерфейсном и техническом, и как следствие, корректировать аспекты решения на уровне бизнеса. Давно ли на вашей опыте проектировщик задавался вопросом наличия специалистов, которые смогут «потянуть» сложность придуманной им архитектуры? Ответ, который я слышу от многих коллег — такого не было никогда. А по идее должно происходить в каждом проекте.

Давайте рассмотрим этот вопрос на практическом уровне. «Метод параноика» предполагает, что по мере прохождения стадий проекта и все большем погружении в детали степень технической проработки увеличивается. Так, при работе над концепцией продукта требуется выполнить техническую экспертизу и ответить на вопрос, существуют ли в принципе технические возможности реализации задуманного решения. Другими словами, стоит ли вообще ввязываться в проект. Одновременно с этим нужно понять, насколько сложно будет привлечь
специалистов с нужными компетенциями. Если выяснится, что цена вопроса высока либо специалисты недоступны, то требуется пересмотреть технические способы реализации продукта, а возможно, и принципиальную схему решения. И сделать это необходимо до, а не после завершения работы над концепцией.

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

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

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

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

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

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

Раннее включение ключевых участников служит цели «вживления» в тело проекта новых несущих конструкций, давая им время «врасти» и закрепиться. Они ведь могут и не прижиться. И только на следующем этапе, после того как мы убедились в их надежности, вокруг них формируется полный состав команды, отвечающий за ту или иную систему. Проект представляет собой в таком случае постепенно развивающийся организм. Отсюда и название принципа — динамические команды.
Большая часть элементов несущей конструкции имеет жизненный цикл, равный отдельным этапам проекта. Ключевые участники, из которых она состоит, включаются в проект по мере необходимости для работы над конкретными задачами, связанными с проектированием и реализацией цифрового продукта. Но среди них есть и те, кто поддерживает непосредственно проект. Такие люди являются носителями идей проекта и сохраняют его культуру. И обеспечивают связанность всех решений в проекте от начала и до конца. Одним из таких участников является продюсер, о котором будет говориться в следующей главе.
Управление динамическими командами
Для того чтобы пройти сложный путь от первоначального замысла до реального его воплощения в виде уникального цифрового продукта, одного наличия проектной команды недостаточно. Ею требуется еще и управлять. Поскольку динамические команды по своей природе отличаются от фиксированных команд, то и способы управления тоже должны быть другие.

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

Я считаю, что в современном мире абсурдна сама мысль
такого разделения, и более того, подобный подход и привел в результате к социально-экономическому кризису, который мы сейчас переживаем. Почему же это произошло только сейчас, не создав проблемы в прошлом? Все дело в сложности технологий, на которых базируется бизнес. Смотрите, до тех пор, пока уровень их сложности был относительно прост, знаний обычного человека хватало, чтобы в них разобраться. Административная иерархия совпадала с иерархией компетенций. Будучи руководителем, вы были способны как минимум разобраться в результатах работы своих подчиненных, а значит, принять решения на их основе.

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

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

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

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

Все вышесказанное означает, что специалисты в инженерных и креативных компаниях не должны быть «подчиненными» по отношению управленцам, выступая в роли исполнителей. Право принятия решений не должно быть обусловлено лишь наличием полномочий, не подкреплённых компетенциями. Вообще, как только в такой компании побеждают менеджеры, бизнес начинает стагнировать, теряя клиентов, либо упрощается до уровня «чистых» управленцев, переходя на понятную им торговлю «ресурсами», о чем я подробно писал во второй главе. Любимое их выражение «я не хочу знать, как вы это сделаете, но чтобы было готово к завтрашнему дню». Уважающие себя специалисты такого не терпят и уходят, а вместе с ними утрачивается способность компании создавать сложные продукты. В качестве примера можно вспомнить те же Nokia или Disney до начала сотрудничества с Pixar.
Вернёмся в наше время. Сейчас, когда бизнес строится не с использованием, а по самой своей сути на основе цифровых инструментов, знание технологий окончательно перестаёт быть вспомогательной компетенцией. Вдумайтесь, если бизнес-модель компании невозможна без сложных технологических продуктов, возможно ли ее создание и управление без их понимания? Если вы что-то не понимаете, то для вас это воспринимается как магия. А там, где магия, там возможно и чудо, например, такое, чтобы за короткий срок и без четких требований разработать цифровой сервис, который начнёт приносить прибыль. Но чудес, как известно, в этом мире не бывает.

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

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

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

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

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

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

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

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

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

Какие именно технологии для описания модели продукта вы будете использовать, не так важно. Это могут быть классические UML-диаграммы, это может быть смесь текстовых спецификаций, алгоритмических схем и графических макетов интерфейса. Важно то, какой у них жизненный цикл, и то, каким образом они структурированы. Об этом будет подробно рассказано в «чёрной книге» метода. Сейчас же я хотел остановиться на принципиальных аспектах подхода.

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

Мы в своей практике для подготовки спецификаций часто используем google-документы. Например, все тот же проектировщик формирует документ, описывая решения для частей будущего продукта. У тех, кто будет участвовать непосредственно в реализации, есть возможность обсудить детали решения еще до их передачи в разработку, что часто позволяет найти более удачные решения или разобраться с непонятными моментами.
Идея в том, что автор обладает полными правами редактирования, а участники обсуждения только правами на комментирование. Таким образом изменения в документ вносятся одним человеком, но по итогу общего обсуждения. То же самое может происходить в дальнейшем и на этапе разработки.

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

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

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

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

– Проектная команда для создания уникальных цифровых продуктов формируется под конкретные требования и представляет собой индивидуальное сочетание специалистов.

– В процессе работы над проектом состав участников команды динамически меняется в зависимости от состава задач.

– Состав задач, равно как и требования к участникам команды, определяются на основе результатов проектирования.

– Формирование команды является составляющей процесса проектирования.
– Поиск и проверка решений о составе проектной команды для следующей стадии проекта происходит в рамках текущей стадии, а окончательное подтверждение – в контрольной точке проекта между ними

– Основу проектной команды составляют ключевые участники, изначально ориентированные на техническое лидерство и координацию рабочих групп («железобетонное правило»).

– Ключевые участники самостоятельно или вместе с рабочей группой работают над цифровым продуктом в целом или над одной из его частей.

– Цифровой продукт представляет собой сложную систему, состоящую из частей, каждая из которых в свою очередь так же является сложной системой.

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

– Ключевые участники мультидисциплинарны и обладают компетенциями, позволяющими контролировать все части системы, над которой они работают.

– Границы ответственности ключевых участников проекта проходят по периметру систем, над которыми они работают.

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

– Участники проекта, будучи специалистами в инженерных и креативных дисциплинах, не являются подчинёнными по отношению к «чистым» управленцам

– Управление проектами рассматривается не как отдельная активность, а в качестве составляющей технологического процесса создания цифровых продуктов.
– Управление проектом выполняется ключевыми участниками проекта исходя из целей создания цифрового продукта в целом или одной из его частей.

– Накопление знаний о проекте и продукте происходит за счёт артефактов проектирования.

– Артефакты проектирования являются одновременно моделью будущего цифрового продукта и средой для коммуникаций между участниками проекта.
Made on
Tilda