Рассмотрим эту проблему с точки зрения Нассима Талеба, на которого я часто ссылаюсь в этой книге. По его мнению, самые большие неожиданности таятся в длинных хвостах нормального распределения. В данном случае речь о распределении внимания к проектированию ключевыми участниками проекта. Как видно на схеме, наибольший интерес проявляют проектировщики и дизайнеры, а бизнес и разработчики заинтересованы значительно меньше.
Поскольку ни бизнес, ни разработчики не вовлечены напрямую в процесс проектирования, каждая из сторон ждет результатов работы дизайнеров и проектировщиков и рассматривает их деятельность как «черный ящик». Итог может нравиться или не нравиться, но не восприниматься как совместное решение.
Бизнес в итоге не чувствует своей ответственности за результат проектирования и недостаточно четко ставит задачи для проектировщиков, рассчитывая на возможность внести уточнения на этапе разработки. Так рождается неопределенность в левой части нормального распределения, скрытая под длинным хвостом графика. При таком подходе бизнес смотрит на проектировщиков, как на тех, кто мешает четко поставить задачу разработчикам. Приходится отвечать на миллион «бессмысленных» вопросов, восклицая: «Нам просто нужно мобильное приложение!», «Какое значение имеет портрет пользователя, наш сервис для всех!», «Мы же уже все объяснили, чего мы ждем, почему не идет разработка?!» – и мое любимое: «Какие приоритеты? Все задачи одинаково важные!».
Разработчики, в свою очередь, считают дизайнеров и проектировщиков умниками, усложняющими работу своими требованиями, и мнению которых нельзя доверять. Это неудивительно, ведь не так часто проектировщики «опускаются» до технического уровня, ограничиваясь пользовательским интерфейсом и общими архитектурными схемами. Как следствие, на документацию, дизайн и остальные артефакты проектирования разработчики склонны смотреть как на рекомендации, а не обязательные к исполнению инструкции. Поэтому меня совершенно не удивляет типичный вопрос дизайнеров, почему итоговое приложение или сайт внешне отличается от первоначальных макетов. Точно такие вопросы появляются и у системных архитекторов, ведь они видят разницу между документацией и программным кодом, реализующим логику компонентов системы. Это пример проявления неопределенности в правой части нормального распределения, показанного на графике.
Получается, что при традиционном подходе шансы получить цифровой продукт в том виде, как он был изначально задуман, ничтожны. Даже если допустить, что бизнес ясно сформулировал цели, что бывает редко, а потом предположить, что проектировщики правильно поняли задачу, нашли наиболее подходящее решение, на этапе разработки это будет проигнорировано или неверно интерпретировано. Поэтому так популярны гибкие методики разработки, в своем упрощенном виде исключающие проектирование из процесса. После потери надежды сделать все по уму работа сводится к бесконечной серии проб и ошибок, еще называемых итерациями или спринтами, где бизнес говорит разработчикам, что он хочет получить здесь и сейчас, а разработчики пытаются это реализовать минимальными средствами.
Чтобы преодолеть описанную ситуацию, нужно, чтобы и бизнес, и разработчики увидели явные преимущества от проектирования и таким образом были больше в него вовлечены. Можно сколько угодно говорить, что без тщательной проработки хорошего продукта не создать, но настоящие изменения происходят, когда люди получают реальную пользу. Цель первого принципа «Метода параноика» – сделать проектирование личным инструментом каждого участника проекта. Для этого нужно вспомнить, что проектирование – это процесс поиска и принятия решений. Его смысл в том, чтобы продумать решение до реализации. Ошибки, обнаруженные на этапе проектирования, обходятся значительно дешевле, чем выявленные на этапе реализации и, тем более, эксплуатации продукта. Говоря более образно, проектируя, мы позволяем «умереть» плохим идеям, а не готовому продукту.
Казалось бы, в чем вопрос, ведь именно этим и занимаются проектировщики. Но дело в том, что их работа основывается на первоначальных требованиях и условиях, которые предъявляются бизнесом. Такими требованиями могут быть, например, описание бизнес-модели компании, набор пользовательских функций, схемы существующих в компании процессов или описания ролей пользователей, сюда можно отнести и цели проекта. Если они ошибочны, то как бы качественно ни было проведено проектирование, конечный продукт не будет работать нужным образом и не позволит решить поставленные перед ним задачи. Когда идеи, положенные в основу, являются непроверенными гипотезами, устойчивость всей конструкции под большим вопросом. Эта скрытая неопределенность, которая проявляет себя, когда уже поздно что-либо менять или цена исправления недопустимо высока.
То же самое происходит, если проектировщики выполняют работу без проверки решения на возможность реализации либо делают это без учета всех факторов влияния. Даже опытные специалисты часто не принимают в расчет важные аспекты, такие как доступность квалифицированных программистов, стоимость поддержки системы, возможность дальнейшего развития, не говоря уже об элементарной проверке соответствия дизайна пользовательского интерфейса возможностям средств разработки. Как итог, разработчики сталкиваются с неподтвержденными требованиями и набором противоречивых или непроверенных решений. Это как проектировать автомобиль и передавать на производство неполную документацию, оставляя окончательную доводку конструкции сборщикам на конвейере. Если такой проект удается запустить, то это является просто чудом и, конечно же, заслугой разработчиков. Если же чуда не случается, то, чтобы выполнить стабилизацию и привести продукт в состояние хотя бы близкое к удовлетворительному, уходят долгие месяцы, и только после этого становится понятно, насколько он пригоден для использования.
Из приведенных примеров видно, что при традиционном подходе плохие идеи не умирают, а воплощаются в продукте. Бизнес не получает то, что требуется, теряет время и деньги, а заодно и репутацию. Разработчики вместо качественной технической реализации вынуждены разбираться, как должна работать система, и тратить силы на изматывающее тестирование и стабилизацию.
Проектирование в своей новой роли должно быть фильтром для идей и решений, отсеивающим те из них, которым не стоит жить и на реализацию которых не стоит тратить ни силы, ни деньги, ни время. Только так можно сделать проектирование работающим инструментом в руках каждого из участников, давая возможность влиять на успешность проекта и при этом разделять ответственность за результат. Далее я расскажу о трех базовых правилах, на которые опирается принцип проектирования.
Первое правило: каждое решение должно уменьшать неопределенность
Идея, что каждое решение должно уменьшать, а не увеличивать неопределенность, заключается в том, что изначальная точка отсчета проекта полна неопределенностей, подобно Вселенной в момент Большого взрыва. Чтобы прийти к работающему цифровому продукту, нужно, чтобы все гипотезы – от целей бизнеса до цвета кнопок в интерфейсе – превратились в подтвержденные решения. Только так можно сузить воронку неопределенности и сфокусироваться на конечном результате проекта. Именно это отличает описываемый метод от других подходов, опирающихся на проектирование. Параноидальное недоверие к абстрактным рассуждениям – залог того, что проект всегда будет оставаться на твердой почве.
Здесь уместно вспомнить эмпирический закон Галла, по которому сложная система не может быть создана сразу в своем конечном состоянии, а развивается от более простой, но работающей системы. Это связано с тем, что устройство и решения, лежащие в ее основе, должны пройти процесс естественного отбора. Из-за множества факторов и неопределенностей, связанных с их взаимным влиянием, невозможно предсказать все связи и параметры, а значит, искусственно построенная система будет неработоспособна.
При кажущейся простоте того, чтобы брать в расчет исключительно решения, основанные на подтвержденных гипотезах, эта идея не столь легка в осуществлении. Откуда у вас будет достаточно причин, чтобы проводить проверку гипотез, что увеличивает и сроки, и бюджет без явных на то оснований, только если вы не заинтересованы в достижении качественного результата? Посмотрим на примерах.
Начнем с классической проблемы, с которой сталкивается почти каждый проект. Современные цифровые продукты так или иначе зависят от внешних сервисов. Поэтому если цель проекта – создание мобильного приложения для продаж, потребуется доступ к внутренней базе данных с информацией о товарах и услугах, списку зарегистрированных пользователей, сделанным заказам, а также к платежной системе и сервису отслеживания курьеров. При наличии сайта, который выполняет аналогичные функции, бизнес в начале проекта скажет разработчикам, что все необходимое уже есть и от них требуется только воспользоваться существующими наработками: «Вот, у нас даже есть документация к API! Когда сможете подготовить оценку проекта?»
Против такого сложно устоять, и это главная трудность. Специалистам нужно не только найти аргументы в пользу более тщательной подготовительной работы, но и избежать искушения быстрее переключиться на работу «руками». Опыт показывает, что, даже если документация выглядит безупречно, стоит протестировать реальное API на практике и сделать это еще на этапе проектирования. Документация часто оказывается не актуальна, а особенности реализации могут предполагать пользовательские сценарии, отличные от того, что нужно для мобильного приложения.
Пока не написано ни строчки кода, ошибочную гипотезу об устройстве продукта можно отбросить и заменить другой, подтвержденной. Цена ошибки будет невысокой. Но если бюджет уже согласован, задачи спланированы и началась разработка, а на стороне бизнеса доработка API оказалась невозможна из-за отпусков команды, что вы будете делать? Особенно если это выяснится ближе к концу проекта. Разработчики могут найти обходное решение, но именно так и появляются странно или нестабильно работающие системы, с которыми всем приходилось сталкиваться и которые каждый день добавляют минус в карму бренда в глазах клиентов. Но нужно понимать, что это та высокая цена, которую приходится платить в конце, избежав минимальных затрат на старте проекта.