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

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

Проектировщик – генеральный конструктор продукта

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

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

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

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

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

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