Воронка неопределенности, как базовый фреймворк, задает общую систему координат проекта и вектор, по которому должна быть направлена вся работа над продуктом. При движении слева направо по оси времени цель проектной команды – сужать пространство возможных способов решения исходной задачи, чтобы получить единственный реализованный вариант.
Работа над проектом делится на стадии. В конце каждой из них происходит проверка на целостность всех решений, но внутри стадии участники имеют пространство для творческого поиска. Характер задач на каждой стадии меняется и по мере сужения воронки неопределенности должен становиться более предсказуемым. Технология продуктовой разработки устанавливает набор стадий и конкретные критерии их успешного завершения. В зависимости от области применения и особенностей проекта у них могут быть свои особенности. В девятой главе, описывающей принцип сериала, приведен пример типичного набора стадий.
Решения относительно устройства продукта также структурируются. Это вертикальная ось фреймворка, на которой выделяются разные уровни. Помимо уровней, связанных с продуктом, есть уровни проекта, например организационный и бизнес-уровень. Напомню, что благодаря им получается взять уровни продукта в «тиски», зажав между тем, что НУЖНО и что ВОЗМОЖНО. Концепция «тисков» дополняет фреймворк воронки неопределенности, объясняя, за счет чего должно сужаться пространство возможностей.
Уровни, на которые нарезается воронка неопределенности – это уровни абстракции. Они позволяют смотреть на продукт во всем его многообразии, при этом не быть раздавленным его сложностью. Для цифровых продуктов есть три типовых уровня: функциональный (что система делает), интерфейсный (как система взаимодействует с пользователями) и технический (как система устроена). Набор уровней – такой же настраиваемый параметр при внедрении технологии продуктовой разработки, как и стадии проекта.
На пересечении стадий и уровней локализуются решения относительно устройства продукта, выраженные в виде проектных артефактов – схем, спецификаций, макетов и дизайна интерфейса, описаний пользовательских сценариев, чек-листов для тестирования, бюджета, плана проекта, требований к команде и программного кода. Некоторые артефакты нужны только на отдельных стадиях, другие развиваются и дополняются на протяжении всего проекта. Таким образом получается общая система координат проекта, понятная каждому участнику, и отвечающая, кто, когда и над чем должен работать.
Модель продукта и проектирование
В отличие от производственного конвейера, по которому движутся отдельные части будущего автомобиля, воронка неопределенности работает с идеями. Они поступают на вход, превращаются в гипотезы и, доведенные до проверенных решений, постепенно собираются в комплексное описание компонентов архитектуры или всей системы. Структурой, в виде которой описывается продукт, является его модель.
Модель продукта нужна везде, где применяется проектирование. Проектирование же – это то, без чего невозможно создать что-то сложное. Когда мы говорим о движении идей, гипотез и решений по воронке неопределенности, то на самом деле мы говорим о процессе проектирования. Поэтому логично, что модель продукта выступает в роли контейнера для проектных артефактов. По сути, модель продукта – это набор таких артефактов.
Структура модели задается уровнями проекта и подобна изображению, состоящему из пазлов. Если элемент отсутствует или он неполон, то общая картина не складывается. Например, можно детально описать поведение системы на функциональном уровне и визуально представить ее интерфейс, но если на техническом уровне не будет архитектуры и устройства программных компонентов, то работа команды разработчиков будет непредсказуемой.
Конкретный набор артефактов и требований к ним – часть технологии продуктовой разработки. В зависимости от типа разрабатываемых систем один и тот же уровень проекта, например, интерфейсный, может быть представлен по-разному. В мобильных приложениях это навигационные карты переходов, детальные макеты экранов и примеры анимации отдельных элементов форм. Для системы с голосовым вводом потребуются сценарии диалогов, справочник синонимов, набор интентов и прочее.
По мере продвижения проекта от стадии к стадии структура модели продукта меняется. Например, на концептуальной стадии не требуется детально прорабатывать функции и техническое устройство. Достаточно общего представления о возможностях продукта и ключевых элементах архитектуры. Тщательная работа над этими аспектами будет происходить на более поздних стадиях. Технология продуктовой разработки должна это учитывать и структурировать модель продукта не только по уровням, но и по стадиям.
Теперь, если представить точки пересечения стадий и уровней проекта, то это будут пазлы или ячейки модели. Работа над ними не идет последовательно, например, снизу вверх, когда сперва выясняются детали на уровне бизнес-требований, потом на функциональном. Наоборот, поскольку решения рождаются на стыке разных дисциплин, то процесс проектирования часто затрагивает сразу несколько уровней, как игла швейной машинки проходит несколько слоев, чтобы их сшить.
При внедрении технологии продуктовой разработки необходимо выявлять жизненный цикл артефактов и порядок перехода между ними в процессе проектирования. Иногда даже небольшая настройка способна сэкономить существенную часть бюджета. Например, при проектировании систем со сложным пользовательским интерфейсом лучше не прорабатывать все детали сразу, а отдать первоначальные эскизы экранов на экспертизу разработчикам. Их уточнения, что технически возможно реализовать, а что нет, избавят от большого количество переделок на стадии реализации.
В отличие от методологии, задающей принципы работы, технология определяет конкретный набор артефактов, процесс работы над ними и инструменты для проектирования и разработки. Это еще один аспект технологии, который нужно учитывать при внедрении. Кроме вопросов удобства и эффективности инструментов, нужно учитывать их стоимость и популярность. Последнее важно, когда речь заходит о доступности специалистов с нужными компетенциями.
К инструментам относятся не только специализированные программы, например, Figma, но и различные методики. JTBD, например, отлично работает на функциональном и бизнес-уровне, помогает выявлять требования к продукту во время подготовки концепции. Scrum используется на более поздних стадиях, когда выполнено детальное проектирование и происходит переход к разработке, давая команде возможность двигаться спринтами уже внутри отдельной стадии.
Технология продуктовой разработки по «Методу параноика» не заменяет подобные методики и фреймворки, а создает общее пространство для разных инструментов, эффективных в зависимости от стадии или уровня проекта.
Проектная команда и управление
Работа над проектными артефактами, поиском идей и превращением гипотез в решения, не происходит сама по себе. Этим занимаются члены проектной команды. Чтобы сформировать такую команду, проджект-раннеру и другим ключевым участникам нужно понимать ее устройство и требования к специалистам, из которых она состоит.
В типовых проектных подходах при формировании команды принято идти от ролей, предполагая, что этого достаточно для получения результата. Технология продуктовой разработки разворачивает эту связь на 180 градусов и в качестве отправной точки использует модель продукта. Действительно, если для создания продукта нужна модель, состоящая из разных артефактов, то за каждый из них должен кто-то отвечать.
Невозможно определиться с требованиями к составу команды, пока не ясна структура модели продукта. Как только это определено, можно выявлять роли участников. Общее правило состоит в том, что в проекте не может быть ни одного артефакта, за который никто не отвечает. В противном случае, как вы помните, не получится создать полную картину продукта.
Изначально можно опираться на типовой набор артефактов и ролей, но только для того, чтобы потом уточнить их исходя из потребностей конкретного проекта, либо его типового формата в рамках проектного офиса. «Черная» книга описывает технологии продуктовой разработки по «Методу параноика» и дает такие «пресеты», но и в этом случае нужна индивидуальная настройка. В конце концов, над проектом работают люди, и их личные качества не всегда совпадают с типовыми ролями.
Если говорить более строго, в рамках технологии роль участника определяет его область деятельности с привязкой к уровням проекта, полномочия в принятии решений, которые выражаются в том числе в артефактах, условиях мотивации и ответственности за результаты работы. Не стоит думать, что одна роль всегда связана с одним уровнем, например, функциональным или техническим. Большинство ключевых участников работают на стыке дисциплин. Например, роль, которую обычно принято называть менеджером продукта, отвечает за объединение решений сразу на трех уровнях – функциональном, интерфейсном и техническом.
Кроме областей деятельности и ответственности за артефакты, технология задает правила организации работы. В гибких командах управление не директивное, когда одни роли подчиняются другим, а происходит через влияние результатов одного участника на работу других. Здесь есть иерархия уровней модели продукта, а не людей. Область деятельности участника дает ему полномочия в принятии решений. Это важно при работе над уникальными продуктами, где нет и не может быть полномочий без компетенций и ответственности.
Отдельно хочу остановиться на роли проджект-раннера, ведь он носитель технологии и с него начинается ее развертывание в рамках конкретного проекта. Его уникальность в том, что он связан со всеми уровнями проекта скорее как идеолог и координатор, нежели специалист, непосредственно выполняющий технические задачи. Его основной инструмент – это «тиски», зажимающие пространство решений об устройстве продукта между бизнесом и организационным уровнем. Его цель – коммерциализация продукта: внутри компании, при создании тиражируемого продукта или при разработке на заказ.