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

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

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

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

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

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

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

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

Итак, ещё раз. Когда я говорю о принципе проектировании, то имею в виду выделение поиска и формулирования решения в отдельную активность. Этот принцип настолько важен, что без него все остальные принципы метода попросту теряют смысл и не могут быть применены. Хотя, конечно, я отдаю себе отчёт в том, что основывать на проектировании оригинальный подход к созданию цифровых продуктов — это достаточно смело. Настолько же смело, как и настаивать на здоровом образе жизни, в то время как все только об этом и говорят. Что же здесь может быть оригинального?

Точно так же, как большинство адептов ЗОЖа продолжают есть сахар, так же и большинство тех, кто утверждает, что выполняет проектирование, по факту этого не делают. Есть

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

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

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

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

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

В-третьих, у проектирования как такового есть два лагеря противников, и представители каждого из них имеют определяющее влияние на способ ведения проектов. Речь идёт о программистах и менеджерах компаний, заказывающих цифровые продукты. Программисты, будучи людьми практичными и одновременно увлечёнными технологиями, в своей работе сконцентрированы на написании кода и считают всё остальное несущественным и вторичным. Их любимая фраза: «Болтать может каждый, покажите мне код!» Это касается и анализа требований, и дизайна, и технического проектирования. О том, чтобы рассматривать будущий продукт как нечто неразрывно связанное с бизнесом, речи не идёт совсем. Удивительно, но бизнес-требования часто кажутся им мешающими и идущими вразрез с идеальной

картиной будущего продукта.

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

Одна из целей создания «Метода параноика» — вернуть проектированию его первоначальный смысл

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

Возможно, для кого-то подобное отношение

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

Цифровые системы — сама суть сегодняшнего бизнеса, основа, скелет, вокруг которого выстраивается бизнес-модель. Это не громкие слова, а описание реальности, в которой мы живём. Точно так же, как новые строительные технологии в середине XX века радикально изменили возможности при возведении зданий и дали архитекторам недоступную ранее свободу творчества, точно так же и цифровые технологии позволили предпринимателям создавать компании, действующие по уникальным моделям. Зачастую их нельзя назвать даже компаниями в привычном значении этого слова. Возможны ли банки без

отделений в отсутствии цифровых систем? Нет. Возможны ли сервисы на манер Uber или Яндекс.Такси без мобильных приложений? Нет. Возможно ли построение рабочих коллективов, работающих вместе над одним проектом, но распределённых географически по разным странам без коммуникационных технологий? Нет. Именно поэтому, чтобы суметь воспользоваться новыми возможностями, нужно радикально поменять свои взгляды и подходы, в том числе и к тому, что все привыкли считать проектированием.

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

Получается, что при традиционном подходе шансы получить цифровой продукт в том виде, как он был

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

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

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

Казалось бы, в чём вопрос, ведь именно этим и занимаются проектировщики. Но дело в том, что свою работу они строят на основе тех первоначальных требований и условий, которые предъявляются им со стороны бизнеса. Такими требованиями могут быть, например, описание бизнес-модели компании, набор пользовательских функций, схемы существующих

в компании процессов или описания ролей пользователей, сюда же можно отнести цели проекта. И если они ошибочны, то как бы качественно ни было проведено проектирование, конечный продукт не будет работать нужным образом и решать поставленные перед ним задачи. Когда идеи, положенные в основу, являются всего лишь непроверенными гипотезами, устойчивость всей конструкции находится под большим вопросом. Это та самая скрытая неопределённость, о которой было так много сказано в третьей главе, и которая проявляет себя в те моменты, когда уже поздно что-либо менять, либо цена исправления недопустимо высока.

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

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

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

попытки разобраться, как именно должна вести себя система, а заодно и на изматывающие в своей бесплодности периоды тестирования и стабилизации.

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

Для начала давайте их перечислим. Первое: каждое решение в проекте должно уменьшать, а не увеличивать неопределённость. Второе: каждое решение в проекте требует своего уровня абстракции, компетенции и ответственности. Третье: все решения в проекте должны быть связаны между собой. Остановимся на каждом из правил подробнее.

потребуется доступ к внутренней базе данных с информацией о товарах и услугах, к списку зарегистрированных пользователей и сделанных ими ранее заказов, а также к платёжной системе и сервису отслеживания текущего положения курьеров. В случае наличия сайта, уже выполняющего аналогичные функции, бизнес в начале проекта скажет разработчикам, что всё необходимое уже есть и от них требуется только воспользоваться существующими наработками: «Вот, у нас даже есть документация к API! Когда сможете подготовить оценку проекта?»

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

или инфраструктуры могут предполагать пользовательские сценарии, отличные от того, что нужно для мобильного приложения.

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

Другой пример, уже с обратной стороны проектных

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

Подобное неведение не создаёт особых проблем до тех пор, пока не появляется задачи создать цифровой продукт или сервис, напрямую связанный с основной

деятельностью компании, например, с продажами или внутренними процессами производства и оказания услуг. Существует выражение, что если автоматизировать хаос, то получится автоматизированный хаос. Но как было сказано выше, это не совсем хаос, а неосознаваемая сложность. Тем не менее, если компания может находиться в таком состоянии, то проектная команда — нет. Для создания работающих цифровых продуктов, вплетённых в бизнес-модель, требуется ясность относительно этой модели. Кроме этого, современные цифровые системы — это вовсе не автоматизация существующих процессов, делающая всё чуть «эффективнее», а основные инструменты, в некотором роде скелет, на котором строится весь бизнес. И здесь мы снова сталкиваемся с тем, насколько сложно на практике осуществить идею о снижении неопределённости в проекте.

