Аналогично выглядит ситуация с цифровыми продуктами. Есть сложившиеся архитектурные схемы в качестве шаблонов, например, для реализации мобильных приложений или веб-сайтов. На них опираются разработчики, предлагающие типовые решения, а также поставщики цифровых платформ и средств разработки. Но каждый конкретный проект имеет свою специфику. Это происходит за счет сочетания множества факторов: бизнес-модели, функциональных требований, особенностей технической инфраструктуры и организационных ограничений. Для простых проектов достаточно подхода с «конструированием». Это обычная практика для проектов типа «Процедуры» и «Седина». Но для уникальных проектов нужно найти принципиальную схему решения, чтобы сформулировать требования и к архитектуре продукта, и к отдельным его компонентам.
Как видно из этого примера, проектирование является приоритетной проектной задачей в сравнении с последующим воплощением рассчитанной модели «в металле». Если вы не понимаете, как должен быть реализован продукт, то ни привлечение разработчиков самой высшей квалификации, ни проведение фокус-групп, ни организация A/B-тестирования не помогут. Включение в проект бизнес-аналитика также не спасет ситуацию, потому что аналитика – это сбор требований, а проектирование – это поиск решений для их выполнения. Какая польза от знаний о том, чего хочет бизнес, если вы не знаете, как решить его задачу?
Из этого следует, что проектирование нельзя рассматривать как просто подготовительную работу или задачу для коммерческого предложения. Также это не может быть всего лишь предпроектным обследованием. Проектирование – сама суть проекта, и ему необходимо уделять особое внимание. Если происходит попытка зажать проект в рамках первоначальных оценок, сделанных еще до его начала, это приводит к тому, что функциональные и технические решения, принятые на начальной стадии в виде набросков идей по неполным требованиям, в дальнейшем не могут быть изменены и ложатся в основу всего продукта. Что вполне понятным образом сказывается на его качестве.
Но это вовсе не значит, что весь проект должен делиться на две большие стадии: сначала проектирование, потом реализация. Это бы вернуло нас к классической «водопадной» модели, вряд ли возможной в мире, в котором мы живем. Вместо этого «Метод параноика» разделяет каждую задачу. Поскольку решения нужно принимать на протяжении всего проекта, речь о том, чтобы сделать «выжимку» «продумывания» из всех задач, начиная с бизнеса и заканчивая техническими вопросами, и передать ее в руки тех, кто обладает необходимыми компетенциями.
Итак, когда я говорю о принципе проектирования, то имею в виду выделение процесса поиска и формулирования решений в отдельную активность. Этот принцип настолько важен, что без него все остальные принципы метода попросту теряют смысл и не могут быть применены. Хотя конечно основывать на проектировании оригинальный подход к созданию цифровых продуктов – это смело, как и настаивать на здоровом образе жизни. Но как большинство адептов ЗОЖа продолжают есть сахар, так и те, кто утверждает, что выполняет проектирование, по факту этого не делают.
Есть несколько причин, почему так происходит. Во-первых, проектирование требует вдумчивого и осознанного подхода и не дает быстрого положительного подтверждения. Чтобы получить результат, нужно потратить время и силы. Идти таким путем не в человеческой природе. Людям проще сразу окунуться в активную и, как нам кажется, результативную работу. Например, вместо анализа целей проекта и проработки способов его реализации проще сразу запустить разработку, надеясь на магию эджайла. Гибкость важна, но, как я покажу в девятой главе о принципе сериала, чтобы получить от нее эффект, требуется серьезная подготовительная работа.
Во-вторых, понимание, что такое проектирование, не сильно распространено даже в профессиональной среде, не говоря уже о представителях бизнеса. Это выражается в доминировании двух противоположных подходов. Один – глубокий инженерный, доставшийся нам по наследству от разработчиков комплексных корпоративных систем. Его сила одновременно является и слабостью: сложные для понимания абстракции, уходящие за горизонт спецификации, непереводимые на обычный язык термины, академический снобизм ИТ-архитекторов и слабая привязка к практическим задачам бизнеса и пользователей. Этот подход похож на современное искусство, где понять ценность результата, как и расшифровать содержание, можно только обратившись к дорогому консультанту.
Противоположный подход – упрощение проектирования до дизайна пользовательского интерфейса (тем, что принято называть UX). Это стало масс-маркетом в создании цифровых сервисов, и для большинства непосвященных людей это и есть проектирование. Все кажется понятным, и создается иллюзия, что так могут быть решены все вопросы об устройстве будущего продукта. В результате к этим задачам привлекаются люди без глубоких технических знаний и системного подхода, упускаются важные технические особенности реализации, и все это отражается на качестве работы. Сложные вопросы отдаются команде разработки в расчете, что участникам хватит компетенций и сообразительности в том, как набор схем интерфейса и макетов дизайна превратить в работающую систему.
В-третьих, у проектирования есть два лагеря противников, и представители каждого из них имеют определяющее влияние на способ ведения проектов. Речь о программистах и менеджерах компаний, заказывающих цифровые продукты. Программисты, будучи практичными и увлеченными технологиями, концентрируются на технической реализации и все остальное считают вторичным. Их любимая фраза: «Болтать может каждый, покажите мне код!» Это касается и анализа требований, и дизайна, и технического проектирования. О том, чтобы рассматривать будущий продукт как нечто неразрывно связанное с бизнесом, речи не идет совсем. Удивительно, но бизнес-требования часто кажутся им мешающими и идут вразрез с идеальной картиной будущего продукта.
Менеджеры компаний, с другой стороны, ориентируются на «осязаемые» результаты работы проектной команды, глядя на которые можно составить личное впечатление о степени готовности и качестве. Например, дизайн пользовательского интерфейса или установленное на смартфон приложение, но точно не техническая спецификация алгоритмов работы внутренних компонентов системы. Ирония в том, что подробное описание того, как должен быть устроен цифровой продукт, является наиболее значимым результатом с точки зрения достижения целей проекта. Дело в том, что любая модель, описывающая сложную систему, проще самой системы. Если у вас нет возможности подумать хотя бы над моделью, почему вы считаете, что сможете подумать над самой системой?
В этой ситуации смысл проектирования заключается в создании целостной модели продукта в противовес сумме разрозненных решений разных специалистов, не связанных между собой. Цель «Метода параноика» – вернуть проектированию его первоначальное значение и на его основе построить более эффективную модель работы над цифровыми продуктами.
Я, как и большинство моих коллег, работая каждый день над проектами, был вынужден делать выбор между своими представлениями о качестве, с одной стороны, и требованиями бизнеса получить результат как можно быстрее и дешевле, с другой. В определенный момент я понял, что это ложный выбор. Такое противопоставление предполагает, что компании неспособны оценить качественный результат работы с точки зрения экономики. В конечном счете создание цифрового продукта при должном проектировании обходится дешевле, чем попытки создать продукт «грубой силой», сразу приступив к разработке и решая вопросы «по месту». Хотя в начале проекта кажется наоборот, так как не учитывается, сколь извилистой дорожкой придется идти команде и сколько денег и времени потеряет компания, чтобы получить приемлемое решение.
Правильный подход к проектированию позволяет добиться результата, когда усилия, затраченные на создание цифрового продукта или сервиса, многократно оправдывают себя. Возможно, кому-то подобное отношение к достижению целей покажется чрезмерно затратным с точки зрения сил и внимания, но в современном мире лидерами становятся компании, которые ставят на первое место связку бизнес-модели с цифровыми инструментами. Чтобы такая стратегия была успешной, недостаточно рассматривать IT в качестве вспомогательной инфраструктуры, значение которой ограничивается лишь тем, что существующие процессы начинают идти быстрее.
Цифровые системы – основа сегодняшнего бизнеса, его скелет. Это не громкие слова, а описание реальности, в которой мы живем. Эти системы так же важны, как например новые строительные технологии в середине XX века, которые радикально изменили возможности при возведении зданий и дали архитекторам недоступную ранее свободу творчества. Цифровые технологии позволили создавать компании с бизнес-моделями, о которых раньше нельзя было и подумать. Банки без отделений, сервисы типа Uber, рабочие коллективы, распределенные по разным странам – все это было невозможно без них. Вот почему, чтобы воспользоваться новыми возможностями, нужно кардинально изменить свои взгляды и подходы, в том числе и к тому, что все привыкли считать проектированием.
Новая роль проектирования
«Метод параноика» был задуман как подход к созданию цифровых продуктов, позволяющий контролировать уровень неопределенности, свойственной проектной работе. Проектирование служит ключевым инструментом для решения этой задачи. Именно такой взгляд позволяет дать ему новое определение.
В отличие от традиционного подхода, когда проектирование выделяется в отдельный этап и рассматривается как самостоятельная активность, при работе по «Методу параноика» принцип проектирования распространяется на все аспекты проекта – от организационных задач до технических вопросов. Я специально делаю на этом акцент. Обычно даже в тех проектах, где привлекаются проектировщики, их работа считается вспомогательной – помогает улучшить продукт, но принципиально ничего не меняет.