Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

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

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

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

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

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

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

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

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

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