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

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

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

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

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

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

Модель продукта

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

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

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

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

Детальное проектирование

Цель стадии и характер работ