История создания метода

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

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

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

Структура книги

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

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

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

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

Что изменилось во втором издании

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

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

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

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

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

Благодарности

Паше Шереру, моему коллеге и партнеру по множеству проектов, за его активное участие и поддержку во время написания первой версии книги.

Жене Зеленому из компании Visa за то, что поверил в метод и дал зеленый свет одному из крупнейших проектов по продюсерской модели еще до того, как даже появился замысел этой книги.

Даше Кошкиной за иллюстрации для первой версии книги.

Сергею Гурову, моему другу и коллеге, за идею и дизайн обложки для первого издания книги.

Николаю Чулкову и Олегу Матвееву из компании AdWorm за помощь в обновлении и создании иллюстраций и обложки для нового издания.

Анне Галагуре за вдохновение и поддержку при работе над книгой, когда уже казалось, что ничего не получится.

Косте Шахраю и Максу Толкачеву за атмосферу и классное кафе «Флер» в Светлогорске, где была написана существенная часть книги.

Диме Вальянову, руководителю международного направления Битрикса за глубокий анализ идей книги и обратную связь.

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

Игорю Кожелину, основателю космической компании SR Data, за поддержку и распространение книги в предпринимательской среде.

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

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

Марине Бердник из издательства «Бомбора» за выбор книги для переиздания и за то, что помогла разобраться с личным архетипом писателя.

Команде автостартапа «Атом» за то, что дали свободу и пространство для творческого поиска решений при внедрении метода, благодаря чему были отточены идеи для второго издания книги.

Команде Unilever и их новой IT-компании в России за масштаб задачи и основательный подход при внедрении технологии продуктовой разработки на основе метода.

Дмитрию Чистову и Василию Корешкову, моим единомышленникам по методологическому клубу, за идеи.

Всем моим читателям, которые своим интересом к книге сделали первую версию бестселлером в 2022–2023 году и вдохновили на переиздание.

Глава 1
Цифровые продукты в бизнесе

Структура главы:

• Технологии необходимы, но недостаточны

• Цифровые технологии в бизнесе

• О важности бизнес-инфраструктуры

• Критерии успешности продукта

• Как искать технологические решения для бизнеса

• Отраслевые концепты

• Дилемма бизнеса и IT-специалистов

Технологии необходимы, но недостаточны

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

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

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

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

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

Помимо проблемы ошибочных ожиданий от технологий, существует еще одно распространенное заблуждение – непонимание причин успеха цифровых продуктов. Многие помнят яркие примеры успеха мобильных приложений и сервисов: продажа WhatsApp за миллиард долларов, взлет Prisma и FaceApp, взрывная популярность Twitter, YouTube, TikTok и ChatGPT. Но мало кто знает, что одновременно с этим разработчики получали массу заказов на создание аналогов популярных приложений. Людям казалось, что, сделав такие же, но улучшенные продукты, они повторят успех. Как правило, даже при внушительном бюджете и качественном исполнении, такие проекты проваливались еще на старте.

Уже тогда я интуитивно начал понимать, в чем дело. У успеха продукта две стороны: одна – это решение задач пользователей, другая – быть первым, оказаться в нужное время в нужном месте и связать представление пользователей о задаче именно с ним, когда его название становится синонимом самой задачи. Лучше всего об этом написал один из создателей Quake, Майкл Абраш в статье «Valve: как я здесь оказался, на что это похоже и чем я здесь занимаюсь»:

«Гэйб рассказывает об этом так. Когда он работал в Microsoft в начале 90-х, он провел опрос на тему того, какое ПО установлено на компьютерах работников. На втором месте по популярности оказалась Windows.

На первом был Doom.

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