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