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

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

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

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

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

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

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

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

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

Организация проектной работы

Творчество против определенности

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