Другой пример, уже с обратной стороны проектных баррикад. На него мне указал один из читателей первых глав книги, пока она еще была в работе. Суть в том, что владельцам и управляющим бизнеса необязательно знать все детали его устройства. Как и любая сложная система, организация состоит из множества компонентов, взаимодействующих между собой, и при этом находится в динамическом балансе. Интересы одних сотрудников уравновешиваются интересами других, решения руководителей интерпретируются подчиненными по-своему, и никто не может точно сказать, по каким правилам действительно работает компания. Именно на этом основана «итальянская забастовка», когда строгое исполнение должностных обязанностей сотрудниками способно полностью остановить работу. Ведь должностные обязанности отражают видение руководителей, но не всегда соответствуют реальной схеме работы.
Подобное неведение не создает особых проблем до тех пор, пока не требуется создать цифровой продукт или сервис, связанный с основной деятельностью компании, например, продажами или внутренними процессами производства и оказания услуг. Существует выражение, что если автоматизировать хаос, то получится автоматизированный хаос. Но как было сказано выше, это не совсем хаос, а неосознаваемая сложность. Тем не менее, если компания может находиться в таком состоянии, то проектная команда – нет. Для создания работающих цифровых продуктов, встроенных в бизнес-модель, требуется ясность. Современные цифровые системы – это вовсе не автоматизация существующих процессов, которая делает все чуть «эффективнее», а основные инструменты, на которых строится весь бизнес. И здесь мы снова сталкиваемся с тем, насколько сложно на практике осуществить идею о снижении неопределенности в проекте.
Руководитель компании редко осознает, что его представления расходятся с реальностью. То же касается сотрудников, хотя им кажется, что они то уж точно знают, как обстоят дела. Можно реализовать продукт, основываясь на формальных представлениях о бизнесе, но выполнять он будет функции, также отвечающие формальным, а не действительным целям, т. е. будет совершенно бесполезным.
Поэтому при проектировании будущего продукта главная задача не в том, чтобы на основе предоставленных требований найти подходящее решение, а в том, чтобы разобраться, каковы действительные требования. Но даже если проектной команде удается их сформулировать, это все равно гипотеза, требующая подтверждения. Отсюда два непростых вопроса: как получить подтверждение и кто должен взять ответственность за результат. Ответы на них неочевидны, поскольку это так или иначе затрагивает границы личной компетентности, которые каждый из нас скрывает.
Второе правило: каждое решение требует своего уровня абстракции, компетенции и ответственности
Теперь перейдем ко второму правилу принципа проектирования: каждое решение в проекте требует своего уровня абстракции, компетенции и ответственности. Из прошлых примеров понятно, что любая сложная система – не просто сумма ее частей. Взаимодействие между компонентами системы играет ключевую роль. Когда они соединены определенным образом, система превращаются в нечто, обладающее свойствами, отличными от свойств всех частей по отдельности. Как нетрудно догадаться, это означает, что для создания подобной системы требуется рассматривать ее устройство на более высоком уровне абстракции.
Чтобы вы могли прочувствовать эту идею, посмотрите на дорожное движение из окон высотного здания. Потоки машин, словно ручейки, сливаются и расходятся, где-то течение замедляется, а на других участках, наоборот, ускоряется. Только глядя на действующую систему при таком масштабе можно понять замысел ее создателя, точно так же как заметить ошибки и причины компромиссных решений. Когда вы находитесь за рулем, кажется, что причина пробки в невнимательности отдельных водителей, но истинная причина может быть в самой организации движения, что можно увидеть, только если посмотреть на картину в целом.
Все вышесказанное в полной мере относится и к созданию цифровых продуктов. Каждый участник проекта видит его и принимает решения исходя из картины, которая открывается его мысленному взору из той точки и той роли, в которой он находится. А значит, среди них должны быть специалисты, которые могут охватить систему одним взглядом. Это касается всех аспектов проекта, особенно если рассматривать цифровой продукт как часть бизнес-модели компании. Приведу пример.
В банке, упомянутом в третьей главе, для взаимодействия с клиентами используется веб-сайт. Руководство решает добавить голосового ассистента и мобильное приложение. В том же примере говорится, что для решения подобной задачи обычно привлекаются специалисты, которые уже работают над текущей системой. Здесь и проявляется идея о требуемых уровнях компетенции и абстракции для принятия проектных решений.
Кажется разумным нанять специалистов с компетенцией в мобильных и голосовых технологиях для проектирования и реализации новой версии банковского сервиса. Если существующая команда не имеет нужных знаний, маловероятно, что ее участники быстро их освоят и смогут принять решения, на которые можно будет опереться и снизить неопределенность в проекте. Это касается всех аспектов будущей системы: функциональных, интерфейсных и технических. Но, похоже, мы все равно что-то упускаем, а именно – уровень абстракции.
Когда к веб-сайту добавляется мобильное приложение и голосовой ассистент, то система становится сложнее. Сложность возрастает не только из-за количества новых компонентов, но и из-за их взаимодействия. При этом речь идет не только о связях частей системы. Появляются сценарии, в которых пользователи одновременно взаимодействуют с разными типами интерфейсов, решая одну задачу.
Например, спрашивают голосом у колонки, где ближайшее отделение банка, и после получения ответа заполняют заявку на кредит через веб-сайт, одновременно бронируя время визита, а дальше, уже в отделении, подписывают свою заявку с помощью мобильного приложения. При этом нужно учитывать варианты, когда у клиента банка есть только один канал коммуникаций, например, мобильное приложение. Нетрудно догадаться, что таких сценариев может быть очень много. Если же мы расширим функциональные требования и добавим маркетинговые аспекты, то количество взаимосвязей увеличится еще больше.
Проектирование подобных цифровых сервисов требует более высокого уровня абстракции и взгляда на систему в целом. Для ее создания недостаточно специалистов по каждой отдельной технологии. Требуется понимание, как должна быть устроена мультиплатформенная и многоканальная система. Сначала проектируется цифровой сервис как единый механизм в виде набора компонентов, взаимодействующих между собой и связанных общими сценариями. Затем формулируются требования к отдельным частям системы, проектирование которых также потребует соответствующего уровня абстракции и компетенций.
Еще одной причиной, почему для принятия любого проектного решения требуется максимально высокий уровень абстракции, конечно, без потери детализации, является вопрос оптимизации. Как говорил Элияху Голдратт в своей теории ограничений, оптимизировать нужно систему в целом, а не ее отдельные части. Но разработчики, дизайнеры, тестировщики, менеджеры работают в рамках своих областей и склонны добиваться личной эффективности либо эффективности создаваемых ими частей проекта и упускают из вида общие цели.
Приведенный пример мог подвести к мысли, что при наличии нужных компетенций суть идеи сводится к определению уровня абстракции, с которого следует рассматривать систему при проектировании. Но почему же тогда я использовал слово «ответственность»? Способность принять решение, соответствующее целям, и учитывать все факторы, зависит от полноты знаний, опыта и понимания смежных дисциплин. Но фокус в том, что этого недостаточно. Уровень, необходимый для принятия каждого решения в проекте, имеет две координаты, а именно: уровень абстракции и ответственности.
Еще до выхода книги Нассима Талеба «Рискуя собственной шкурой», которая полностью посвящена обсуждаемой теме, я заметил интересную закономерность на нескольких проектах. Там, где над продуктом работали люди, которые должны были в дальнейшем использовать его как свой собственный инструмент, все завершалось успешно. Где же был только инвестор, который хотел сделать коммерческий цифровой сервис, и нанятая проектная команда для проектирования и разработки, в 100 % случаев все заканчивалось провалом, даже если технически все соответствовало исходным требованиям. Изначально я думал, что причина в отсутствии нужной компетенции у инвесторов для верной постановки задачи, но в дальнейшем стало понятно, что, даже обладая необходимыми знаниями, но не будучи связанными «угрозой» использовать конечный продукт, они не могли верно расставить акценты.
Давайте посмотрим, что это значит на практике. Например, как следовало бы поступить инвесторам из предыдущего абзаца. Напомню, что мы обсуждаем принцип проектирования, и, казалось бы, причем здесь инвесторы проекта? Описанная ситуация нужна, чтобы показать, насколько шире стоит смотреть на этот принцип в контексте работы над цифровыми продуктами.
Итак, если следовать логике, то в проекте должен быть тот, кто будет непосредственно использовать разрабатываемый продукт. Не фокус-группа и не абстрактный персонаж, а конкретный человек, который будет запускать и вести бизнес, основанный на этом цифровом инструменте. Например, для онлайн-магазина это коммерческий директор, для мобильного приложения банка – руководитель клиентского направления. Он должен принимать решения, которые определят жизнеспособность будущего продукта. Проектировщики, дизайнеры и разработчики даже при наличии нужных знаний не смогут сделать это за него, потому что у них другие цели. Ответственностью инвесторов, как и проявлением их компетенции, является выбор человека, который встанет у руля бизнеса и задаст правила для проектной команды.