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

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

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

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

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

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

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

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

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

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