и создаёт возможность их воплощения на практике.

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

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

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

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

ответственность, которая заставляет ключевого участника — продюсера — правильно расставлять приоритеты и учитывать все существенные факторы ещё на этапе проектирования.

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

Тем не менее здесь присутствует интересный момент.

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

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

участники проектной команды, так и внешние специалисты могут выступать в ролях «Фармацевтов» (команды специалистов с типовыми компетенциями в разработке, дизайне и т.д.), «Сиделок» (маркетинговые и рекламные агентства) и даже «Нейрохирургов» (системные интеграторы, высококлассные профессионалы и уникальные креативные студии).

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

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

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

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

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

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

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

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

Если суммировать все сказанное выше, то можно выделить три ключевые функции продюсера, а вместе с ними

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

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

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

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

команд называется «несущей конструкцией проекта».

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

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

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

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

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

Кто должен заниматься сексом с вашей женой

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

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

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

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

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

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

В конечном счёте те же P&L и cashflow, а вместе с ними все возможные метрики и индикаторы — это только средства контроля, но важно себя спросить, а контроля чего именно? Ответить на этот вопрос и должен владелец компании или руководитель одного из направлений. Именно от него требуется нащупать схему работы, которая сможет принести прибыль, быть жизнеспособной и устойчивой на определённом промежутке времени, за который «отобьются» вложения в её реализацию. Согласно принципу динамических команд, он тоже ключевой участник проекта, рассматривающий бизнес как систему на соответствующем уровне абстракции.

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

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

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

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

продолжительное время и извлекать из этого пользу.

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

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

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


Доверенное лицо бизнеса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

процессы так, чтобы вовсе избежать решения задачи.

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

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

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

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

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

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

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

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

то нового и амбициозного.


До цифрового продукта

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

Иногда попросту не ясно, какую информацию нужно

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

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

своим взглядом весь продукт?

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

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

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

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

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

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

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

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

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

просто не будет существовать.

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

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

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

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

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


Баланс вместо компромисса

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

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

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

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

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

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

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

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

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

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

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

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

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

прийти к приемлемой конфигурации проекта на всех его уровнях.

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


Скрепы проектного бутерброда

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

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

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

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

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

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

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

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

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

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

посвящена эта часть главы.

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

Здесь проявляется противоречие, с которым многие сталкиваются в своей проектной практике. Нельзя

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

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

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

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

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

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

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

Это настолько важно, что этому шагу в организации

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

(4) Получается, что согласование условий участия специалистов при формировании динамической команды

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

(5) Если удаётся достигнуть необходимого баланса и сформировать команду, соответствующую модели продукта, то на следующем шаге проектный процесс

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

(6) Завершающим шагом является проверка результатов работы проектной команды. Мы должны быть уверены, что поставленные задачи не просто выполнены, а то, что достигнуты первоначальные цели. Инструментом для такой проверки выступает все та же модель продукта, которая играет роль эталона, с которым сравнивается полученный результат. Следствием такого подхода является то, что появляется возможность понимать статус

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

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

можно переходить к следующим шагам.

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

Шкура продюсера на кону проекта

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

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

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

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

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

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

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

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

Значит нужно как-то провести границу ответственности, чтобы продюсер, с одной стороны, не рассматривал проект как оплачиваемое развлечение, а с другой стороны — не был демотивирован размером возможного личного

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

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

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

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

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

До определённой степени для снижения риска можно

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

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

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

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

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

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

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


Цена привлечения продюсера

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

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

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

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

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

коммерчески адекватных продуктовых решений.

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

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

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

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

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

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

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

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


Сочетание интересов бизнеса и специалистов

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

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

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

Победителю тендера кажется, что его выбрали из-за того,

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

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

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

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

Если точно известно, какие задачи нужно выполнить и какие для этого нужны ресурсы, а это, как правило,

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

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

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

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

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

Интересно, что когда я только собирал материалы для этой главы, то искал примеры того, как подобный подход используется в других индустриях. Я хотел сказать, что продюсирование — неизбежная модель в современном мире, и был очень удивлён, когда наткнулся на рассказ о постройке самой крупной ракеты в истории человечества для полёта на Луну (источник: https://habr.com/ru/post/388699/):

«Ракета обладала беспрецедентной сложностью. Стоял вопрос, кто будет её строить. Фон Браун выбрал разделение труда. Это позволяло ему выбирать лучших из лучших во всей промышленности. Он мог задействовать самых опытных людей из каждой из компаний. Скорость разработки действительно получилась высокой. Для

подрядчиков решение означало крупные заказы, а не огромный заказ для кого-то одного. В итоге основная доля распределялась между тремя компаниями: «Боинг», North American Aviation и «Дуглас». Они производили три ступени, из которых состоит «Сатурн-5…

…За работой подрядчиков следили две группы в Космическом центре Маршалла. Отдел Research and Development Operations следил за целостностью структуры ракеты, а Industrial Operations перечислял денежные средства и принимал работу…»

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

образ жизни цифровых кочевников, описанный подход становится единственно возможным ответом на вызов времени.

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

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

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

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

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

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

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

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

К уже сказанному можно добавить ещё несколько условий, которые нужно соблюсти, чтобы преуспеть в роли

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