Творчество против определенности
Переходим к третьей функции проджект-раннера, без которой нельзя говорить о продюсерском подходе как таковом. После того, как совместно с бизнесом будет найдено решение, его необходимо воплотить в цифровом продукте, и это возможно сделать только с привлечением других специалистов. Их работу нужно организовать, и ответственность за эту задачу – то, что отличает проджект-раннера от типичных ролей бизнес-аналитика, проектировщика и менеджера продукта.
В классических методологиях вопросами организации и управления занимается менеджер проекта, но для проектов типа «Мозги» необходим другой подход. Как было сказано в главе о гибких проектных командах, построение команды – тоже проектирование, завязанное на модель продукта, и для этой задачи роль администратора не подходит. Нужен тот, кто обладает достаточным уровнем компетенций и не выступает в роли исполнителя, которому поручают такую задачу, а сам является инициатором.
Как вы помните, идея продюсерского подхода в IT-проектах заимствована из киноиндустрии, в которой за долгие годы удалось создать интересную модель работы. Несмотря на сложность процесса, большое количество участников и необходимость соблюдения множества технологических процедур, на выходе удается получать шедевры. Хотя не каждый фильм или сериал может похвастаться уникальностью, процесс построен так, чтобы сохранялось пространство для творчества.
Я вижу два фактора, которые позволяют этого добиться. Первый состоит в том, что креативному процессу уделяется особое внимание, и он рассматривается в качестве отправной точки. Когда говорят об удачном фильме, отмечают прежде всего интересный сюжет, который лежит в его основе. Даже хорошо снятый с технической точки зрения, но лишенный смысла фильм не может считаться успешным. При этом отдельные необычные эпизоды не спасают ситуацию, так как весь сценарий должен быть связным, чтобы все складывалось в крепкую историю.
Этому аспекту посвящен принцип проектирования. Кажется, что он ограничивает необходимую свободу действий, но на деле выступает как инструмент поиска решений. Мне нравится думать о проектной работе как о контрольных точках, через которые нужно пройти. Во всем остальном у вас должно быть достаточно свободы для творчества. Из-за дороговизны технической реализации разделение на придумывание и создание вполне разумно. В киноиндустрии для этого используется сценарий и раскадровки, в IT – модель продукта на функциональном, интерфейсном и техническом уровне. И то и другое нужно, чтобы вовремя понять, хороши ли найденные решения, и правильно подойти к их воплощению. Поскольку при таком подходе плохие идеи умирают до того, как будут реализованы, в проекте можно позволить их придумать достаточно много, чтобы выбрать среди них наиболее интересные.
Второй фактор, влияющий на возможность создания уникальных фильмов, заключается в том, что под каждый проект собирается уникальная команда. Для воплощения конкретного замысла нужно подобрать наиболее подходящих людей. Трудно представить ситуацию, когда с одним и тем же составом актеров можно снять разные фильмы. У каждой роли есть свой образ и значение, и для их выражения нужны соответствующие люди. Это касается и других участников – сценаристов, операторов, каскадеров, художников и композиторов. Кинопродюсер или шоураннер здесь играет ключевую роль, работая в качестве проводника первоначальных идей и добиваясь, чтобы каждый участник процесса максимально соответствовал возложенным на него задачам. Тому, как этот подход нашел свое отражение в работе над IT-проектами, и будет посвящена эта часть главы.
Многим кажется, что современные методы создания цифровых продуктов позволяют добиваться таких же результатов, но я с этим не согласен. В нашей индустрии все устроено наоборот. Если попытаться собрать в одном проекте столько специалистов, сколько обычно участвует в съемках фильма, то его не получится даже организовать. У нас нет необходимых инструментов для координации и управления столь сложными проектами. Поэтому возможности творческого поиска заменяются жесткими процедурами, а уникальная команда – типовым набором ролей. Из предыдущей главы вы уже знаете, что этот подход нацелен на два типа проектов – «Процедуры» и «Седина», и их цель – предсказуемый результат. Но чтобы получить что-то нестандартное, нужны «Мозги».
Здесь проявляется противоречие, с которым многие сталкиваются в своей проектной практике. Нельзя рассчитывать на уникальный результат, не закладывая возможность непредсказуемого развития событий. Другими словами, бизнес хотел бы получить что-то особенное, при этом без риска потерять время и деньги. Но чудес не бывает. Новые, необычные решения рождаются из неопределенности. Чтобы создать пространство для свободного поиска идей, необходимо отталкиваться от целей проекта, а не от зафиксированного набора инструментов и состава специалистов. Единственное, что можно взять с собой в такой путь, это подходы, позволяющие контролировать неопределенность, как альпинисты, которые идут неизвестным маршрутом к вершине, берут с собой снаряжение для экстремальных условий.
В «Методе параноика» таким снаряжением служат принципы контроля неопределенности, описанию которых посвящена эта книга. Дальше я покажу, как первые два из них – проектирование и гибкие команды – помогают проджект-раннеру организовать проектную работу.
Жизненный цикл гибкой проектной команды в продюсерском подходе
Принцип проектирования, помимо трех правил, вводит понятие модели продукта, которая структурирует все решения, относящиеся к устройству создаваемого цифрового продукта. Модель работает и на организационном уровне, выступая связующим звеном между целями проекта и средствами для его выполнения. Используя ее, можно подобрать способы реализации принципиальной схемы, которые вписываются в границы возможностей бизнеса. Здесь вступает в действие принцип гибких проектных команд, определяющий способы выбора и организации участников проекта на основе модели продукта. Поскольку работа над проектами типа «Мозги» предполагает постоянную проверку гипотез и уточнение модели на все более детальном уровне, то команда, работающая над продуктом, также должна обновляться. Все это можно представить в виде шести последовательных шагов.
(1) Все начинается с выявления требований к участникам проектной команды на основе модели продукта. Основными критериями для этого служат профессиональные компетенции и опыт, соответствующие тем частям системы, над которыми каждому специалисту предстоит работать. Важно учитывать «железобетонное» правило: управление гибкими командами происходит на уровне ключевых участников, которые должны появиться заранее, чтобы микрокоманды образовывались вокруг них. Это означает, что помимо технических навыков, такие участники должны уметь координировать рабочие группы. Необходимо помнить: чем выше уровень абстракции, на котором работает специалист, тем более мультидисциплинарным он должен быть с учетом природы всех составных частей системы, за которую он отвечает.
(2) Имея требования к участникам команды, можно переходить к поиску потенциальных кандидатов и обсуждению с ними условий участия. В зависимости от обстоятельств проекта это могут быть как внутренние, так и внешние специалисты. Если продюсерский подход используется внутри крупной компании, ориентированной на оперативное перераспределение сотрудников между проектами, можно обойтись собственными силами. Справедлива и обратная ситуация, когда бизнес целенаправленно ищет «свежую кровь», способную привнести новые идеи в сложившуюся организацию. Конечно, возможен и комбинированный подход, при котором участники проектной команды подбираются как из своих, так и приглашенных специалистов. Независимо от этого, важно прийти к пониманию, кто именно может принять участие в проекте и на каких условиях.
(3) Далее следует интересный момент, который отличает описываемый подход от типичной проектной практики. В предыдущей части главы я говорил о необходимости достигнуть баланса между желаемым результатом проекта в виде цифрового инструмента, поддерживающего бизнес-модель, и границами сроков и бюджета, за пределами которых пропадает смысл создания продукта. Обычно после обозначения цели проекта, компания с упрямством пытается «прогнуть» и внешних подрядчиков, и своих сотрудников, чтобы любой ценой ее достигнуть. Бизнес забывает, что, выжимая все возможное, лишает себя преимуществ работы с мотивированными людьми. Но интеллектуальный труд не терпит подобного отношения, и уникальные задачи решаются только в атмосфере творческого поиска, а не в условиях непрерывного аврала и психологического давления. Поэтому нужно быть готовым к тому, что условия привлечения нужных специалистов окажутся за пределами доступных возможностей бизнеса или необходимых специалистов не окажется вовсе. В таком случае потребуется уточнить модель продукта, чтобы набор специалистов соответствовал возможностям бизнеса, сохраняя при этом необходимые функции системы.
Это настолько важно, что этому шагу в организации проектной работы стоит уделить еще один абзац. Что я имею в виду под уточнением модели продукта с учетом возможностей бизнеса? Обсуждение условий привлечения специалистов касается не только стоимости, но и предварительной оценки проектных задач, под которые подбираются специалисты. Гибкие команды формируются не путем «закупки» ресурсов на определенный срок, а через точечное подключение конкретных специалистов, исходя из логики технологического процесса создания системы. Когда мы прорабатываем с ними возможные способы реализации задач, то проверяем гипотезы, заложенные на уровне модели продукта. Нас интересует оценка и техническая экспертиза решений конкретными людьми, которые затем займутся их воплощением. Если не удается найти тех, кто способен выполнить работу в установленные сроки и в рамках бюджета, нужно менять модель продукта, например, упрощать ее или даже менять принципиальную схему решения.
(4) Получается, что согласование условий участия специалистов при гибком формировании команды напрямую связано со следующим шагом – передачей знаний о том, что требуется сделать в проекте. Пусть вас не сбивает с толку такая формулировка, будто процесс предполагает, что все решения приняты заранее и участники проекта лишь должны их исполнить. Проектирование как поиск идей и детализация модели продукта в проектах типа «Мозги» не прекращается в течение всего времени работы. Структура команды, построенная вокруг ключевых участников, способствует этому. Первым появляется проджект-раннер, рассматривает систему на самом верхнем уровне. Затем он подбирает следующих участников, которые занимаются отдельными подсистемами, проектируют их и дают обратную связь на более высокий уровень. Все это выстраивается вокруг модели продукта, которая выступает в качестве инструмента для постановки задач и определения границ возможных решений на каждом уровне.
(5) Если удается достигнуть необходимого баланса и сформировать команду, соответствующую модели продукта, то на следующем шаге проектный процесс переходит в активную фазу. Специалисты включаются в работу над задачами и между ними начинаются регулярные коммуникации. Средой для этого, согласно принципу гибких команд, выступает проектная документация. В ней накапливается информация о принимаемых решениях, и она обеспечивает одинаковое видение устройства продукта всеми участниками проекта. Еще одним аспектом здесь является управление командой. Поскольку ее работа опирается на ключевых участников, вокруг которых образуются микрогруппы, они тоже выступают в роли проджект-раннеров, каждый на своем уровне. Так работает «несущая конструкция проекта».
(6) Завершающим шагом является проверка результатов работы проектной команды. Мы должны быть уверены, что достигнуты первоначальные цели, а не просто выполнены поставленные задачи. Инструментом для такой проверки выступает все та же модель продукта, которая служит эталоном для сравнения. Такой подход позволяет понимать статус проекта в понятной для всех участников системе координат. Сравнивая код с моделью продукта и выявляя места расхождения, мы можем говорить о готовности частей продукта и степени их соответствия модели, а не оперировать количеством строчек кода или произвольными процентами готовности, не имеющими отношение к реальности.
Вернемся к общей схеме. Первые три шага образуют цикл, в рамках которого выбираются способы реализации цифрового продукта и формируется проектная команда. Это не просто последовательные шаги, а именно цикл. Если для нахождения баланса между параметрами проекта и ограничениями со стороны бизнеса мы вынуждены изменять решения на уровне устройства продукта, то это также заставляет обновлять требования к составу команды, пересматривать кандидатов и условия их привлечения на проект. И так до тех пор, пока решения, заложенные в модель продукта, не пройдут экспертизу и не будут увязаны с организационным уровнем. Только после того, как появится уверенность в их реализуемости, можно переходить к следующим шагам.
Далее в течение каждой стадии проекта работает второй цикл, образующийся из следующих трех шагов. Они составляют основную часть работ по созданию продукта. В зависимости от характера конкретной стадии и особенностей проекта это может быть исследование и поиск новых решений, проектирование и дизайн, разработка и тестирование, или их комбинация. Все это выполняет команда, сформированная на предыдущих трех шагах. Ее состав, будучи очередной версией гибкой проектной команды, существует на отрезке между двумя контрольными точками. Поскольку за это время представление об устройстве создаваемого продукта уточняется, то при приближении к следующей контрольной точке проджект-раннер должен снова запустить цикл для выявления требований к составу участников. Это необходимо для проверки реализуемости обновленной модели продукта и подготовки другой версии команды для следующей стадии проекта.
Шкура проджект-раннера на кону проекта
Цель жизненного цикла гибкой команды – обеспечить проект нужными специалистами для реализации конкретного уникального проекта типа «Мозги», и при этом не выйти за границы возможностей бизнеса. Здесь требуется «мотор», приводящий механизм в движение. Для того, чтобы проджект-раннер мог им быть, необходимо соблюсти некоторые условия.
Прежде всего он должен нести личную ответственность, «ставить шкуру на кон», как говорит Талеб. Обычный наемный сотрудник здесь не подойдет, потому что проджект-раннер – это тот, кто смотрит на проект на самом высоком уровне, а значит, принимает решения, касающиеся всех аспектов. Цена ошибки крайне высока, поэтому у его полномочий должен быть противовес для необходимого равновесия. Любой вопрос в проекте, будь то согласование условий привлечения специалистов в команду, выбор принципиальной схемы решения или определение критериев качества продукта, проджект-раннер должен воспринимать как личный, и чувствовать угрозу возможных потерь. Для него подставить бизнес и свою команду должно ощущаться так же, как подставить себя.
Такое возможно только в случае, когда пересекаются векторы интересов участников. Сами же интересы могут быть разными. Например, для владельца компании важно увеличить прибыль и выйти на международный рынок, что подтвердит его статус успешного предпринимателя, но это не значит, что проджект-раннер хочет добиться того же. Его личным интересом может быть профессиональная самореализация или возможность создать какой-то значимый для индустрии продукт. Это, конечно, не отменяет финансовой заинтересованности, но только она не может быть достаточной причиной. Я еще не видел крутых проектов, где их участниками двигало только желание заработать. Не забывайте об этом при размышлениях о мотивации.
Стремление к цели часто толкает нас на необдуманные действия, и только угроза серьезного проигрыша может привести нас в чувства. Лоцман, ведущий корабль по сложному маршруту, знает, что из-за ошибки может потопить судно и утонуть вместе с ним, и это заставляет его быть внимательным. Так же и проджект-раннер должен быть дальновидным и заинтересованным в том, чтобы довести проект до конечной цели, зная, что в случае серьезных просчетов ко дну пойдет не только проект, но и его надежды на красивую жизнь вместе с профессиональной репутацией.
Чтобы проджект-раннер был готов взять на себя такую ответственность, он должен иметь положительный вектор мотивации – его интерес должен быть выше, чем страх возможных потерь. С первым все понятно. Уверен, вы бывали в ситуациях, когда задачи настолько амбициозные и увлекательные, что кажется, над ними можно поработать и бесплатно. Я уже говорил, что классные специалисты всегда находятся в поиске интересных проектов, на которых они могут вырасти еще больше. Если к этому добавляется возможность получить солидное денежное вознаграждение, то проект и вовсе выглядит мечтой. В ряде случаев проджект-раннер может договориться с бизнесом о доле с прибыли, как это часто бывает в стартапах, или рассчитывать на крупную премию, если проект внутри компании.
Со страхом потерь все немного сложнее. При попытке сделать что-то уникальное всегда есть риск потерпеть неудачу. Например, решение может быть не найдено, или оно слишком дорогое и сложное в реализации. Запуская проекты типа «Мозги», бизнес должен быть готов к тому, что все пойдет не по плану. Если переложить эти риски на плечи проджект-раннера, он справедливо посчитает, что игра того не стоит. Ведь, как говорил герой фильма «Револьвер» Гая Ричи, «ничто не ранит больше, чем потеря денег и унижение».
Значит нужно провести границу ответственности, чтобы проджект-раннер не рассматривал проект как оплачиваемое развлечение и при этом не был демотивирован размером возможного личного ущерба. Для этого, согласно Талебу, вероятность выигрыша должна быть выше, а проигрыш не должен быть смертельным. Применим эту идею к разным ситуациям и рассмотрим, как могут выстраиваться отношения проджект-раннера с бизнесом.
Начну с утверждения, что степень нашей вовлеченности обычно равна уровню риска, который мы на себя берем. Когда мы идем по канату над пропастью без страховки, наша концентрация составляет 100 %, и мы вряд ли будем отвлекаться. Во время прогулки по набережной, кроме того, чтобы смотреть под ноги, мы успеваем общаться с друзьями и размышлять о всякой ерунде.
В проектной работе это выражается в том, насколько проджект-раннер может сфокусировать свое внимание и как глубоко готов погрузиться в задачу для достижения целей проекта. Разные проекты требуют разной степени вовлеченности. Вы не можете просто потребовать максимальной внимательности от человека, не поставив его в ситуацию принятия риска. Чем больший риск берет на себя проджект-раннер, тем большее он рассчитывает получить, и речь идет не только о деньгах. Бизнес должен сопоставлять реальную потребность в вовлеченности проджект-раннера и цену, которую он готов ему за это заплатить.
У этого есть и другая сторона. Не каждый готов, а самое главное, способен принять на себя риск и связанные с ним последствия. Это зависит как от психологических особенностей людей, так и от возможностей. Например, вы можете потребовать компенсации за сорванные сроки проекта, но если человек или организация не способны ее выплатить, то какой в этом смысл? То же относится и к самому пониманию того, в чем именно заключается риск. Для этого требуется личная и профессиональная зрелость, которой обладают далеко не все претенденты на участие в сложных проектах.
Для снижения риска можно использовать принципы контроля неопределенности, которые заложены в «Методе параноика», но у всего есть предел. В некоторых проектах риск неизбежен, например, когда успех зависит от исследовательских задач и невозможно спрогнозировать, сколько времени займет их выполнение. Похожая ситуация складывается в проектах, ориентированных на принципиально новые бизнес-модели, где неясно, как примут продукт пользователи. Везде, где степень риска невозможно заранее просчитать, важно понимать, каким запасом прочности обладают участники проекта и до каких издержек они готовы дойти. Это также следует использовать в качестве одного из факторов, который нужно учитывать и на уровне проектирования, и на уровне организации проектной работы.
Чем больший риск берет на себя человек, тем большим контролем за ситуацией он должен обладать. Как канатоходец над пропастью, вы вряд ли согласитесь на трюк, если не сможете выбрать материал для каната, время суток, когда солнце не будет вас слепить, и погодные условия, чтобы избежать дождя и ветра. То же самое относится и к проектной работе, где имеют значение выбор людей в команду, технологии, способы управления и бюджетирования, плюс все решения, относящиеся к устройству цифрового продукта. Как проджект-раннер вы обязательно должны контролировать ключевые параметры проекта, ведь от них зависит получится у вас добиться нужного результата или нет. И это, вероятно, самый сложный для бизнеса момент, поскольку деньгами он еще готов поделиться, но вот передать часть контроля, как правило, нет.
Здесь я должен привести последний аргумент в пользу подхода, когда проджект-раннер наделяется достаточными полномочиями для управления процессом создания цифрового продукта. Делать что-то хорошо можно только когда веришь в сам продукт, и в методы работы над ним. Не принимая идеи, лежащие в основе бизнес-модели компании, вряд ли получится продуктивно находить способы их реализации. Возможно, для вас будет сюрпризом, но большинство IT-проектов терпят неудачу, и специалисты из нашей отрасли часто теряют уверенность, что их работа имеет хоть какое-то значение. В результате многие включаются в проекты без веры в успех. Для них это просто способ заработка, без уважения к ценностям бизнеса, с которым они взаимодействуют. Получается негативный замкнутый цикл.
Чтобы его разорвать, проджект-раннер должен изначально оценивать реалистичность замысла со стороны бизнеса, и в этом он может полагаться только на свое профессиональное чутье. Зачастую на бумаге все выглядит убедительно, но, если интуиция подсказывает, что не все так гладко, как может казаться владельцу компании, с этими подозрениями стоит разобраться, прежде чем приступить к работе. В терминах принципа проектирования это означает уменьшить неопределенность и только после этого двигаться дальше или не двигаться, отказавшись от участия в проекте. Если проджект-раннер будет действовать по навязанным правилам, в которых он не уверен или которые вызывают у него неприятие, то говорить о готовности взять ответственность на себя вряд ли получится. Напротив, будучи уверенным в предлагаемой бизнес-модели продукта и опираясь на подтвержденные опытом инструменты и методы организации проектной работы, проджект-раннер сможет по-настоящему проникнуться целями проекта и передать эту вовлеченность проектной команде.
Цена привлечения проджект-раннера
Теперь, когда есть концептуальное понимание взаимосвязи между полномочиями, мотивацией и принимаемым на себя риском, можно рассмотреть подходы к проектам, которые требуют разной степени вовлеченности проджект-раннера. Да, кажется, что в большинстве случаев необходима его максимальная концентрация на проекте, но у этого есть своя цена, и она не всегда оправдана.
(1) Когда не стоит вопрос о внесении изменений в бизнес-модель и необходимо обеспечить лишь технологическую реализацию, например, онлайн-сервисов, от проджект-раннера требуется только спроектировать продукт и подобрать необходимых специалистов, организовав проектную работу. Так обстоят дела в компании, которая занимается развитием своих цифровых инструментов в рамках сложившейся схемы работы. Если принципиальная схема решения уже сформулирована, не стоит повышать ставки и искать способы мотивации проджект-раннера для высокой вовлеченности в проект. Это начальный уровень, когда его роль совмещает в себе менеджера проекта, проектировщика и менеджера продукта.
При таком сочетании ролей проджект-раннеру должно быть достаточно полномочий в определении способа воплощения принципиальной схемы решения, то есть устройства продукта, плюс права подбора команды и организации проектной работы по своему усмотрению. Кроме возможности поучаствовать в интересном проекте, мотивацией может быть достаточно крупное вознаграждение. На него можно смотреть как на страховую премию бизнеса, и риск проджект-раннера состоит в том, что если ему не удастся достигнуть поставленных целей проекта, то она не выплачивается. Без дополнительного вознаграждения оплата работы проджект-раннера должна быть сопоставима с зарплатой мультидисциплинарного специалиста, кем он и является на начальном уровне. Успехом проекта будет считаться соответствие характеристик цифрового продукта изначальным целям, что никак не связано с возможными коммерческими результатами его использования. Проджект-раннер не участвует в формировании бизнес-модели, ответственность полностью на стороне бизнеса.
(2) Иначе обстоят дела в компании в момент ее трансформации. У владельцев уже есть понимание необходимости изменений бизнес-модели, но чтобы понять, в чем они могут состоять, может потребоваться помощь в анализе возможностей цифровых технологий. Это как раз тот момент, когда к работе должен подключиться проджект-раннер, и, в отличие от обычного технического консультанта, уже на столь ранней стадии от него потребуется высокий уровень вовлеченности. Только так он сможет правильно расставить акценты и подобрать подходящие технологические инструменты, на которые станет опираться новая бизнес-модель. Вряд ли вы будете спорить, что эффективность усилий не только проектной команды, но и бизнеса в целом, будет полностью зависеть от точности такого выбора.
В подобной ситуации вопрос качественной технической реализации конкретного цифрового продукта важный, но не первостепенный. Радикальные изменения в работе компании всегда связаны с большими рисками, и бизнесу стоит найти способ заинтересовать проджект-раннера, чтобы не потерять еще больше. Например, это могут быть проценты от экономии расходов компании за счет использования внутреннего технологического инструмента, созданию которого посвящен проект, или выплаты, пропорциональные коммерческому успеху нового онлайн-сервиса. Давая проджект-раннеру возможность заработать на результатах своей деятельности, бизнес фокусирует его на поиске коммерчески выгодных продуктовых решений.
Вполне ожидаемо, что полномочия проджект-раннера должны быть шире, чем просто управление проектом по своему усмотрению. Он должен контролировать в том числе аспекты устройства работы компании, выраженные в принципиальной схеме решения. Способом установить баланс ответственности служит то, что бюджет проекта, выделяемый бизнесом, – это фактически его бюджет, который находится под его управлением. При его превышении для проджект-раннера существует риск оплатить работу специалистов из своих средств. Он выступает гарантом того, что согласованный бюджет позволит реализовать запланированный объем задач. Конечно, имеет значение характер работ на каждой стадии проекта и подход к прогнозированию, о чем подробнее будет рассказано в следующей главе.
Ответственность проджект-раннера на данном уровне вовлеченности не распространяется на возможную коммерческую неудачу использования продукта. Его риски связаны только с собственными ошибками в управлении и проектировании. Издержки, которые может понести компания из-за новой бизнес-модели, полностью лежат на стороне владельцев, поскольку это их уровень принятия решений. Кроме цифровых инструментов, на успех влияют и другие факторы, которые находятся вне контроля проджект-раннера. Эта граница ответственности нужна, чтобы интерес проджект-раннера был выше угрозы потерь, обеспечивая необходимый уровень вовлеченности.
(3) Существуют проекты, где от проджект-раннера может потребоваться не просто высокая, а экстремальная вовлеченность. Речь идет о высокотехнологичных стартапах, аналогом которых в корпоративной среде может быть запуск новых направлений в бизнесе. И там, и там проджект-раннер чаще всего выступает не в роли приглашенного консультанта и организатора, а становится соучастником амбициозного замысла, по крайней мере на отрезке жизни компании, пока она не достигнет зрелости. Это означает, что в случае со стартапами продюсерский подход может использоваться самими предпринимателями, если у них достаточно технических компетенций.
Цель состоит в нахождении новой бизнес-модели, которая сможет доказать свою работоспособность на практике. Неопределенность таких проектов требует непрерывной проверки различных гипотез и изменения направления развития как продукта, так и бизнеса в целом. Проджект-раннер, как активный участник, должен не противодействовать изменениям, а наоборот, иметь мотив к поиску наилучшего сочетания схемы работы компании и цифровых инструментов. В этом ему может помочь возможность воплощать собственные концепты, о которых я рассказывал в «Кодексе проектировщика». Бизнес будет рад получить источник новых идей в его лице. На таком взаимном интересе и могут сойтись владельцы новой компании и проджект-раннер.
Неудивительно, что при таком уровне вовлеченности полномочия проджект-раннера приближаются к тем, которыми обладают организаторы бизнеса. Он по-прежнему определяет принципиальную схему решения и то, каким образом будет реализован цифровой продукт, но к этому добавляется его участие в решении того, какова будет схема работы компании. Право голоса при формулировании бизнес-модели достается не просто так. Проджект-раннер вкладывает в проект свои собственные средства. Объем вложений может отличаться от проекта к проекту, но в любом случае дает право претендовать на долю в прибыли компании. Риск тоже понятен – при неудаче вложения в проект могут не вернуться.
Сочетание интересов бизнеса и специалистов
Проджект-раннер, имея прямую связь с бюджетом, уже не может его рассматривать просто как цифры в таблице. В отличие от наемного менеджера, он знает цену деньгам, которыми оплачивается работа над проектом. Считайте это KPI прямого действия, который меняет его отношение ко всем аспектам проекта и позволяет иначе решить вопрос сочетания интересов бизнеса и специалистов. Это одна из сильных сторон продюсерского подхода.
В противоположность этому обычным способом согласования условий проекта служит игра «Угадай, если сможешь». Именно так стоит смотреть на конкурсы и тендеры. От потенциальных исполнителей проекта ожидается, что они предложат условия, которые устроят заказчика, но почему эти условия именно такие, им не сообщается. Хотя из бизнес-модели компании естественным образом следуют ограничения бюджета и сроков реализации необходимых для нее цифровых инструментов, это вовсе не значит, что данные ограничения являются константой. Вместо того, чтобы объяснить потенциальным участникам причины ограничений проекта, из них выбирается один из вариантов, который попал в диапазон допустимого бюджета и сроков. Остальные предложения даже не рассматриваются.
Победителю тендера кажется, что его выбрали за лучшее предложение, но он не знает объективных причин. Это незнание создает проблемы для проекта в будущем, потому что у команды нет понимания настоящих целей, и она не может соизмерять свои технические решения с ними. Между целями бизнеса и функциональными требованиями, которые обычно указываются в техническом задании, лежит огромная разница. То, что кажется специалистам безобидным отклонением от заданных параметров в свойствах проекта, на деле оказывается критическим с точки зрения бизнеса. Но ни у одной из сторон нет возможности понять позиции друг друга.
Проблема в том, что для бизнеса вопрос оценки и планирования проекта – это одно, а для специалистов – другое. Каждая сторона смотрит на согласование условий со своей точки зрения. Специалисты обычно не понимают, что бизнес интересует только решение его задачи, и все варианты рассматриваются с позиции окупаемости затрат. Бизнес тоже не учитывает, что любая оценка со стороны проектной команды – всего лишь гипотеза из-за неопределенности, о которой уже столько было сказано в этой книге.
Напомню, что существует две модели работы компаний, выполняющих проекты. Первая – торговля ресурсами, в данном случае рабочим временем специалистов, например программистов или дизайнеров. Это пресловутые человеко-часы, которые можно по-разному упаковывать. Вторая – продажа и применение уникальных знаний, значимость которых раскрывается применительно к конкретному заказчику. Их нельзя измерить с точки зрения затраченного времени исполнителя, поскольку это либо готовая методика или технология, либо креативные задачи.
Если известно, какие задачи нужно выполнить и какие для этого нужны ресурсы, а это, как правило, проекты типа «Процедуры» и «Седина», то работа по первой модели оправдана. Если же решение только предстоит найти, как в проектах типа «Мозги», нужна вторая модель. Изменение схемы работы компании с использованием цифровых инструментов или запуск нового направления – как раз такой случай. В них вы не сможете поставить задачу и организовать тендер, чтобы привлечь команду на конкурсной основе. Нужен тот, кто разговаривая с бизнесом на одном языке, найдет решение и переведет его в понятную специалистам форму.
В «Методе параноика» такую функцию выполняет проджект-раннер, и его роль состоит в запуске уникальных проектов. Он, как вытяжной парашют, тянет за собой все остальное. Проджект-раннер подобен «Психотерапевту», который ставит диагноз и организует процесс, привлекая при необходимости «Фармацевтов» (команды специалистов с типовыми компетенциями в разработке, дизайне и т. д.), «Сиделок» (маркетинговые и рекламные агентства) и «Нейрохирургов» (системные интеграторы, высококлассные профессионалы и уникальные креативные студии). Проджект-раннер знает модели ценообразования и понимает ограничения бизнеса и цели заказчика, он выбирает подходящих участников, опираясь на принцип гибких проектных команд. Происходит ли это через конкурсы или прямые договоренности с подрядчиками, не так важно. Главное, что проджект-раннер разделяет риски и несет ответственность за результат проекта. Он фокусируется на достижении целей бизнеса и добивается, чтобы итоговый продукт соответствовал заданным параметрам.
В отличие от обычных менеджеров, проджект-раннер знает, что при планировании проекта задачи не конвертируются напрямую в человеко-часы. Оценка со стороны исполнителей никогда не может быть достоверной, а таблица с функциями продукта и ожидаемыми трудозатратами – это плод фантазии. Важна только фактическая производительность конкретной команды. Ее замер на реальных задачах является обязательной процедурой и позволяет проджект-раннеру объективно оценивать возможности новой команды. Если они не укладываются в необходимые параметры, то ищется другая команда или меняется устройство продукта под возможности доступных специалистов.
Интересно, что когда я только собирал материалы для этой главы, то искал примеры того, как подобный подход используется в других индустриях. Я хотел показать, что продюсирование – неизбежная модель в современном мире, и был очень удивлен, когда наткнулся на рассказ о постройке самой крупной ракеты в истории человечества для полета на Луну[1]:
«Ракета обладала беспрецедентной сложностью. Стоял вопрос, кто будет ее строить. Фон Браун выбрал разделение труда. Это позволяло ему выбирать лучших из лучших во всей промышленности. Он мог задействовать самых опытных людей из каждой из компаний. Скорость разработки действительно получилась высокой. Для подрядчиков решение означало крупные заказы, а не огромный заказ для кого-то одного. В итоге основная доля распределялась между тремя компаниями: «Боинг», North American Aviation и «Дуглас». Они производили три ступени, из которых состоит «Сатурн-5»…
…За работой подрядчиков следили две группы в Космическом центре Маршалла. Отдел Research and Development Operations следил за целостностью структуры ракеты, а Industrial Operations перечислял денежные средства и принимал работу…»
Если такая схема сработала в 60-х годах прошлого века, то в современном мире это тем более возможно, и наш проектный опыт неоднократно это доказывал. Продюсерский подход дает необходимую гибкость и, подобно Фон Брауну, позволяет строить распределенные команды из самых классных специалистов. Опираясь на принципы проектирования и гибких проектных команд получается выстраивать коммуникации между участниками и управлять процессом создания продуктов. Учитывая, что сейчас многие профессионалы выбирают образ жизни цифровых кочевников, описанный подход становится единственно возможным ответом на вызов времени.