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

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

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

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

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

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

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