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