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

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

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

Во-вторых, когда неопределенность устранить нельзя, то

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

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

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

В момент начала проекта уровень неопределенности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

использования цифровых инструментов.

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

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

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

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

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

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

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

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

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

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

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

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

Мои каракули, Даша еще работает над иллюстрацией

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цифровой продукт обретает конкретные черты
Неопределенность в тисках ограничений. Баланс вместо компромисса. Съесть проектный бутерброд.
Неопределенность в тисках ограничений

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


Съесть проектный бутерброд

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

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

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

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

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

Укрощение неопределенности
Творчество против определенности. Жизненный цикл динамической команды в продюсерском подходе. Шкура продюсера на кону проекта. Цена привлечения продюсера. Сочетание интересов бизнеса и специалистов.
Творчество против определенности

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

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

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

построен так, чтобы сохранялось пространство для творчества.

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

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

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

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

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

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

В «Методе параноика» таким снаряжением служат

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


Жизненный цикл динамической команды в продюсерском подходе

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

заплатить.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метод параноика

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

#методпараноика: продюсерский подход для создания цифровых продуктов в бизнесе и инструмент контроля неопределенности в проектной работе
Связаться с автором
Чтобы связаться с автором метода Вадимом Митякиным, напишите одним из способов: