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

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

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

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

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

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

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

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

Второе правило: каждое решение требует своего уровня абстракции, компетенции и ответственности