Руководитель компании вряд ли отдаёт себе отчёт в том, что его представления расходятся с реальностью. То же самое касается сотрудников, хотя им кажется, что «уж они-то точно знают», находясь непосредственно внутри рабочих процессов. Можно реализовать продукт,

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

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

Кажется разумным, что для проектирования и реализации новой версии банковского сервиса в команду должны быть наняты специалисты с компетенцией в мобильных и голосовых технологиях. Действительно, если существующая команда не имеет нужных знаний, то вряд ли её участники смогут быстро их освоить и к тому же принять решения, на которые можно будет опереться, тем самым снизив неопределённость в проекте. Об этом много говорилось в третьей главе. Это касается всех аспектов будущей системы: функциональных, интерфейсных и технических. Но, похоже, мы всё равно что-то упускаем, а именно — уровень абстракции.

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

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

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

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

Ещё одной причиной, почему для принятия любого проектного решения требуется максимально высокий уровень абстракции, конечно, без потери детализации, является вопрос оптимизации. Как говорил Элияху Голдратт в его блестящей теории ограничений, оптимизируйте систему в целом, а не её отдельные части. Но разработчики, дизайнеры, тестировщики, менеджеры подразделения компании, заказавшей проект, — все они работают в рамках своей локальной области и склонны добиваться личной эффективности либо эффективности создаваемых ими частей проекта, упуская из вида общие цели проекта.

Приведённый пример мог подвести к мысли, что при наличии нужных компетенций суть идеи сводится к определению уровня абстракции, с которого мы должны

рассматривать систему при проектировании. Но почему же тогда я использовал ещё одно слово — «ответственность»? В конце концов, способность принять решение, которое будет максимально отвечать целям и учитывать все факторы, зависит от того, насколько человек обладает полнотой знаний о вопросе, имеет опыт и понимание смежных дисциплин. Но фокус в том, что этого оказывается недостаточно. Дело в том, что тот самый уровень, необходимый для принятия каждого решения в проекте, имеет две координаты, а не одну. А именно уровень абстракции и ответственности.

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

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

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

Итак, если следовать логике, то в проекте должен быть тот, кто будет в дальнейшем использовать разрабатываемый продукт. Не фокус-группа, не умозрительный персонаж,

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

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

начнётся их проверка, многие решения будут пересмотрены, а вместе с ними и результаты всей работы.

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

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

достаточного уровня, соответствующего задачам, и не готов отвечать на базовые вопросы проекта.

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

Читая очередную книгу о подходах к организации проектной работы или методах проектирования, я подобно мистеру Томпкинсу из романа «Дэдлайн» недоумеваю, а где же во всех этих схемах, процессах и ролях находятся люди с их личными качествами и желаниями? Если бы всё было так просто, то уже тех методических наработок, которые были в середине XX

века, было бы достаточно, чтобы выполнять проекты любой сложности. Вопрос правильного принятия решений при проектировании прежде всего лежит не в плоскости технологий, а в особенностях человеческой природы.

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

Например, при создании банковского мобильного приложения проектировщик, продумывая логику взаимодействия с пользователями, представляет интерфейс в модном и актуальном, на его взгляд, виде. Это могут быть функции для просмотра счетов и операций, заказа банковских продуктов и общения с поддержкой. Старясь держаться в тренде и больше думая о личном портфолио, проектировщик упускает из вида соответствие интерфейса и функций возможностям внутренней АБС (автоматизированной банковской системы), которая непосредственно их реализует, а заодно и правовым документам, на основании которых банк оказывает услуги своим клиентам. Разработчики, получая такую постановку задач, возвращаются за уточнениями к проектировщикам, что приводит к непредсказуемым по длительности циклам согласований, либо стараются самостоятельно решить обнаруженную проблему. В первом случае увеличиваются сроки и бюджет проекта, а во втором, определённо страдает качество продукта, т.к. решения принимаются не на том уровне абстракции и компетенции.

Если возложить на проектировщиков ответственность за

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

Отправных точек, т.е. первоначальных решений, лежащих в основе проекта, может быть несколько. В случае с банковским примером — это решение ограничить функциональный уровень сценариями обслуживания клиентов. Далее следует решение создать мобильное приложение и голосового ассистента, которое относится к интерфейсному уровню; и решение использовать для реализации конкретные платформы, например, iOS и «Алису», которое относится к техническому уровню. Все это так или иначе обусловлено бизнес-требованиями, дополненными рыночной конъюнктурой, требующей от банков иметь обязательный набор каналов взаимодействия с клиентами, и договорённостями о совместных маркетинговых акциях по продвижению вместе с поставщиками платформ. При этом, как мы видим, на организационном уровне проекта у нас нет определённости.

Если связать первоначальные решения с первыми двумя правилами принципа проектирования, то, во-первых, они уменьшают неопределённость в проекте, а во-вторых, должны исходить от людей, обладающих нужным уровнем

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

Теперь посмотрим, как происходит проверка по итогу работы над концепцией продукта. Это, как было сказано в предыдущем абзаце, первая контрольная точка, через которую обязательно должен пройти проект. Её цель — убедиться, что в проекте найдены решения на всех уровнях, при этом они соответствуют каждому из трёх правил: 1) неопределённость уменьшается; 2) они приняты на нужном уровне абстракции, компетенции и ответственности; 3) они связаны между собой и с первоначальными целями проекта.

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

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

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

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

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

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

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

контрольную точку, участники проекта будут задавать себе три вопроса: «Это уменьшает неопределённость?», «Это мой уровень компетенции и ответственности?», «Это связано с исходными целями проекта?»