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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

а именно – уровень абстракции.

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

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

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

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

Давайте теперь посмотрим, что это значит с практической точки зрения. Например, попробуем разобраться, как

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Эта часть главы находится в работе и скоро будет опубликована. Следить за обновлениями можно в Телеграм-канале «Метод параноика».
comments powered by HyperComments

Вадим Митякин
Автор метода параноика, основатель цифровой артели Eleven. Подробнее...
Привет, читатель!

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

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

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

Первая глава книги была опубликована осенью 2019 года. Сейчас идет работа над последними главами красной книги. Главы публикуются по мере готовности, за ходом работы можно следить в телеграм-канале.
Telegram-канал "Метод параноика"
Профессиональная точка зрения, связанная с проектированием и разработкой цифровых продуктов и сервисов. Заметки, которые рождаются в процессе работы над книгой и материалами по методу параноика.
Instagram "Метода параноика"
Новый ресурс, пока только создан, но подписаться определённо стоит. Активность начнет после выхода книги, когда у метода начнется своя собственная жизнь за пределами эпистолярного жанра.
Английский перевод книги
For the last 25 years I have been creating digital products in different roles. First as a developer, then as an entrepreneur, now as a producer and product designer. A year ago I decided that I needed to write a book that would describe my approach to how to get the product that business really needs. So now I am also a writer.
Первая часть
Сейчас идет работа над книгой. Главы публикуются по мере готовности. Последнее обновление было в апреле 2021 года, планирую закончить этим летом.
Глава 9. Принцип сериала
Глава в работе...
Глава 11. Принцип вовлечённости бизнеса
Глава в работе...
Глава 11. Playbook
Глава в работе...
Вторая часть
Планируется начать работу после готовности первой части (красной книги) и одновременно с подготовкой учебного курса для продюсеров. Структура книги носит предварительный характер и будет уточняться по мере работы над ней.
Глава 1. Продюсирование и принципы создания проектных команд
Аспекты продюсирования проектов. Формирование команды, настройка рабочего процесса, взаимодействие с клиентом и бюджетирование.
Глава 2. Концепция продукта
Как найти идею продукта и сформулировать принципиальную схему решения, а потом защитить ее перед клиентом.
Глава 3. Функциональное проектирование
О проектировании цифрового продукта с точки зрения того, какие функции он выполняет. Как перейти от концепции продукта до отдельных пользовательских сценариев.
Глава 4. Интерфейсное проектирование
Как спроектировать наиболее подходящий способ взаимодействия пользователя с продуктом. Об интерфейсах и дизайне для мобильных приложений, онлайн-сервисов и голосовых систем.
Глава 5. Техническое проектирование
О тот, как обрести уверенность в том, что все фантазии клиента и дизайнера получится воплотить в жизнь. Как выполнить техническую экспертизу, спроектировать архитектуру и сделать детальную проработку способа реализации каждого из компонентов системы.
Глава 6. Авторский надзор и управление разработкой
Работа продюсера и проектировщика с командой разработки на всех стадиях проекта, от первоначальной экспертизы до запуска. Как избежать потери контроля и получить в результате продукт таким, как о задумывался.
Электронное приложение. Примеры проектной документации и материалов
Набор проектных артефактов, иллюстрирующих все аспекты продюсирования и проектирования: спецификации, схемы, планы и бюджеты, прототипы интерфейсов и макеты дизайна продукта.
Учебные материалы
В дополнение к книге мы начинаем готовить учебные материалы. В 2021 году это направление будет развиваться. Помимо того, что уже сейчас участники цифровой артели Eleven ведут занятия в Нетологии и GeekBrains, мы планируем запустить собственный учебный курс в рамках Школы параноиков. Следите за новостями!

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