Принцип проектирования, помимо трех правил, вводит понятие модели продукта, которая структурирует все решения, относящиеся к устройству создаваемого цифрового продукта. Модель работает и на организационном уровне, выступая связующим звеном между целями проекта и средствами для его выполнения. Используя ее, можно подобрать способы реализации принципиальной схемы, которые вписываются в границы возможностей бизнеса. Здесь вступает в действие принцип гибких проектных команд, определяющий способы выбора и организации участников проекта на основе модели продукта. Поскольку работа над проектами типа «Мозги» предполагает постоянную проверку гипотез и уточнение модели на все более детальном уровне, то команда, работающая над продуктом, также должна обновляться. Все это можно представить в виде шести последовательных шагов.
(1) Все начинается с выявления требований к участникам проектной команды на основе модели продукта. Основными критериями для этого служат профессиональные компетенции и опыт, соответствующие тем частям системы, над которыми каждому специалисту предстоит работать. Важно учитывать «железобетонное» правило: управление гибкими командами происходит на уровне ключевых участников, которые должны появиться заранее, чтобы микрокоманды образовывались вокруг них. Это означает, что помимо технических навыков, такие участники должны уметь координировать рабочие группы. Необходимо помнить: чем выше уровень абстракции, на котором работает специалист, тем более мультидисциплинарным он должен быть с учетом природы всех составных частей системы, за которую он отвечает.
(2) Имея требования к участникам команды, можно переходить к поиску потенциальных кандидатов и обсуждению с ними условий участия. В зависимости от обстоятельств проекта это могут быть как внутренние, так и внешние специалисты. Если продюсерский подход используется внутри крупной компании, ориентированной на оперативное перераспределение сотрудников между проектами, можно обойтись собственными силами. Справедлива и обратная ситуация, когда бизнес целенаправленно ищет «свежую кровь», способную привнести новые идеи в сложившуюся организацию. Конечно, возможен и комбинированный подход, при котором участники проектной команды подбираются как из своих, так и приглашенных специалистов. Независимо от этого, важно прийти к пониманию, кто именно может принять участие в проекте и на каких условиях.
(3) Далее следует интересный момент, который отличает описываемый подход от типичной проектной практики. В предыдущей части главы я говорил о необходимости достигнуть баланса между желаемым результатом проекта в виде цифрового инструмента, поддерживающего бизнес-модель, и границами сроков и бюджета, за пределами которых пропадает смысл создания продукта. Обычно после обозначения цели проекта, компания с упрямством пытается «прогнуть» и внешних подрядчиков, и своих сотрудников, чтобы любой ценой ее достигнуть. Бизнес забывает, что, выжимая все возможное, лишает себя преимуществ работы с мотивированными людьми. Но интеллектуальный труд не терпит подобного отношения, и уникальные задачи решаются только в атмосфере творческого поиска, а не в условиях непрерывного аврала и психологического давления. Поэтому нужно быть готовым к тому, что условия привлечения нужных специалистов окажутся за пределами доступных возможностей бизнеса или необходимых специалистов не окажется вовсе. В таком случае потребуется уточнить модель продукта, чтобы набор специалистов соответствовал возможностям бизнеса, сохраняя при этом необходимые функции системы.
Это настолько важно, что этому шагу в организации проектной работы стоит уделить еще один абзац. Что я имею в виду под уточнением модели продукта с учетом возможностей бизнеса? Обсуждение условий привлечения специалистов касается не только стоимости, но и предварительной оценки проектных задач, под которые подбираются специалисты. Гибкие команды формируются не путем «закупки» ресурсов на определенный срок, а через точечное подключение конкретных специалистов, исходя из логики технологического процесса создания системы. Когда мы прорабатываем с ними возможные способы реализации задач, то проверяем гипотезы, заложенные на уровне модели продукта. Нас интересует оценка и техническая экспертиза решений конкретными людьми, которые затем займутся их воплощением. Если не удается найти тех, кто способен выполнить работу в установленные сроки и в рамках бюджета, нужно менять модель продукта, например, упрощать ее или даже менять принципиальную схему решения.