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