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

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

<p>Модель продукта и проектирование</p>

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

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

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

Конкретный набор артефактов и требований к ним – часть технологии продуктовой разработки.

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

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

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

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

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