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

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

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

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

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

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

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

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

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