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

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

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

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

Посмотрим, как происходит проверка по итогу работы над концепцией продукта. Это первая контрольная точка, через которую обязательно должен пройти проект. Ее цель – убедиться, что в проекте на всех уровнях найдены решения, и они соответствуют трем правилам: 1) уменьшают неопределенность; 2) приняты на нужном уровне абстракции, компетенции и ответственности; 3) связаны с первоначальными целями проекта.

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

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

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

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