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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подобно тому как может накапливаться опыт работы

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

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

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

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

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

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

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

Последствия такого подхода хорошо известны. Появление

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

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

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

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

не приходится «ломать».

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

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

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

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

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

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

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

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

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

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

решат, как продукт будет реализован технологически.

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

Подобный подход работает на относительно простых и типовых проектах, где не стоит задачи поиска новых решений. Проектах, где фиксированные команды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

надёжности решения не было уделено достаточно внимания, и часто связана с уровнем привлекаемых на этом этапе участников проекта.

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

Стоимость привлечения специалистов и их доступность для проекта определяют не только решения на техническом уровне, но и влияют на организацию

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

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

задачах у нас не остаётся времени.

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

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

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

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

Большая часть элементов несущей конструкции имеет жизненный цикл, равный отдельным стадиям проекта.

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

и от целей проекта, и от целей развития компания.

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

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

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

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

принятии решений, нужно глубокие знания в предметной области.

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

Вернёмся в наше время. Сейчас, когда бизнес строится не

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

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

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

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

Следуя этой логике, если ключевой участник проекта, отвечающий за определённую систему или подсистему

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

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

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

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

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

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

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

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

«Метод параноика» меняет порядок и рассматривает документацию как описание не того, что уже сделано,

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

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

Прежде всего проектная документация, а не списки задач

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

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

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

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

Соединяя формат коммуникаций, основанный на

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

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

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

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