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

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

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

Цифровой продукт обретает конкретные черты

Неопределенность в тисках ограничений

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

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

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

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

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

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