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

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

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

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

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

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

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

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