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

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

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

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

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

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

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

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