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

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

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

Почему же проектирование в этой отрасли часто считается избыточным и ограничивается дизайном? Ведь если не уделять достаточного внимания проектированию, уровень неопределенности в проекте можно довести до максимума.

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

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

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

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

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

Негативная эволюция

Разобраться с тем, что произошло в IT-индустрии, мне помог Чак Паланик, автор книги «Бойцовский клуб». В подкасте Джо Роган спросил его о процессе написания книги и о том, когда он садится за компьютер, чтобы работать над текстом. Паланик ответил, что старается откладывать этот момент до тех пор, пока не останется другого выбора, например в самолете, и назвал это машинописью (typewriting). По его мнению, к созданию книги этот процесс относится в последнюю очередь. Основная работа состоит в поиске, сборе и анализе материалов, причем в случае с Палаником это происходит где угодно и с использованием любых подручных средств, включая клочки бумаги и салфетки.