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

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

• В ловушке предсказуемости

• Цифровые продукты в бизнесе

• Что такое «Метод параноика»

• Проджект-раннер и продюсирование проектов

• Области применения метода

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

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

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

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

В ловушке предсказуемости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое «Метод параноика»

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

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

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

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

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

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

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

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

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

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

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

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

Проджект-раннер и продюсерская модель управления

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

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

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

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

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

Области применения метода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Успех Doom’а наглядно показал, что этот подход больше не работал. Не было особого смысла в том, чтобы делать одну и ту же вещь даже дважды; практически вся ценность сосредотачивалась в воплощении творческого порыва в самый первый раз. После того как Doom был выпущен, тысячи программистов и художников могли сделать что-то подобное (и многие делали), но никто из них и близко не подошел к такому же эффекту. Проще говоря, если ты программист, возможно, ты вполне способен написать аналог существующей соцсети или поисковый механизм как у Google, или Twitter, или браузер, и ты определенно можешь штамповать Tetris, или Angry Birds, или Words with Friends, или Farmville, или любую из сотен других чрезвычайно успешных программ. Однако прибыль от такой деятельности будет крайне мала, и в этом вся фишка – в эпоху Интернета софт имеет практически нулевую стоимость копирования и массивные сетевые эффекты, которые приводят к так называемой “спирали положительного фидбэка”, а следовательно, именно тот, кто первым сделает ход, будет доминировать».

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

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

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

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

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

В такой бизнес-модели имеют значение следующие параметры:

• цена аренды (желательно ниже);

• сумма зарплат всех сотрудников (желательно ниже);

• среднее время присутствия гостей (желательно короче);

• средняя стоимость заказа (желательно выше);

• количество посетителей в день (желательно больше и без пауз между получением заказов).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструмент имеет значение только при его использовании, а его характеристики определяются потребностями бизнеса. Например, в случае с «Газелью» грузоподъемность или размеры, связанные с характером перевозок. Получается, инструмент подчинен бизнесу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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