Вадим Митякин

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

Бизнес. Как это работает в России

© Митякин В. В., текст, 2023

© Чулков Н. В., иллюстрации во внутреннем оформлении и на обложке, 2024

© Оформление. ООО «Издательство «Эксмо», 2025

Пролог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В основе «Метода параноика» лежит работа большого количества людей, участвовавших со мной в нескольких сотнях проектов разной степени сложности. Запуск самостоятельных коммерческих продуктов, разработка корпоративных систем и мобильных приложений для самых разных компаний, среди которых Майкрософт, Лаборатория Касперского, Яндекс, Сбер, Афиша, Коммерсант, Ведомости, Литрес, Мое дело, 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 человек промаршировать к определенной точке и пасть там смертью храбрых. После того, как произошла Индустриальная революция, иерархический менеджмент снова оказался отличным выбором, так как в конечном итоге целью было рассматривать любого человека в качестве компонента, выполняющего одну и ту же работу снова и снова.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В каком состоянии находится компания? Кажется, все в порядке, пока что-то не начинает нарушать привычный уклад. Один уволившийся сотрудник – не проблема. Но если это финансовый директор или уходит вся ключевая команда? Это уже заметно. Изменения в финансовых показателях, выраженных в отчетах, сложнее заметить. Упала выручка на 7 %? Бывает. Снижение продолжается несколько месяцев? Уже заметнее. Но что, если это происходит одновременно с изменением других параметров? Тогда тенденции не столь очевидны.

А если ничего не меняется? Сотрудники работают, обороты компании на прежнем уровне. Кажется, не стоит беспокоиться. Но, возможно, все вокруг меняется, просто вы этого не замечаете. Например, у конкурентов растут обороты и рынок развивается, а это означает, что ваш бизнес теряет позиции, и вскоре вы это почувствуете, но будет поздно. Нассим Талеб называет это «Черным лебедем» – неожиданным событием, которое вы не заметили из-за невнимательности или непонимания.

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

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

Точка отсчета

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

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

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

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

Мобильные приложения

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

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

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

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

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

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

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

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

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

Голосовые интерфейсы и искусственный интеллект

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

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

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

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

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

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

Помимо сценариев использования голосовых интерфейсов через «умные» устройства, как колонки и телефонные звонки, есть мобильные приложения голосовых ассистентов. Их концепция проста: обращаясь к ассистенту, вы запускаете определенный сервис, реализованный в виде отдельного сценария голосового взаимодействия. Эти сервисы называются «навыками» и позволяют заказать такси, поиграть в игру, узнать статус заказа и прочее. Любая компания или разработчик может создать свой «навык» для пользователей голосовых ассистентов, таких как Алиса от Яндекса или Amazon Alexa. К сожалению, у подобного подхода есть существенный недостаток – сложность и неочевидность использования.

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

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

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

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

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

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

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

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

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

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

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

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

Глава 2

Как устроена индустрия создания цифровых продуктов

Содержание главы:

• Зачем нужно знать устройство IT-индустрии

• Типы проектов

• Форматы работы

• Экономика проектов

• Экосистема IT-индустрии и продюсирование проектов

Зачем нужно знать устройство IT-индустрии

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

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

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

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

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

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

Помню, как впервые прочитал книгу Дэвида Майстера «Управление фирмой, оказывающей профессиональные услуги». На тот момент компании «ГАЛС СОФТ» было уже 10 лет, и, к своему удивлению и восторгу, я нашел в этой книге ответы на большинство накопившихся вопросов. Я был поражен, как все просто складывалось. Майстер писал про юридические и консалтинговые компании, я же адаптировал описанную модель под реалии IT-индустрии. В итоге после анализа нашей деятельности мы кардинально изменили формат работы с клиентами, а с некоторыми из них даже завершили проекты, чтобы сфокусироваться на приоритетных задачах. Всем, кто занимается проектной деятельностью, настоятельно рекомендую прочесть как минимум две книги – «Управление фирмой, оказывающей профессиональные услуги» и «Истинный профессионализм».

Типы проектов

По мнению Дэвида Майстера, существует три обобщенных типа проектов – «Мозги», «Седина» и «Процедуры» (Brains, Grey Hair, Procedures).

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

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

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

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

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

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

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

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

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

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

Форматы работы

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

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

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

Самая распространенная область – это левый нижний квадрант. Здесь задачи просты и стандартизированны, а коммуникации минимальны. Например, нужно разработать сайт или мобильное приложение. Клиент формулирует задачу и передает ее исполнителю, который работает над ней и возвращается с готовым результатом. Это похоже на то, как вы приходите с рецептом в аптеку и покупаете либо готовое лекарство, либо сделанное по вашему рецепту. Поэтому квадрант называется «Фармацевт» (Pharmacist). Это классический аутсорсинг.

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

Теперь посмотрим на другую область – левый верхний квадрант. Здесь задачи тоже простые либо не индивидуализированные, но требуют регулярных коммуникаций. Важно понимать, что высокая интенсивность общения клиента с исполнителем отражает суть решаемых задач. Примером может служить продвижение бренда компании в диджитал-пространстве. Такую задачу невозможно выполнить раз и навсегда, требуется постоянная работа, учитывающая текущий контекст на рынке и меняющиеся бизнес-цели клиента. Это похоже на работу медсестры, которая следит за состоянием пациента и выполняет типовые процедуры. Квадрант называется «Сиделка» (Nurse).

Если проекты типа «Фармацевт» имеют конечный срок, то в случае с «Сиделкой» работа выстраивается вокруг долговременных целей клиента. Это характерная черта бизнес-модели диджитал-агентств. На ум приходят термины «аккаунт-менеджер», «медиа-план», «kpi на календарный период», «рекламные акции» и т. п.

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

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

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

Теперь, когда мы разобрались со сложностью, перейдем к двум оставшимся квадрантам. Начнем с правого нижнего, где уровень коммуникаций между клиентом и исполнителем низкий. Как и «Фармацевты», компании из этого квадранта получают описание задачи, после этого выполняют проект и возвращаются с готовым результатом. Ключевое отличие от «Фармацевтов» в том, что задача часто включает выяснение проблемы клиента и поиск ее решения. Это похоже на работу врача с пациентом, которому требуется сложная операция. После постановки диагноза ясно, что требуется сделать, пациент засыпает на операционном столе и просыпается после завершения операции. Поэтому квадрант называется «Нейрохирург» (Brain Surgeon).

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

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

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

Экономика проектов

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

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

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

Бизнес-модели

Самая распространенная модель – ресурсная. Это когда у вас как у компании есть ресурсы, и вы ими торгуете. В случае с заказной разработкой ресурсы – это специалисты и их рабочие часы. При этом как вы упаковываете эти часы для клиента – сдаете каждого разработчика в аренду по часовой основе («Time & Material» или «T&M») или продаете целиком команду на проект – не имеет значения. Это может быть аутстафф и классический аутсорсинг. Важно то, что чем больше у вас ресурсов, тем потенциально больше вы можете на них заработать. А вот то, как реализуется этот потенциал, определяет отношение количества проданных часов к календарному периоду.

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

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

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

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

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

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

Стоимость услуги в такой модели определяется не себестоимостью, а ценностью, которой услуга обладает в масштабах бизнеса клиента. Если новая технология позволяет клиенту зарабатывать дополнительные 10 % или сэкономить те же 10 %, то при обороте компании в 100 млн. рублей ценность услуги составит 10 млн. рублей. Именно о таком порядке стоимости услуг следует вести разговор, а не о часовой ставке. Иногда одного часа общения с клиентом достаточно, чтобы повлиять на его бизнес. Вы же не будете говорить о стоимости часа в несколько миллионов рублей? Конечно, у этой модели есть обратная сторона: одно и то же решение или технология даст пропорционально меньший результат в абсолютных значениях в бизнесе меньшего масштаба.

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

Приходы и расходы

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

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

Если клиент покупает конкретные результаты работы, например дизайн-макеты сайта или спроектированное и разработанное мобильное приложение, то это проектная работа. Для такой работы характерны нерегулярные поступления, то есть оплата клиента привязана к этапам проекта, а не к календарным периодам. Более того, каждый этап может иметь разную стоимость, ведь от этапа к этапу может быть задействован разный состав команды. Стоимость может рассчитываться по фактически отработанным часам («Time&Material» или «T&M»), или быть фиксированной («fixed price»). В ресурсной бизнес-модели способ расчета стоимости это вопрос, кто несет риски – клиент или подрядчик.

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

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

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

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

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

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

Экосистема IT-индустрии и продюсирование проектов

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

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

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

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

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

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

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

Другая ситуация, когда бизнесу нужно сделать решение, как у конкурентов. Лучший выбор – это подрядчик с отраслевым опытом и выполненными аналогичными проектами. Когда компания занимается похожими проектами, формируется структура команды. Например, когда мы в «ГАЛС СОФТ» создавали приложения для СМИ, на проекте всегда были руководитель проекта, интерфейсный дизайнер, технический архитектор, разработчики для каждой из мобильных платформ и тестировщик. Работа команды укладывалась в один и тот же проектный цикл, состоящий из одинаковых этапов. Более того, если разрабатываемые продукты имеют схожую функциональность, то и состав, и объем задач у каждого из участников будут похожи от проекта к проекту. Таким образом обычно строится работа над проектами типа «Седина».

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

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

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

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

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

Глава 3

Оценка проектов, планирование и неопределенность

Содержание главы:

• Кто прав: бизнес или специалисты?

• Почему невозможно точно оценить проект

• Что делать с неопределенностью в проектах

• Тип проекта как индикатор уровня неопределенности

• Бизнес и цели проекта

• Живое воплощение неопределенности, или выбор специалистов для работы над проектом

• Ограничения традиционных подходов к управлению проектами

• Проектирование и неопределенность

• Итог

Кто прав: бизнес или специалисты?

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

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

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

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

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

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

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

Почему невозможно точно оценить проект

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

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

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

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

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

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

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

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

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

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

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

Не обманывайтесь. Эта история длится десятки лет. Борьба идет с переменным успехом, и периодически верх берет то одна, то другая сторона. Благодаря этому регулярно появляются новые методологии и подходы: дизайн-мышление, проектирование на основе персонажей, Jobs-to-be-done, Agile, Scrum, RUP, экстремальное программирование и прочее. Каждая новая модель предполагает радикальное улучшение процесса и возможность получить нужный результат. Но, как говорил Брукс в своей знаменитой книге «Мифический человеко-месяц», серебряной пули не существует, и вряд ли она когда-нибудь появится. Методологии в основном служат не для снижения неопределенности, а для обоснования переноса рисков со специалистов на бизнес.

Независимо от используемого в проекте подхода, источник риска – неопределенность – не исчезает. Компромисс между сторонами тоже не решает проблему, в конечном счете кто-то все равно должен заплатить за возникающие издержки: либо одна сторона, либо другая, либо обе.

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

Что делать с неопределенностью в проектах

Догадываетесь, к чему я веду? Если неопределенность мешает точному планированию, стоит сконцентрироваться на поиске способов ее уменьшения. Конечно, полностью устранить ее невозможно, но это и не требуется. Значение имеет само знание о наличии неопределенности и ее локализация в отдельных частях проектах. Нассим Талеб после выхода книги «Черный лебедь» объяснял ее ключевую идею: причиной неожиданности события может быть как сама природа такого события (например, метеорит), так и слепота наблюдателя (как экономический кризис 2008 года). И если с первой категорией мы ничего поделать не можем, то со второй такая возможность есть.

Локализация неопределеннос

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

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

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

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

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

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

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

Тип проекта как индикатор уровня неопределенности

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

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

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

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

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

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

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

Неопределенность возрастает от проектов типа «Процедуры» к «Седине» и достигает своего максимума в «Мозгах». Коротко это можно описать следующим образом.

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

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

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

На примерах компаний в разных ситуациях я хочу показать возможные варианты развития событий и способы работы над проектами разных типов. Рассмотрим случаи:

а) бизнес, который стоит перед необходимостью кардинальных изменений;

б) открытие нового бизнес-направления или стартапа;

в) успешный бизнес, развивающий свои цифровые сервисы.

Бизнес на пороге кардинальных изменений

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

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

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

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

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

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

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

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

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

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

Новое направление в бизнесе или стартап

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

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

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

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

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

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

Работающий бизнес, развивающий свои цифровые сервисы

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

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

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

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

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

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

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

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

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

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

Типы проектов в жизненном цикле развития бизнеса

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

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

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

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

Бизнес и цели проекта

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

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

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

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

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

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

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

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

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

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

Живое воплощение неопределенности, или выбор специалистов для работы над проектом

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

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

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

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

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

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

Тендерные процедуры

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

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

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

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

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

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

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

Критерии выбора исполнителей для управления неопределенностью

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения традиционных подходов к управлению проектами

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

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

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

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

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

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

Слабая вовлеченность бизнеса в проектную работу

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

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

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

Навязываемые сроки

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

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

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

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

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

Большие релизы в стиле «все и сразу»

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

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

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

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

Проект без капитана

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

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

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

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

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

Проектирование и неопределенность

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

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

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

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

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

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

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

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

Негативная эволюция

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

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

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

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

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

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

Новое время и неопределенность

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

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

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

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

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

Документация

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

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

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

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

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

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

Проектирование и бизнес

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

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

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

Итог

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

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

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

Глава 4

Принцип контроля неопределенности

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

• «Метод параноика» и продюсирование проектов

• Как взять неопределенность под контроль

• Концепция воронки неопределенности

• Принципы метода

«Метод параноика» и продюсирование проектов

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

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

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

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

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

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

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

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

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

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

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

Как взять неопределенность под контроль

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

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

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

• цели бизнеса;

• понимание того, каким должен быть продукт, чтобы их достигнуть;

• выбор специалистов для его создания;

• организация проектной работы;

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

Цели бизнеса

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

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

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

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

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

Понимание того, каким должен быть продукт

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

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

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

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

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

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

Выбор специалистов, необходимых для работы над проектом

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

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

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

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

Организация проектной работы

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

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

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

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

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

Ресурсы, необходимые для реализации проекта

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

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

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

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

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

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

Обычно для всего проекта принято использовать одинаковый подход к оценке, независимо от характера работ на разных стадиях. Выбор делается из двух крайних вариантов: T&M (расчет по фактически затраченному времени специалистов) и Fixed Price (фиксированная стоимость за определенный набор задач). В случае же организации работы, когда неопределенные задачи решаются как можно раньше, а более предсказуемые идут следом, для каждой стадии применяется индивидуальный подход к планированию и оценке.

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

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

Воронка неопределенности

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

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

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

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

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

Принципы метода

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

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

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

Принцип проектирования

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

Принцип гибких команд

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

Принцип продюсирования

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

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

Принцип сериала

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

Принцип вовлеченности бизнеса

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

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

Описание принципов

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

Глава 5

Принцип проектирования

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

• Цифровые продукты – это сложные системы

• Новая роль проектирования

• Первое правило: каждое решение должно уменьшать неопределенность

• Второе правило: каждое решение требует своего уровня абстракции, компетенции и ответственности

• Третье правило: все решения должны быть связаны

• Проектировщик – генеральный конструктор продукта

Сложные системы должны быть спроектированы до реализации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новая роль проектирования

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

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

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

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

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

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

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

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

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

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

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

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

Первое правило: каждое решение должно уменьшать неопределенность

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

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

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

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

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

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

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

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

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

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

Второе правило: каждое решение требует своего уровня абстракции, компетенции и ответственности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третье правило: все решения должны быть связаны

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

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

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

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

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

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

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

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

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

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

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

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

Проектировщик – генеральный конструктор продукта

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

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

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

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

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

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

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

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

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

Глава 6

Кодекс проектировщика

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

• Насмотренность, исследования, мастерство

• Как работает штанга Талеба

• Поиск источников информации

• Аналитика ≠ проектирование

• Для чего нужны исследования в проектировании

• Личная история исследований

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

• Продюсирование как альтернативная модель работы в IT-отрасли

Насмотренность, исследования, мастерство

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

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

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

Исследование – второй шаг. Это процесс, когда вы сами разбираетесь в заинтересовавшей вас профессиональной теме. Результаты исследования важны, но сам процесс еще важнее. Во время исследования новой области знаний вы ее осваиваете, т. е. делаете своей. Не пройдя путь практики и анализа, terra incognita вряд ли станет terra mea. Такие инвестиции в свои знания и опыт расширяют ваши возможности и позволяют заниматься интересными проектами.

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

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

Насмотренность проектировщика

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

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

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

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

Как работает штанга Талеба

Здесь я хочу подвести вас к концепции «штанги», описанной Нассимом Талебом в «Антихрупкости». Суть в том, что большинство из нас всегда усредняет возможности, тогда как стоит разделить их все на две крайности, подобно блинам на концах грифа штанги. С одной стороны (по Талебу это левая сторона, но в нашем случае это не имеет значения) должны быть проверенные подходы, гарантирующие результат. В конце концов, как пишет Талеб, это вопрос выживания. С другой стороны (правой) следует расположить все, что несет риск и одновременно может принести неожиданные возможности. Как писатель, который работает в кафе, чтобы заработать на жизнь, одновременно пишет роман, который может стать бестселлером. Худшее, что может случиться – роман не будет успешным, но писатель продолжит свою жизнь. Так и вы, будучи профессионалом, можете работать в области, хорошо вам известной, опираться на свои проверенные знания, и в то же время делать рискованные ставки в расчете на неочевидный успех. Главное – не смешивать.

Штанга для контроля неопределенности в проектах

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

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

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

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

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

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

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

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

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

Стратегия штанги для профессионального развития

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

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

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

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

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

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

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

Поиск источников информации

О ценности первоисточников

Если вы, как и я, занимаетесь проектированием цифровых продуктов, то наверняка знакомы с концепцией персон, придуманной Аланом Купером. Возможно, вы не знали автора этой концепции и познакомились с понятием персон в тематической статье. Также вероятно, что из той статьи вы узнали об устаревании и ошибочности этого подхода, а вместо него автор предлагает использовать другой подход к проектированию, например, Jobs-To-Be-Done и Job stories. Забавно, что и автор статьи, скорее всего, недостаточно знаком ни с методом персон, ни с новым методом, который он описывает. Он так же, как и вы, мог о них прочитать в профессиональном издании и решил собрать все вместе.

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

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

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

Экспедиции в мир других

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

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

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

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

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

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

Аналитика ≠ проектирование

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

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

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

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

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

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

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

Для чего нужны исследования в проектировании

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

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

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

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

Извращенная корпоративная модель использования исследований

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

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

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

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

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

Через несколько дней после того, как я закончил эту главу, в блоге Алана Купера вышла статья «Practitioners in Businessland». Она созвучна моим идеям, и я не могу не процитировать ее фрагмент (а лучше прочитайте ее целиком):

«Basically, everyone in business is looking for a way to do things more quickly, more easily, and with less skilled people. The solution, of course, is to take more time, work harder and use more highly skilled people.

In other words, the best business people are wrong. Sadly, those same business people often make lots of money being wrong.

Don’t conflate making money with making successful products. Your boss will not reward you for taking time and working harder. Do you want a raise and a promotion? A nice house and a new Tesla? Or do you want to create a supportive, healthy, peaceful world in which your children can grow old in happiness? You have to make a choice about how you wish to shape the world you live in. That’s a very tough choice».

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

Для чего нужны исследования в вашей профессиональной жизни

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

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

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

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

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

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

Личная история исследования голосовых систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продюсирование как альтернативная модель работы в IT-отрасли

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

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

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

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

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

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

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

Специфика индустрии путешествий в том, что она базируется на устаревших технологиях. Вы, наверно, слышали термин GDS (Global Distribution System). Это международные системы бронирования билетов, которые были разработаны несколько десятилетий назад и до сих пор существуют в неизменном виде. Каждый раз, когда вы покупаете билет в любимом онлайн-сервисе, этот сервис обращается к GDS, чтобы запросить информацию о тарифах и оформить заказ в авиакомпании. Многие ограничения, которые могут вам показаться странными, связаны с тем, как реализованы API GDS.

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

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

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

Глава 7

Принцип гибких проектных команд

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

• Команды в разных типах проектов

• Сила и слабость фиксированных команд

• Выбор участников гибких команд

• Проектирование проектных команд

• «Железобетонное» правило

• Правило многоуровневой команды

• Правило предварительной проверки команды

• Управление гибкими командами

• Коммуникации между участниками

Команды в разных типах проектов

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

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

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

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

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

Сила и слабость фиксированных команд

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

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

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

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

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

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

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

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

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

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

Выбор участников гибких команд

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

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

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

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

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

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

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

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

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

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

Проектирование проектных команд

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

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

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

«Железобетонное» правило

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

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

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

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

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

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

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

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

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

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

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

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

Правило многоуровневой команды

Второе правило принципа проектирования гласит: каждое решение в проекте требует своего уровня абстракции, компетенции и ответственности. Применительно к гибкому формированию команд на это можно смотреть так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правило предварительной проверки команды

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление гибкими командами

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

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

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

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

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

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

Это означает, что специалисты в инженерных и креативных компаниях не должны быть «подчиненными» управленцам, выступая в роли исполнителей. Право принятия решений не должно быть обусловлено лишь наличием полномочий, не подкрепленных компетенциями. Вообще, как только в такой компании побеждают менеджеры, бизнес начинает стагнировать, теряя клиентов, либо упрощается до уровня «чистых» управленцев, переходя на понятную им торговлю «ресурсами», о чем я подробно писал во второй главе. Любимое их выражение «Я не хочу знать, как вы это сделаете, но чтобы было готово к завтрашнему дню». Уважающие себя специалисты такого не терпят и уходят, а вместе с ними утрачивается способность компании создавать сложные продукты. В качестве примера можно вспомнить тех же Nokia или Disney до начала сотрудничества с Pixar.

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

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

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

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

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

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

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

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

Коммуникации между участниками

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 8

Принцип продюсирования

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

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

• Трансформация бизнеса через цифровые технологии

• Цифровой продукт обретает конкретные черты

• Организация проектной работы

• Как стать проджект-раннером

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

Между Сциллой и Харибдой

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функции проджект-раннера

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

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

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

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

Трансформация бизнеса через цифровые технологии

Ложная дилемма предпринимателя

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

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

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

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

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

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

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

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

Кто должен заниматься сексом с вашей женой

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

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

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

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

В конечном счете те же P&L и cashflow, а также все возможные метрики и индикаторы – это только средства контроля. Важно спросить себя: «Контроля чего?» Ответить на этот вопрос должен владелец компании или руководитель направления. Именно он должен найти схему работы, которая принесет прибыль и будет жизнеспособной и устойчивой на определенном промежутке времени, за который «отобьются» вложения в реализацию. Согласно принципу гибких проектных команд, он тоже ключевой участник проекта, рассматривающий бизнес как систему на соответствующем уровне абстракции.

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

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

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

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

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

Доверенное лицо бизнеса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

До цифрового продукта

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

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

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

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

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

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

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

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

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

Цифровой продукт обретает конкретные черты

Неопределенность в тисках ограничений

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

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

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

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

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

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

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

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

Баланс вместо компромисса

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

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

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

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

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

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

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

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

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

Скрепы проектного бутерброда

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

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

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

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

Организация проектной работы

Творчество против определенности

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

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

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

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

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

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

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

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

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

Жизненный цикл гибкой проектной команды в продюсерском подходе

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

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

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

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

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

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

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

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

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

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

Шкура проджект-раннера на кону проекта

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

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

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

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

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

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

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

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

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

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

Для снижения риска можно использовать принципы контроля неопределенности, которые заложены в «Методе параноика», но у всего есть предел. В некоторых проектах риск неизбежен, например, когда успех зависит от исследовательских задач и невозможно спрогнозировать, сколько времени займет их выполнение. Похожая ситуация складывается в проектах, ориентированных на принципиально новые бизнес-модели, где неясно, как примут продукт пользователи. Везде, где степень риска невозможно заранее просчитать, важно понимать, каким запасом прочности обладают участники проекта и до каких издержек они готовы дойти. Это также следует использовать в качестве одного из факторов, который нужно учитывать и на уровне проектирования, и на уровне организации проектной работы.

Чем больший риск берет на себя человек, тем большим контролем за ситуацией он должен обладать. Как канатоходец над пропастью, вы вряд ли согласитесь на трюк, если не сможете выбрать материал для каната, время суток, когда солнце не будет вас слепить, и погодные условия, чтобы избежать дождя и ветра. То же самое относится и к проектной работе, где имеют значение выбор людей в команду, технологии, способы управления и бюджетирования, плюс все решения, относящиеся к устройству цифрового продукта. Как проджект-раннер вы обязательно должны контролировать ключевые параметры проекта, ведь от них зависит получится у вас добиться нужного результата или нет. И это, вероятно, самый сложный для бизнеса момент, поскольку деньгами он еще готов поделиться, но вот передать часть контроля, как правило, нет.

Здесь я должен привести последний аргумент в пользу подхода, когда проджект-раннер наделяется достаточными полномочиями для управления процессом создания цифрового продукта. Делать что-то хорошо можно только когда веришь в сам продукт, и в методы работы над ним. Не принимая идеи, лежащие в основе бизнес-модели компании, вряд ли получится продуктивно находить способы их реализации. Возможно, для вас будет сюрпризом, но большинство IT-проектов терпят неудачу, и специалисты из нашей отрасли часто теряют уверенность, что их работа имеет хоть какое-то значение. В результате многие включаются в проекты без веры в успех. Для них это просто способ заработка, без уважения к ценностям бизнеса, с которым они взаимодействуют. Получается негативный замкнутый цикл.

Чтобы его разорвать, проджект-раннер должен изначально оценивать реалистичность замысла со стороны бизнеса, и в этом он может полагаться только на свое профессиональное чутье. Зачастую на бумаге все выглядит убедительно, но, если интуиция подсказывает, что не все так гладко, как может казаться владельцу компании, с этими подозрениями стоит разобраться, прежде чем приступить к работе. В терминах принципа проектирования это означает уменьшить неопределенность и только после этого двигаться дальше или не двигаться, отказавшись от участия в проекте. Если проджект-раннер будет действовать по навязанным правилам, в которых он не уверен или которые вызывают у него неприятие, то говорить о готовности взять ответственность на себя вряд ли получится. Напротив, будучи уверенным в предлагаемой бизнес-модели продукта и опираясь на подтвержденные опытом инструменты и методы организации проектной работы, проджект-раннер сможет по-настоящему проникнуться целями проекта и передать эту вовлеченность проектной команде.

Цена привлечения проджект-раннера

Теперь, когда есть концептуальное понимание взаимосвязи между полномочиями, мотивацией и принимаемым на себя риском, можно рассмотреть подходы к проектам, которые требуют разной степени вовлеченности проджект-раннера. Да, кажется, что в большинстве случаев необходима его максимальная концентрация на проекте, но у этого есть своя цена, и она не всегда оправдана.

(1) Когда не стоит вопрос о внесении изменений в бизнес-модель и необходимо обеспечить лишь технологическую реализацию, например, онлайн-сервисов, от проджект-раннера требуется только спроектировать продукт и подобрать необходимых специалистов, организовав проектную работу. Так обстоят дела в компании, которая занимается развитием своих цифровых инструментов в рамках сложившейся схемы работы. Если принципиальная схема решения уже сформулирована, не стоит повышать ставки и искать способы мотивации проджект-раннера для высокой вовлеченности в проект. Это начальный уровень, когда его роль совмещает в себе менеджера проекта, проектировщика и менеджера продукта.

При таком сочетании ролей проджект-раннеру должно быть достаточно полномочий в определении способа воплощения принципиальной схемы решения, то есть устройства продукта, плюс права подбора команды и организации проектной работы по своему усмотрению. Кроме возможности поучаствовать в интересном проекте, мотивацией может быть достаточно крупное вознаграждение. На него можно смотреть как на страховую премию бизнеса, и риск проджект-раннера состоит в том, что если ему не удастся достигнуть поставленных целей проекта, то она не выплачивается. Без дополнительного вознаграждения оплата работы проджект-раннера должна быть сопоставима с зарплатой мультидисциплинарного специалиста, кем он и является на начальном уровне. Успехом проекта будет считаться соответствие характеристик цифрового продукта изначальным целям, что никак не связано с возможными коммерческими результатами его использования. Проджект-раннер не участвует в формировании бизнес-модели, ответственность полностью на стороне бизнеса.

(2) Иначе обстоят дела в компании в момент ее трансформации. У владельцев уже есть понимание необходимости изменений бизнес-модели, но чтобы понять, в чем они могут состоять, может потребоваться помощь в анализе возможностей цифровых технологий. Это как раз тот момент, когда к работе должен подключиться проджект-раннер, и, в отличие от обычного технического консультанта, уже на столь ранней стадии от него потребуется высокий уровень вовлеченности. Только так он сможет правильно расставить акценты и подобрать подходящие технологические инструменты, на которые станет опираться новая бизнес-модель. Вряд ли вы будете спорить, что эффективность усилий не только проектной команды, но и бизнеса в целом, будет полностью зависеть от точности такого выбора.

В подобной ситуации вопрос качественной технической реализации конкретного цифрового продукта важный, но не первостепенный. Радикальные изменения в работе компании всегда связаны с большими рисками, и бизнесу стоит найти способ заинтересовать проджект-раннера, чтобы не потерять еще больше. Например, это могут быть проценты от экономии расходов компании за счет использования внутреннего технологического инструмента, созданию которого посвящен проект, или выплаты, пропорциональные коммерческому успеху нового онлайн-сервиса. Давая проджект-раннеру возможность заработать на результатах своей деятельности, бизнес фокусирует его на поиске коммерчески выгодных продуктовых решений.

Вполне ожидаемо, что полномочия проджект-раннера должны быть шире, чем просто управление проектом по своему усмотрению. Он должен контролировать в том числе аспекты устройства работы компании, выраженные в принципиальной схеме решения. Способом установить баланс ответственности служит то, что бюджет проекта, выделяемый бизнесом, – это фактически его бюджет, который находится под его управлением. При его превышении для проджект-раннера существует риск оплатить работу специалистов из своих средств. Он выступает гарантом того, что согласованный бюджет позволит реализовать запланированный объем задач. Конечно, имеет значение характер работ на каждой стадии проекта и подход к прогнозированию, о чем подробнее будет рассказано в следующей главе.

Ответственность проджект-раннера на данном уровне вовлеченности не распространяется на возможную коммерческую неудачу использования продукта. Его риски связаны только с собственными ошибками в управлении и проектировании. Издержки, которые может понести компания из-за новой бизнес-модели, полностью лежат на стороне владельцев, поскольку это их уровень принятия решений. Кроме цифровых инструментов, на успех влияют и другие факторы, которые находятся вне контроля проджект-раннера. Эта граница ответственности нужна, чтобы интерес проджект-раннера был выше угрозы потерь, обеспечивая необходимый уровень вовлеченности.

(3) Существуют проекты, где от проджект-раннера может потребоваться не просто высокая, а экстремальная вовлеченность. Речь идет о высокотехнологичных стартапах, аналогом которых в корпоративной среде может быть запуск новых направлений в бизнесе. И там, и там проджект-раннер чаще всего выступает не в роли приглашенного консультанта и организатора, а становится соучастником амбициозного замысла, по крайней мере на отрезке жизни компании, пока она не достигнет зрелости. Это означает, что в случае со стартапами продюсерский подход может использоваться самими предпринимателями, если у них достаточно технических компетенций.

Цель состоит в нахождении новой бизнес-модели, которая сможет доказать свою работоспособность на практике. Неопределенность таких проектов требует непрерывной проверки различных гипотез и изменения направления развития как продукта, так и бизнеса в целом. Проджект-раннер, как активный участник, должен не противодействовать изменениям, а наоборот, иметь мотив к поиску наилучшего сочетания схемы работы компании и цифровых инструментов. В этом ему может помочь возможность воплощать собственные концепты, о которых я рассказывал в «Кодексе проектировщика». Бизнес будет рад получить источник новых идей в его лице. На таком взаимном интересе и могут сойтись владельцы новой компании и проджект-раннер.

Неудивительно, что при таком уровне вовлеченности полномочия проджект-раннера приближаются к тем, которыми обладают организаторы бизнеса. Он по-прежнему определяет принципиальную схему решения и то, каким образом будет реализован цифровой продукт, но к этому добавляется его участие в решении того, какова будет схема работы компании. Право голоса при формулировании бизнес-модели достается не просто так. Проджект-раннер вкладывает в проект свои собственные средства. Объем вложений может отличаться от проекта к проекту, но в любом случае дает право претендовать на долю в прибыли компании. Риск тоже понятен – при неудаче вложения в проект могут не вернуться.

Сочетание интересов бизнеса и специалистов

Проджект-раннер, имея прямую связь с бюджетом, уже не может его рассматривать просто как цифры в таблице. В отличие от наемного менеджера, он знает цену деньгам, которыми оплачивается работа над проектом. Считайте это KPI прямого действия, который меняет его отношение ко всем аспектам проекта и позволяет иначе решить вопрос сочетания интересов бизнеса и специалистов. Это одна из сильных сторон продюсерского подхода.

В противоположность этому обычным способом согласования условий проекта служит игра «Угадай, если сможешь». Именно так стоит смотреть на конкурсы и тендеры. От потенциальных исполнителей проекта ожидается, что они предложат условия, которые устроят заказчика, но почему эти условия именно такие, им не сообщается. Хотя из бизнес-модели компании естественным образом следуют ограничения бюджета и сроков реализации необходимых для нее цифровых инструментов, это вовсе не значит, что данные ограничения являются константой. Вместо того, чтобы объяснить потенциальным участникам причины ограничений проекта, из них выбирается один из вариантов, который попал в диапазон допустимого бюджета и сроков. Остальные предложения даже не рассматриваются.

Победителю тендера кажется, что его выбрали за лучшее предложение, но он не знает объективных причин. Это незнание создает проблемы для проекта в будущем, потому что у команды нет понимания настоящих целей, и она не может соизмерять свои технические решения с ними. Между целями бизнеса и функциональными требованиями, которые обычно указываются в техническом задании, лежит огромная разница. То, что кажется специалистам безобидным отклонением от заданных параметров в свойствах проекта, на деле оказывается критическим с точки зрения бизнеса. Но ни у одной из сторон нет возможности понять позиции друг друга.

Проблема в том, что для бизнеса вопрос оценки и планирования проекта – это одно, а для специалистов – другое. Каждая сторона смотрит на согласование условий со своей точки зрения. Специалисты обычно не понимают, что бизнес интересует только решение его задачи, и все варианты рассматриваются с позиции окупаемости затрат. Бизнес тоже не учитывает, что любая оценка со стороны проектной команды – всего лишь гипотеза из-за неопределенности, о которой уже столько было сказано в этой книге.

Напомню, что существует две модели работы компаний, выполняющих проекты. Первая – торговля ресурсами, в данном случае рабочим временем специалистов, например программистов или дизайнеров. Это пресловутые человеко-часы, которые можно по-разному упаковывать. Вторая – продажа и применение уникальных знаний, значимость которых раскрывается применительно к конкретному заказчику. Их нельзя измерить с точки зрения затраченного времени исполнителя, поскольку это либо готовая методика или технология, либо креативные задачи.

Если известно, какие задачи нужно выполнить и какие для этого нужны ресурсы, а это, как правило, проекты типа «Процедуры» и «Седина», то работа по первой модели оправдана. Если же решение только предстоит найти, как в проектах типа «Мозги», нужна вторая модель. Изменение схемы работы компании с использованием цифровых инструментов или запуск нового направления – как раз такой случай. В них вы не сможете поставить задачу и организовать тендер, чтобы привлечь команду на конкурсной основе. Нужен тот, кто разговаривая с бизнесом на одном языке, найдет решение и переведет его в понятную специалистам форму.

В «Методе параноика» такую функцию выполняет проджект-раннер, и его роль состоит в запуске уникальных проектов. Он, как вытяжной парашют, тянет за собой все остальное. Проджект-раннер подобен «Психотерапевту», который ставит диагноз и организует процесс, привлекая при необходимости «Фармацевтов» (команды специалистов с типовыми компетенциями в разработке, дизайне и т. д.), «Сиделок» (маркетинговые и рекламные агентства) и «Нейрохирургов» (системные интеграторы, высококлассные профессионалы и уникальные креативные студии). Проджект-раннер знает модели ценообразования и понимает ограничения бизнеса и цели заказчика, он выбирает подходящих участников, опираясь на принцип гибких проектных команд. Происходит ли это через конкурсы или прямые договоренности с подрядчиками, не так важно. Главное, что проджект-раннер разделяет риски и несет ответственность за результат проекта. Он фокусируется на достижении целей бизнеса и добивается, чтобы итоговый продукт соответствовал заданным параметрам.

В отличие от обычных менеджеров, проджект-раннер знает, что при планировании проекта задачи не конвертируются напрямую в человеко-часы. Оценка со стороны исполнителей никогда не может быть достоверной, а таблица с функциями продукта и ожидаемыми трудозатратами – это плод фантазии. Важна только фактическая производительность конкретной команды. Ее замер на реальных задачах является обязательной процедурой и позволяет проджект-раннеру объективно оценивать возможности новой команды. Если они не укладываются в необходимые параметры, то ищется другая команда или меняется устройство продукта под возможности доступных специалистов.

Интересно, что когда я только собирал материалы для этой главы, то искал примеры того, как подобный подход используется в других индустриях. Я хотел показать, что продюсирование – неизбежная модель в современном мире, и был очень удивлен, когда наткнулся на рассказ о постройке самой крупной ракеты в истории человечества для полета на Луну[1]:

«Ракета обладала беспрецедентной сложностью. Стоял вопрос, кто будет ее строить. Фон Браун выбрал разделение труда. Это позволяло ему выбирать лучших из лучших во всей промышленности. Он мог задействовать самых опытных людей из каждой из компаний. Скорость разработки действительно получилась высокой. Для подрядчиков решение означало крупные заказы, а не огромный заказ для кого-то одного. В итоге основная доля распределялась между тремя компаниями: «Боинг», North American Aviation и «Дуглас». Они производили три ступени, из которых состоит «Сатурн-5»…

…За работой подрядчиков следили две группы в Космическом центре Маршалла. Отдел Research and Development Operations следил за целостностью структуры ракеты, а Industrial Operations перечислял денежные средства и принимал работу…»

Если такая схема сработала в 60-х годах прошлого века, то в современном мире это тем более возможно, и наш проектный опыт неоднократно это доказывал. Продюсерский подход дает необходимую гибкость и, подобно Фон Брауну, позволяет строить распределенные команды из самых классных специалистов. Опираясь на принципы проектирования и гибких проектных команд получается выстраивать коммуникации между участниками и управлять процессом создания продуктов. Учитывая, что сейчас многие профессионалы выбирают образ жизни цифровых кочевников, описанный подход становится единственно возможным ответом на вызов времени.

Как стать проджект-раннером

Я хочу завершить главу кратким напутствием тем, кто решит пойти по указанному пути и попробовать свои силы в продюсировании. Мой опыт общения с читателями первой версии книги показал, что большинство специалистов рано или поздно упираются в потолок профессионального роста. Кажется, что можно еще долго развиваться, прокачивать свои навыки, но с определенного уровня ограничением становятся не ваши личные способности, а сложности взаимодействия с другими участниками проекта. Сколь бы хорошо вы ни делали свою работу, если процесс построен так, что ваши коллеги не могут воспользоваться ее результатами, то качественный продукт создать не получится.

Изменение проектного процесса требует административных полномочий, и для многих это становится непреодолимым препятствием. С одной стороны, они не могут воплотить свои замыслы, а с другой – понимают, что переключение на управленческую карьеру лишит их радости творческого процесса, ради которого они выбрали свое занятие. Однако существует альтернативный путь, в котором можно работать по своим правилам, сохранить связь с профессиональными корнями и не потерять в масштабе и уникальности проектов. Этот путь избавляет от давления корпоративных ограничений, дает возможность сфокусироваться на интересных задачах и общении с компетентными специалистами. Так я вижу образ профессиональной жизни проджект-раннера.

Входным билетом в нее служит готовность выйти за границы своей привычной деятельности, поскольку проджект-раннер по определению должен обладать несколькими компетенциями. Становясь одним из ключевых участников, необходимо уметь искать решения на стыке разных дисциплин. Чем на более высоком уровне абстракции вы рассматриваете цифровой продукт, тем больше его аспектов попадает в ваше поле зрения. Начиная с определенного уровня, кроме технических задач, вам уже не избежать вовлеченности в решение вопросов организации проектной работы, а поднимаясь еще выше, вы будете захватывать уже и вопросы бизнеса. Это вовсе не означает, что вы станете чистым управленцем, тем не менее, дорога лежит через обретение навыков координации команды как части производственной технологии.

Главное препятствие на пути становления проджект-раннера – поменять отношение к ответственности за результаты своей деятельности. По сути, до тех пор, пока вы не возьмете на себя ответственность, вы так и будете оставаться просто специалистом, к мнению которого можно прислушаться, но необязательно брать в расчет. Понимание вашими коллегами и представителями бизнеса того, что вы готовы нести риски за принятые вами решения, кардинально меняет их отношение к вам и вашей точке зрения.

Конечно, вам не доверят сразу решение проектных вопросов на уровне бизнеса. Это последовательный процесс: сначала вы начинаете изменения в организации работы над своей частью продукта и постепенно расширяете сферу своих интересов. Ваша задача – получить достаточно полномочий, без которых невозможно преодолеть ограничения, возникающие при попытке исправить проблемы, пока вы занимаетесь своей локальной задачей дизайнера, проектировщика или архитектора. Таким образом вы сможете получить статус ключевого участника проекта и сразу начать оттачивать навыки, необходимые для работы над более комплексными задачами. Напомню, что «Метод параноика» рассматривает каждого ключевого участника как проджект-раннера, работающего на своем уровне.

Когда я говорю о постепенном расширении полномочий, то речь необязательно идет об одном и том же проекте. Чаще всего каждый следующий шаг на пути к самостоятельному продюсированию будет происходить в рамках разных проектных команд. Такая траектория развития даст вам представление об используемых подходах и познакомит с людьми в индустрии. Вы увидите, что общепринятые правила на самом деле лишь договоренности между участниками конкретных проектов. Так вы сможете понять, как формулировать и устанавливать свои правила игры.

Думаю, уже понятно, что нет такой профессии, как проджект-раннер, на которую можно было бы выучиться с нуля. В основе должен быть серьезный профессиональный бэкграунд в разных областях, и даже опытные мультидисциплинарные специалисты не могут сразу оказаться в его роли. Им требуется пройти долгий путь становления. И уж тем более нельзя стать проджект-раннером, опираясь только на управленческий опыт. Если у вас нет достаточных технических и бизнес-компетенций или навыков проектирования цифровых продуктов, вряд ли у вас получится организовать работу над проектами типа «Мозги». Любая попытка свести все к типовым процессам, где проджект-раннер выступает исключительно в роли администратора, потерпит неудачу.

На характер проектов, которые вы сможете продюсировать, влияет ваша базовая профессия. Любой проект, запускаемый выходцем из дизайнерской среды, будет нести отпечаток ее ценностей и подходов. То же относится и к остальным сферам – разработке, проектированию, менеджменту, маркетингу и так далее. Обратная сторона этого в том, что вы сможете установить крепкие партнерские отношения в проектах только с теми, кто разделяет ваши ценности. Особенно это относится к бизнесу, для которого маркером в том числе могут выступать ваши продуктовые концепты из «Кодекса проектировщика». Это одновременно и сила, и слабость продюсерского подхода: вы вряд ли сможете работать над проектами, которые вам не интересны, что сильно сужает выбор, но зато значительно повысите их качество и свою удовлетворенность.

Можно добавить еще несколько условий, которые нужно соблюсти, чтобы преуспеть в роли проджект-раннера. У вас должен сформироваться широкий круг профессиональных контактов. Знакомства со специалистами из разных сфер помогают собирать команды для работы над проектами. С этим связан еще один интересный аспект. Вы должны понимать культуру каждой среды и с уважением относиться к профессионализму специалистов. Еще одно требование – навыки и опыт организации проектной работы, что следует из всего текста главы. Я бы не стал указывать этот пункт, если бы не важное уточнение к нему. При работе над уникальными проектами приобретает особое значение умение проджект-раннера вести их в условиях высокой неопределенности, не теряя контроля и сохраняя способность прогнозировать параметры проекта и его результат. Собственно, этому и будет посвящена следующая глава.

Глава 9

Принцип сериала

Структура главы:

• Замкнутый круг прогнозирования

• Оценка проектов типа «Мозги»

• Решение уравнения от обратного

• Как принцип сериала берет под контроль неопределенность

• Организация проектов типа «Мозги»

• Фирменный проектный процесс

• Концепция продукта

• Высокоуровневое проектирование

• Детальное проектирование

• Разработка

Замкнутый круг прогнозирования

Существует известное противоречие между потребностью бизнеса знать заранее параметры проекта и невозможностью со стороны проектной команды их предсказать. Желание иметь на руках сроки и бюджет при принятии решения о запуске проекта вполне объяснимо. Любая компания работает в рамках бизнес-модели со своими границами временных и финансовых возможностей. Если на создание цифрового продукта придется потратить больше средств, чем получится с его помощью заработать, то вся затея теряет смысл. И было бы здорово это понимать до, а не после того, как бюджет потрачен, а продукт не появился.

Для специалистов ситуация складывается обратным образом. Им нужно предсказать стоимость и сроки еще до начала работ, когда информации минимум. Чтобы появилась хоть какая-то ясность, необходимо пройти определенный путь. Даже после предварительного анализа и проектирования оценка остается всего лишь прогнозом. Предсказать его статистически невозможно, в математике даже существует понятие «неразрешимости». Проектная работа – это последовательность решений, и пока нет ответа на один вопрос, неясно, какие будут следующие. Полная ясность наступает только к концу проекта.

Получается замкнутый круг. Бизнес не готов начинать работу без оценки, а специалисты не могут дать прогноз до начала проекта. Кто-то должен пойти на уступки, и поэтому предварительные переговоры между клиентом и исполнителями – это, по сути, попытка договориться, кто возьмет на себя ответственность за неопределенность. Усугубляет ситуацию то, что любая компания постоянно развивается, и работа над цифровым продуктом – это всегда стрельба по движущейся мишени. Даже идеально спланированный проект гарантировано не попадет в цель, так как она к его завершению сдвинется.

Гибкие методологии не сильно помогают решению этой проблемы. Как было сказано в предыдущих главах, современные подходы в большей степени ориентируются на то, чтобы избежать ответа на поставленный вопрос, сняв ответственность с участников проекта. Происходит это за счет того, что движение по проекту осуществляется короткими шагами, называемыми итерациями или спринтами. Прогнозирование сводится к определению того, какой объем задач будет реализован в ближайшем спринте. Но сколько спринтов необходимо для полной готовности продукта, по-прежнему предсказать нельзя. Законы природы не обманешь. Поэтому гибкие методологии по факту – это способ перекладывания рисков на бизнес, а традиционные – на проектные команды.

Проблема не всегда стоит так остро, и неопределенность зависит от точки цикла, в которой находится компания. Если идет процесс последовательного развития цифровых инструментов для уже реализованной бизнес-модели, то проекты типа «Процедуры» можно достаточно точно оценить, особенно на коротких дистанциях. Также предсказуема ситуация в проектах типа «Седина», когда запускается новый бизнес на основе заимствованной бизнес-модели и готовых цифровых инструментов. Если же владельцы компании выбирают путь инновационного развития, когда необходимо придумать новую бизнес-модель, то придется иметь дело с проектами типа «Мозги», где неопределенность может достигать максимального уровня.

«Метод параноика» как раз ориентирован на проекты с высокой степенью неопределенности, а значит, в арсенале проджект-раннера должны быть инструменты для работы в таких условиях. При создании нового бизнеса или его кардинальной перестройке владельцам хватает сложностей. Задача проектной команды не усугублять и без того непростую ситуацию, а наоборот, помочь бизнесу пройти путь с минимальными потерями. По аналогии с предыдущей главой, в которой проджект-раннер собирает все уровни проекта в виде «проектного бутерброда», здесь его требуется правильно нарезать на разные стадии.

«Нарезать» проект означает расставить в нем контрольные точки, через которые он проходит, и в которых все его части проходят проверку и соединяются вместе. Согласно принципу проектирования это нужно, чтобы не копить неопределенность, а периодически выкладывать карты на стол и убеждаться, что проект движется в нужную сторону. С учетом исследовательского характера проектов типа «Мозги» поиски решения могут зайти в тупик, и тогда лучше остановить работу, зафиксировав убытки. Чем раньше вы об этом узнаете, тем дешевле обойдется ошибка, поэтому без контрольных точек не обойтись. С другой стороны, слишком частые проверки не дадут команде достаточно пространства для творчества, без которого не бывает нестандартных решений.

Еще одним аспектом правильной «нарезки» проекта является распределение разных типов задач по стадиям. Тут все кажется очевидным. Например, в начале стоит выполнять высокоуровневые задачи, затем погружаться на более детальный уровень реализации продукта. Если же посмотреть на вопрос с точки зрения неопределенности, то критерием здесь должен быть не только уровень задач, но и степень их «рискоемкости». То есть насколько непредсказуемым может быть результат и как он затронет остальные задачи. Практика показывает, что можно сделать почти весь продукт, но так никогда его не выпустить из-за технической мелочи, от которой зависит успех проекта.

Оценка проектов типа «Мозги»

Все, что я описал, нужно, чтобы сделать работу над цифровым продуктом более предсказуемой, но эти меры все равно не позволяют заранее ответить на вопросы о стоимости и сроках. И это неудивительно, ведь в проектах типа «Мозги» вопрос стоит иначе – получится ли в принципе достичь цели, а заодно как в случае провала не потерять больше, чем может себе позволить бизнес, и как увеличить шансы на успех. Для проектов такого типа нужна другая стратегия прогнозирования.

В проектах типа «Седина» поиск решений уже выполнен, и задача – применить их в конкретной ситуации. Непредсказуемая часть вынесена за скобки проекта. Похожим образом складывается ситуация в «Процедурах», где масштаб и сложность задач низкие, что ограничивает количество возможных решений. В случае же с типом «Мозги» поиск решений является основным содержанием, и пока не найдены все ответы, нельзя достоверно назвать параметры.

Получается, что в проектах с высоким уровнем неопределенности есть обратная зависимость между точностью оценки и тем, как рано мы можем ее получить. В самом начале предсказать параметры проекта практически невозможно, а к его завершению мы будем знать их со стопроцентной точностью, но уже не как прогноз, а как факт. После начала проекта мы каждый день расходуем бюджет и постепенно увеличиваем точность прогнозирования оставшейся части проекта. Возможно, есть цена, за которую можно получить приемлемый уровень точности оценки всего проекта. Если это так, то со стороны бизнеса следующий вопрос будет более уместным: «Сколько нужно заплатить, чтобы узнать общую стоимость проекта?»

Можно ли узнать эту цену? Существуют разные форматы участия специалистов в проекте, о которых я писал во второй главе: «Фармацевты», «Сиделки», «Нейрохирурги» и «Психотерапевты». Для первых двух форматов задачи часто типовые, и их стоимость будет равняться произведению цены за условную единицу работы и количества таких единиц. Например, дизайнеры интерфейсов обычно назначают усредненную стоимость за одну форму мобильного приложения или сайта. Если вы знаете, сколько таких форм будет в вашем продукте, то легко подсчитать общую стоимость. Но чтобы узнать, сколько форм потребуется нарисовать, необходимо выполнить исследовательскую работу. И это как раз и есть та самая цена, которую придется заплатить, чтобы понять общую стоимость проекта.

Однако исследовательские задачи, выполняемые «Нейрохирургами» и «Психотерапевтами», такие как разработка принципиальной схемы решения и концепции продукта, могут быть непредсказуемыми по времени и носить эвристический характер. Иногда ответ может быть найден за несколько дней, а порой на его поиск уходят недели и месяцы. Сложнее обстоит дело с креативными задачами, в которых все зависит от личного вдохновения человека. К расчету стоимости исследовательских задач можно подходить по-разному, в зависимости от конкретной ситуации.

Первым вариантом, который лучше всего работает с креативными задачами, является фиксированная цена за готовый результат. Она не меняется, даже если задача выполняется быстрее. При работе над такими задачами сложно говорить об объеме затраченного времени. Ответ может прийти в любой момент дня и ночи, а разделение времени на рабочее и нерабочее не соответствует действительности. Оценка таких задач должна быть равна сумме, за которую человеку будет интересно их выполнить. Если он будет отвлекаться на что-то другое, то не сможет полностью посвятить себя поиску решения.

Вторым вариантом оценки исследовательских задач служит обратный подход, когда работа специалистов оплачивается по затраченному времени. Например, необходимо проанализировать данные бизнеса, и на их основе сформулировать решение задачи. Сюда же относятся задачи по проведению экспериментов для проверки различных гипотез, как это бывает в случае выхода компании на новый рынок или использования еще не апробированных технологий. Точное время получения необходимого результата предсказать нельзя, поскольку ответы на одни гипотезы ведут к новым. Единственное, как бизнес может себя защитить, – это установить границы времени и бюджета, при достижении которых продолжение поиска решения считается нецелесообразным.

Третий вариант, мой самый любимый, с которым связано больше всего споров в профессиональной среде, основывается на значении цифрового продукта для бизнеса. Существуют решения, которые дают пропорциональный эффект для компаний разных размеров. Например, для компании с оборотом в миллион долларов эффект равен ста тысячам, а для десяти миллионов – в десять раз больше. В таком случае цена исследовательских задач может быть связана с абсолютным значением их влияния на бизнес. Данный подход перекликается с концепцией вовлеченности проджект-раннера, когда его вознаграждение напрямую зависит от коммерческих показателей компании. Это может быть роялти с продаж, процент от прибыли или части суммы, на которую уменьшились издержки. И конечно здесь учитывается вклад не только проджект-раннера, но и других специалистов, вовлеченных в поиск решения.

Казалось бы, вот ответ на вопрос об оценке. Необходимо начать проект с исследовательских задач, что позволит спрогнозировать оставшуюся часть. Такой подход работает до тех пор, пока соотношение между типовыми и исследовательскими задачами не перевешивает в сторону последних. Тогда проект может превратиться в один сплошной слабо прогнозируемый креатив и поиск решений. Альтернативным, но, возможно, худшим сценарием может быть ситуация, при которой исследовательские задачи не сконцентрированы в начале, а разбросаны по проекту. В таких случаях сложно что-либо прогнозировать в принципе. Участники проектной команды становятся похожи на людей, идущих по минному полю. Они не знают, какая задача может стать последней в жизни проекта.

Решение уравнения от обратного

Что, если подойти к прогнозированию с другой стороны? Раз цифровой продукт – инструмент для бизнес-модели компании, то искомые параметры проекта по его созданию известны заранее. Их содержит сама модель в виде требований к частям, из которых состоит сложная система. Применительно к цифровым продуктам это означает все те же бюджет и сроки, в границах которых их создание имеет смысл. Например, при запуске нового направления компания ожидает получить доход, рассчитанный путем анализа рынка. Если расходы превысят определенный порог, модель станет нерентабельной. Таким образом можно предположить границы бюджета создания технической инфраструктуры, которая будет обеспечивать продажи, и сроки ее создания.

Для ясности проиллюстрирую эту идею. Допустим, компания шьет одежду на заказ. Ее точки продажи и мастерские находятся в крупных городах мира, где живут состоятельные клиенты. Обычно они приезжают в ателье для снятия мерок, а потом для окончательной подгонки. Но из-за пандемии меняется привычный уклад, и компания решает запустить выездные продажи, когда мастер сам приезжает к клиенту. Вместе с этим становится понятно, что благодаря новой бизнес-модели можно расширить клиентскую базу, выйдя за границы нескольких точек присутствия. Чтобы это сделать, необходимы соответствующие инструменты: мобильные приложения для внесения мерок мастерами, отслеживания заказов и оформления доставки, а также внутренняя система для учета заказов на производстве.

История лишается смысла, если компания потратит на создание цифровых инструментов больше средств, чем сможет заработать в рамках новой бизнес-модели. При этом надо учитывать не только расходы на технологические части модели, но и затраты на кадры, рекламу, производственные помещения, логистику и прочее. Сложив все вместе и рассчитав возможный объем продаж, регулярные расходы на материалы, зарплату и логистику, получается прибыль за период, в течение которого новая модель сможет работать без сильного давления конкурентов. Из этой будущей прибыли и формируются границы бюджета на создание цифрового продукта. Конечно, это пограничные значения и итоговая цифра будет меньше, исходя из мнения владельцев о возможных рисках и размере дивидендов, на которые они рассчитывают.

Важно отметить, что расходы на подобные трансформации – это всегда инвестиции, а не обычные расходы компании, которая работает по старой модели. Поэтому рассчитывать границы бюджета проекта, отталкиваясь от существующих показателей компании, некорректно. Да, источником инвестиций частично может быть текущая прибыль, но если мы говорим не о действующих компаниях, а о стартапах, то здесь просто нет вариантов, кроме как привлекать внешние источники финансирования.

В дополнение к ограничениям бюджета существуют также и временные факторы. В случае с продажей одежды это может быть сезонность. Если изменения задумываются весной, владельцы компании могут посчитать, что запустить новую схему работы необходимо к предновогодним распродажам. Так появляется общее ограничение по срокам проекта, которое может иметь и более детальную структуру, основанную на логике проверки рыночных гипотез и внутренних процессов компании. В данном случае владельцы могут захотеть протестировать спрос на услуги в онлайне, запустив урезанную версию сайта или мобильного приложения до того, как изменения в компании станут необратимыми.

Этот пример показывает, что начинать планирование проектов с вопросов к потенциальным исполнителям о стоимости и сроках бессмысленно. Какая, собственно, разница? Когда бизнес-модель диктует возможные параметры проекта, важно, как структурировать проект внутри, чтобы в итоге он уложился в заданные рамки.

Такая постановка не отменяет того факта, что на старте проекта мы по-прежнему находимся в состоянии неопределенности. Как уже было сказано, потребуется выполнить исследовательскую работу, чтобы внести ясность. У нее есть своя цена, и вопрос теперь должен звучать так: «Сколько нужно заплатить, чтобы узнать, как за доступный бюджет и срок получить нужный результат?» Уметь ответить на этот вопрос – жизненно важный навык для проджект-раннера, который берет на себя ответственность за результат в условиях высокой неопределенности.

Как принцип сериала берет под контроль неопределенность

Даже если проджект-раннер способен удержать проект в заданных рамках, достигая поставленных бизнесом целей, это закрывает только один источник неопределенности – внутренний. Второй источник – внешний – вытекает из того, что рыночная ситуация на момент старта проекта всегда будет отличаться от той, в которой тот окажется к моменту завершения. Любая компания пребывает в постоянной трансформации и должна адаптироваться к изменениям внешней среды. Вместе с ней должны меняться и инструменты, в том числе цифровые, на которые она опирается. Если цели проекта изменятся до его завершения, то как бы хорошо он ни был выполнен, результат не совпадет с новыми потребностями бизнеса. Как если бы мы задумали снять масштабное кино с большим бюджетом и длительным сроком производства, но к моменту окончания съемок выяснили, что тема перестала быть актуальной для аудитории. Два возможных варианта развития событий одинаково неутешительны. В первом случае работы останавливаются, и затраченные средства списываются в убытки. Во втором случае команда пытается переделать уже готовый продукт, что требует дополнительных расходов и ухудшает качество и целостность результата.

Но что, если бы мы изменили подход и представили всю историю в виде серии эпизодов? В таком случае мы бы оказались в более выгодном положении. Каждый эпизод основывался на общем сценарном пространстве, но развивал исходную идею. При желании мы могли бы менять сюжет, добавлять новых персонажей или раскрывать существующих с неожиданной стороны. Меняющиеся предпочтения аудитории не выбивали бы нас из колеи, а наоборот, были источником вдохновения. И, что самое важное, успех проекта не зависел бы от нашей способности угадывать будущее еще до того, как мы начнем что-то делать.

Таким же образом можно решать проблему с меняющимися целями при создании цифровых продуктов. Вместо попыток предсказать потребности бизнеса через год, лучше корректировать направление развития продукта вместе с изменениями курса компании. Вместо выпуска полной версии, которая сразу закроет все потребности новой бизнес-модели, стоит развивать видение продукта в форме серии небольших релизов. Каждый из них, как новый эпизод, рассказывает свою историю – в данном случае пользовательскую. Такой подход создает ситуацию, когда неопределенность меняющихся целей бизнеса перестает быть угрозой для проекта, а становится желанным пространством возможностей. В этом и заключается ключевая идея принципа сериала «Метода параноика».

Действуя подобным образом, мы получаем сразу несколько преимуществ. Во-первых, благодаря периодическим обновлениям онлайн-сервисов компании, клиенты будут ощущать ее жизненную энергию, видеть, что она развивается, учитывает их потребности и предлагает что-то новое. Это лучшая форма маркетинга, ведь в современном мире точка контакта между потребителем и бизнесом – это сеть, где люди ищут информацию, оформляют свои заказы на товары и услуги.

Во-вторых, развитие цифрового продукта через серию версий позволяет бизнесу и проектной команде более естественно подойти к проектированию и проверке гипотез. Об этом говорит все тот же закон Галла: «Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде. Из-за неизвестности вы никогда не сможете предсказать все связи и переменные, а следовательно, будете постоянно сталкиваться с различными проблемами».

Что интересно, описанный эффект относится не только к цифровому продукту. Компании, как сложной системе, также необходимо пройти путь постепенной трансформации от простого к сложному. Если попытаться сразу запустить все процессы по новой схеме, к этому не будут готовы ни сотрудники, ни менеджмент, ни контрагенты. То есть компания, сразу получив полную версию продукта, не сможет им воспользоваться. Нужны время и череда итераций, чтобы привести все составляющие бизнеса в соответствие с новыми правилами и сценариями. Владельцам и проектной команде нужно время, чтобы увидеть последствия этих изменений и на их основе делать следующие шаги.

У дробления продукта на множество версий есть и отрицательные стороны. Сложно установить границы проекта и спрогнозировать бюджет и сроки. Непонятно, где они проходят и проходят ли вообще? Каждая новая версия вроде бы приближает нас к желаемому результату, но как понять, что пора остановиться? Если вместе с продуктом каждый раз обновляется и цель проекта, то можно попасть в замкнутый круг. Единственным ориентиром служит схема жизненного цикла компании, в которой проекты типа «Мозги» или «Седина» сменяются «Процедурами». Когда проект переходит в фазу регулярного поступательного развития сложившегося продукта, значит мы достигли первоначально обозначенных границ.

Кстати, именно непонимание необходимости отслеживания общих границ проекта – это то, чем грешат многие приверженцы современных гибких методологий. Бизнес нельзя мерить только операционными показателями, для расчета нужны цифры за весь жизненный период. То, что в моменте прибыль компании перекрывает расходы на развитие, не означает, что на более длительном временном отрезке не будет убытков. Проектная работа, как часть внутренней активности компании по ее развитию, подчиняется тем же законам.

Это касается не только бюджета. Гибкие методологии не дают карт-бланш на работу над продуктом в режиме «здесь и сейчас», потому что проект – это всегда способ для бизнеса попасть из точки А в точку Б. У него есть допустимая цена и время, за которое необходимо пройти путь. Если за выбором следующего шага в проекте не стоит понимание конечной цели, то это похоже на езду в автомобиле, когда водитель произвольно крутит руль влево-вправо и не следит за дорогой. Гибкие методологии прежде всего должны давать тактическую свободу, но стратегически необходимо понимать, куда двигаться.

В таком акценте на целостность проявляется особенность принципа. Согласно ему, все версии продукта, подобно эпизодам сериала, рассматриваются не как несвязанные между собой истории, а как части общей картины. В начале задаются правила игры, своеобразные законы вселенной проекта или общее сценарное пространство, в котором действуют герои, и дальше, от эпизода к эпизоду, события разворачиваются, следуя общей логике. И точно так же, подобно сериалу, продукт выстраивается внутри общего архитектурного пространства на всех уровнях: бизнес-уровне, функциональном, интерфейсном, техническом и организационном.

На организационном уровне целостность выражается в том, что интересы и ответственность проектной команды не ограничиваются только одной версией, а охватывают весь цифровой продукт. Участники принимают решения, которые дают преимущества не в рамках локальной задачи, а учитывают общие цели проекта. Похожим образом этот эффект проявляется при формировании самих команд. Часто выгоднее привлечь к проектированию или разработке архитектурных компонентов более опытных, но дорогих специалистов, и за счет этого сэкономить в масштабах всего проекта.

На функциональном, интерфейсном и техническом уровнях целостность проявляется в создании архитектуры и общих правил, унифицирующих добавление новых функций в продукт. Свойством хорошо спроектированной архитектуры, технической или интерфейсной, является достаточная гибкость, при которой не нужно перерабатывать систему целиком, чтобы внести очередные изменения. Это частая проблема, когда доработки делаются в отрыве друг от друга и в проекте накапливается технический долг. Здесь же удается этого избежать, потому что истинная гибкость, о которой так много говорят, опирается, прежде всего, на гибкость конструкции в основе цифрового сервиса.

На уровне бизнеса целостность проекта дает владельцам уверенность, что создаваемый продукт комплексно решает задачи компании, а не просто закрывает отдельные фрагменты бизнес-модели. Это позволяет отказаться от ручного управления, что в проектах типа «Мозги» и невозможно, поскольку они состоят в основном из поиска решений. Стиль управления в таких проектах заключается не в директивном назначении задач, а в создании пространства возможностей, соответствующего образу будущего продукта. Участники проектной команды сами наполнят это пространство найденными решениями в заданных границах.

Если суммировать сказанное, то принцип сериала отвечает на вопрос: «Как подойти к оценке нетиповых проектов и организовать работу в условиях высокой внешней неопределенности со стороны бизнеса?» Следующие части главы описывают, как структурировать работу, сделать первые исследовательские шаги, сформировать пространство, в котором будет развиваться продукт, и как затем перейти к воплощению замысла. Также дается понимание, как проджект-раннер должен подойти к организации проектной команды и прогнозированию работ на каждой стадии.

Организация проектов типа «Мозги»

Напомню, что в отличие от типов «Седина» и «Процедуры», в проектах типа «Мозги» цель не в реализации уже апробированных подходов и технологий, а в нахождении решений для новых нестандартных задач. Это может относиться и к техническим вопросам, и к вопросам бизнеса, но чаще всего и к тем, и к другим. Все потому, что интересные решения обычно рождаются на пересечении разных дисциплин. Примеров много: от бизнес-моделей, построенных на новых технологических инструментах, до экспериментов с новыми сочетаниями сценариев поведения пользователей и цифровых продуктов. Такие проекты отличаются высоким уровнем неопределенности, и в них не работают стандартные методы управления.

Давайте посмотрим, какие инструменты предлагает «Метод параноика» для организации проектов типа «Мозги». Во-первых, контрольные точки, которые позволяют структурировать процесс и внести фактор предсказуемости. Во-вторых, гибкие проектные команды и продюсерский подход к их управлению. Для нетиповых задач нужно собирать уникальную группу специалистов и обновлять ее по мере развития проекта. В-третьих, модель продукта как совокупность всех принятых командой решений. Она позволяет «видеть» цифровой продукт во всей его полноте и одновременно является средой коммуникаций между участниками. Дальше я покажу работу каждого инструмента и их сочетание.

Классические подходы к управлению, использующие такие инструменты, как план проекта, критический путь, диаграмма Ганта, опираются на идею о предсказуемости работы над проектом. В этом нет ничего удивительного, ведь они создавались в индустриальный период, когда основной фокус был на максимально эффективном выполнении заранее продуманного решения. Соотношение объема исследований и дальнейшего воплощения было в пользу последнего. Например, при проектировании моста вы должны были получить технологию его строительства. Создание сложной конструкции разбивалось на множество мелких технологических операций и имел значение порядок их выполнения. От этого зависела логистика поставок строительных материалов, привлечение людских ресурсов, и, конечно, на это влияли физические ограничения, не позволяющие собрать сложную конструкцию в произвольном порядке.

В мире реальных вещей важна стоимость их производства, а в индустриальный период все продукты были физическими, от одежды до транспортных средств. Представляете огромные ангары, в которых строятся самолеты? Проектирование могло быть дорогим, но производство еще дороже. Поэтому была важна эффективность сборочного процесса. Если добавить к этому экономию на объеме, то производство одинаковых продуктов в большом количестве было более предпочтительным. Неудивительно, что предсказуемость операций, составляющих технологию производства, стала синонимом успеха, и на ее достижение были направлены все усилия. Вспоминаются Дао Тойоты и бережливое производство (Lean), теория ограничений (TOC) моего любимого Голдратта, и Канбан.

В мире, где множество продуктов стали цифровыми, а производство физических объектов сильно удешевилось, ситуация поменялась. Теперь выигрывает тот, кто первым придумывает новую технологию, а не тот, кто может ее многократно повторить с меньшими издержками. Да, мы все еще строим мосты, производим корабли, машины и самолеты, но кроме них в мире появилось то, чего раньше не было. Я говорю о бизнес-моделях, которые могут существовать только благодаря цифровым технологиям и быстрым коммуникациям людей между собой и с онлайн-сервисами компаний. При их создании ценен факт того, что вы первым открываете новый рынок. В этом случае время важнее стоимости. Это условия, в которых проявляются сильные стороны проектов типа «Мозги».

В таких проектах акцент смещается с задач реализации на поиск решений. Имеет ли определяющее значение то, как эффективно вы сможете разработать продукт, если неизвестно, каким он должен быть? Нет. Это важная, но второстепенная задача. Первостепенным является акт творчества, придумывания того, чего еще не было. Креативные и исследовательские задачи предполагают свободу действий тех, кто ими занимается. Здесь не работают прямые указания, чек-листы и формальные процедуры. Вы не можете ни приказать, ни уговорить людей быть более изобретательными. Единственное, что можно сделать, – это найти наиболее талантливых и увлечь их интересной задачей.

Контрольные точки проекта

Звучит замечательно, но, если вы предоставляете команде свободу действий, вас точно будет интересовать, как сделать так, чтобы эта свобода не работала против вас. Как понять, что время и усилия не уходят впустую или не тратятся на задачи, ведущие проект по ложному пути? Общий подход к творческим задачам заключается в том, чтобы обозначить цели, задать критерии их достижения, заинтересовать людей, дать им свободу и поставить в ситуацию «шкура на кону», когда от их действий зависит их успех. Моментом проверки служит контрольная точка проекта.

Вы регламентируете не саму задачу, а условия, при которых можно считать, что она выполнена. Такой подход основывается на идее «как ты будешь оценивать меня, так я буду себя вести». Соответственно, меняя критерии оценки, мы можем влиять на то, что происходит в рамках стадии проекта, предшествующей контрольной точке. Поскольку весь проект представляет собой последовательность стадий, меняя критерии оценки в каждой из точек, можно направлять проект в нужную сторону.

Такое управление происходит за счет того, что в зависимости от критериев оценки меняется характер работ в рамках конкретной стадии. Для прохождения контрольной точки участники проекта должны использовать подход, соответствующий заданным критериям. При этом критерии могут быть разными, позволяют тонко настраивать процесс и направлять команду. В одних случаях это функциональные или технические требования к компонентам разрабатываемой системы, в других – качественные характеристики результата, например, образ или настроение, который должен вызвать дизайн. Также есть бюджетные и организационные рамки. Все это вместе создает ограничения, о которых говорилось в главе о продюсировании.

Время тоже выступает в качестве одного из параметров настройки работы. Каждая стадия должна иметь индивидуальную длительность, чтобы у команды было достаточно времени для поиска решений, но при этом, поиск не должен зайти слишком далеко по ложному пути. Конечно, существуют подходы, когда длительность итераций в проекте устанавливается одинаковой, но на практике такого никогда не происходит. Разные задачи требуют соответствующих условий для их выполнения.

Четких правил для определения критериев оценки контрольных точек не существует – это творческий процесс, как и все в проектах типа «Мозги». В зависимости от выбранной стратегии можно по-разному подходить к набору стадий. В последней части главы я покажу пример структурирования проекта по принципу сериала. Но нужно помнить, что план – это всегда гипотеза, как и все остальное в проекте. За очередной контрольной точкой открывается новый вид на территорию, и проджект-раннеру вместе с проектной командой необходимо все время пересматривать маршрут.

Есть только одно важное условие, которое необходимо соблюдать – не ставить противоречивых или несвязанных между собой целей для каждой из стадий, иначе это собьет команду с толку. Напротив, ясные критерии оценки результатов дают возможность настроить работу единым образом. От стадии к стадии они могут отличаться, но должны быть одинаковыми для всех задач внутри одного этапа проекта. Так получится избежать смешивания разных подходов, ведь от характера работы зависит множество аспектов: способ планирования и оценки, уровень неопределенности, желательная длительность стадии, требования к участникам проектной команды и методы управления.

Гибкие проектные команды и продюсерский подход

Из предыдущего абзаца логично следует, что гибкие команды – неотъемлемая часть проектов типа «Мозги». Если на разных стадиях проекта к его участникам предъявляются индивидуальные требования в соответствии с меняющимися задачами, то состав команды должен регулярно обновляться. Применительно к принципу сериала это означает, что участники меняются в зависимости от версии, которая готовится к выпуску. Это похоже на работу над настоящим сериалом, когда для съемок отдельных эпизодов привлекаются разные специалисты и актеры.

Но есть участники, все время участвующие в работе, – исполнители главных ролей, оператор, режиссер и костяк съемочной бригады. То, что в принципе гибких команд называется «несущей конструкцией проекта». В случае работы над цифровым продуктом это прежде всего проджект-раннер и те, кто отвечает за основные части системы. Они поддерживают культуру проекта и являются носителями его изначальных целей.

Будьте внимательны, проджект-раннер – не босс и не менеджер, а такой же участник творческого процесса. Он смотрит на весь проект целиком и настраивает работу остальных участников, но не «командует» ими, а направляет и создает условия, при которых они могут проявить свои лучшие качества. Его сила в том, что он ясно представляет образ конечного продукта и помогает его увидеть остальным участникам.

В гибких проектных командах нет выделенных менеджеров. Управление, в отличие от администрирования, составная часть технологического процесса: важно, в каком порядке выполняются задачи и как их результаты стыкуются. Менять план действий в зависимости от реального состояния дел с учетом технологических зависимостей невозможно без глубокого понимания устройства продукта и технологии его создания.

Это означает, что специалисты в исследовательских и креативных командах не могут быть «подчиненными» по отношению к менеджерам, они сами принимают решения, каждый на своем уровне абстракции, компетенции и ответственности. Управление предполагает наличие компетенций, что обязывает условных менеджеров быть самим специалистами.

По этой же причине в гибких командах нет обычных для проектов UX-дизайнеров, IT-архитекторов, тестировщиков, программистов и аналитиков. Фактически это список компетенций, а не ролей, но в современной проектной работе между ними принято ставить знак равенства. В продюсерском подходе набор ролей в проектной команде не определен заранее, как это происходит в классических методиках, и что более интересно – сами роли не связаны с какой-то одной профессиональной специализацией.

Вместо функциональных ролей в «Методе параноика» структуру гибкой проектной команды составляют ключевые участники. Их состав зависит от проекта, а компетенции и зона ответственности каждого связаны с моделью создаваемого продукта. Получается, проджект-раннер и остальные ключевые участники по определению должны быть мультидисциплинарными специалистами. По мере погружения на более детальный уровень специалисты должны становиться все более специализированными в отдельных компетенциях.

Модель продукта

«Я много планирую “до”. Каждый кадр должен быть продуман заранее. Я встаю в 4 утра, смотрю, что там по графику, раскадровку, еще раз все проверяю. Свет, мизансцена, все возможные варианты, что может пойти не так и что должно произойти на площадке. В конце концов выбираю один наилучший вариант. Всегда готовлюсь по максимуму. Всегда худею килограммов на десять на каждой картине. Это как гонка на выносливость. Я не люблю приходить на площадку и начинать “творить”. Этим мы занимаемся на репетициях, но, когда ты полностью готов и вдруг приходит новая идея на площадке, это легко воплотить, потому что все остальное спланировано и готово…

… Ставки для меня очень высоки каждый раз, когда я выхожу на съемочную площадку. Вы понимаете, я же ставлю жизнь, карьеру, достоинство. Мои коллеги, которые утверждают, что не чувствуют давления, они врут! Господи, я только спустя пять лет перестал блевать на площадке в первый съемочный день!»

Это цитата Сэма Пекинпа, легендарного американского кинорежиссера. Он говорит об одном из важнейших аспектов технологии, которая позволяет связать творчество со сложным процессом производства фильма. Количество деталей, которые необходимо учесть, столь велико, что обойтись без тщательной подготовки просто невозможно. В случае с цифровыми продуктами ее функцию выполняет проектирование. Его результаты складываются в модель продукта, выраженную в документации и проектных артефактах.

Модель продукта – своеобразный интеллектуальный актив команды, выполняющий одновременно роль памяти и средства коммуникаций между участниками. Без нее не получится построить слаженную работу большого количества специалистов. Каждое решение должно быть отслежено и связано с остальными. Модель продукта служит структурой, позволяющей хранить эти решения организованным образом. Это позволяет любому участнику увидеть образ продукта так, как его видят остальные члены команды.

Только не стоит относиться к модели продукта как к чему-то, что готовят одни специалисты, например проектировщики, а исполняют другие – те же разработчики. Свой вклад вносят все участники проекта, но их активность меняется в зависимости от стадии. Модель развивается в течение всего проекта, и работа над очередной версией продукта дополняет ее новыми деталями.

Фирменный проектный процесс

Любой, кто опирается на принципы метода может по-своему интерпретировать их для работы над своими задачами. В момент написания книги я имел возможность увидеть, как читатели уже опубликованных глав смогли применить описанные в них идеи, даже не находясь в роли проджект-раннера, а проекты, в которых они участвовали, имели типы «Седина» и «Процедуры». Но важно помнить, что «Метод параноика» максимально раскрывает свой потенциал в проектах, где нужно найти уникальные решения и где неопределенность достигает максимального уровня.

В последней части главы я покажу, как соединяются идеи организации работы над проектами типа «Мозги» и принцип сериала. Для этого я использую эталонный процесс, который мы с коллегами оттачивали на множестве проектов и который помог нам создать несколько по-настоящему интересных продуктов. Это можно назвать нашим фирменным блюдом. Дальше я покажу рецепт и расскажу, как его приготовить.

Как уже было сказано, определение работающего набора контрольных точек – сложная задача, которая зависит от множества факторов. С точки зрения неопределенности желательно, чтобы проект начинался с исследовательских задач и постепенно переходил к более процедурным. Необходимо добиваться, чтобы проект с каждым шагом становился все более предсказуемым. Вначале будут видны только общие контуры возможного решения, но постепенно модель продукта и его реальное воплощение будут приобретать более ясные очертания.

Одновременно по мере уменьшения неопределенности должен меняться стиль управления и сам состав проектной команды. На первых этапах от участников требуется ничем не ограниченная фантазия, помноженная на широкий профессиональный кругозор. В дальнейшем их задача – наиболее эффективно и качественно реализовывать те или иные компоненты создаваемой системы в рамках заданных параметров. Логично, что такой вектор будет связан с разными целями стадий проекта и критериями для прохождения контрольных точек.

С изменением характера работы должен меняться и способ оценки для каждой стадии. И бизнес, и компании-подрядчики привыкли выбирать один вариант для всего проекта, отталкиваясь, например, от стоимости часа работы специалиста. Но это в корне неверно! Подход к прогнозированию бюджета и сроков различается в зависимости от типа задач: креативных или четко регламентированных. Степень их предсказуемости разная: в одном случае объем работ можно легко спрогнозировать, а в другом – нет. Это еще раз показывает, почему в рамках одной стадии проекта есть смысл группировать задачи сходного типа, ведь в противном случае вы не сможете извлечь выгоду из предсказуемости или, наоборот, локализовать неопределенность.

Проект как выпуск эпизодов сериала

Теперь свяжем все это с принципом сериала, направленным на развитие продукта вместе с адаптацией бизнеса под изменения внешней среды. В отличие от традиционных гибких подходов, этот метод рассматривает проект не как череду не связанных между собой итераций, в которые произвольным образом попадают задачи из-за сиюминутных желаний бизнеса, а как целенаправленное движение. Движение, совершаемое, конечно же, не за один шаг, а через серию эпизодов или версий продукта, которые дополняют друг друга и создают общую историю.

Чтобы история получилась связной, а подготовка каждой версии не требовала избыточных усилий, на уровне системы должны быть установлены общие правила, по которым пойдет развитие. Так действуют сценаристы: им не нужно для каждого эпизода с нуля придумывать среду и населять ее новыми жителями. Однажды прописав законы воображаемого мира и определив характеры главных героев, им не приходится думать о каждой реплике или каждом поступке персонажа. За счет точно установленных ограничений события будут развиваться в нужную авторам сторону, но гибко и по своей логике.

В случае с созданием цифровых продуктов это означает, что при разработке новой версии команда не тратит время на новый дизайн, способ организации пользовательских сценариев или на подход к технической реализации, а опирается на принципы, общие для всей системы. Архитектура становится не просто схемой, в которой компоненты связываются между собой, а правилами добавления новых функций на всех уровнях: техническом, интерфейсном и функциональном. Затратив ресурсы на ее создание в начале проекта, мы можем добиться серьезной экономии на последующих стадиях при выпуске новых версий. И чем лучше она будет проработана, тем больше шансов, что такой подход сработает.

Возможна ли такая унификация в проектах типа «Мозги», где результат на момент старта непредсказуем? Да, но для этого нужно уменьшить неопределенность до приемлемого уровня. Задача в том, чтобы увидеть точку Б, в которой хочет оказаться бизнес по итогу проекта. Поэтому сначала мы выясняем принципиальную возможность решения задачи (разработка концепции продукта), затем создаем пространство для воплощения функций цифрового продукта (высокоуровневое проектирование), и после этого переходим к последовательному движению к обозначенной цели через серию версий продукта («ран»: детальное проектирование и разработка).

Первые две стадии проектного процесса относятся к цифровому продукту в целом, а третья и четвертая представляют собой неразрывную пару, которая называется «ран», и может повторяться множество раз, результатом которой является отдельная версия продукта. Таким образом детальное проектирование и разработка представляют собой короткий цикл проекта. Здесь проявляется связь названия проджект-раннер и пути, по которому он двигает проект через последовательность «ранов».

Помимо короткого цикла существует большой цикл, который запускается, если при работе над релизами исчерпываются возможности, заложенные на уровне архитектуры. Это может произойти на любом из уровней системы – функциональном, интерфейсном или техническом. В этом случае начинается новая стадия высокоуровневого проектирования, цель которой – переосмыслить архитектуру с учетом новых требований и расширить пространство для развития продукта.

Если меняются цели, вытекающие из бизнес-модели компании, то это, по сути, приводит к запуску нового проекта, т. к. должна быть пересмотрена принципиальная схема решения, заложенная в концепции продукта. При таком сценарии проектная команда конечно же должна будет учитывать предшествующий опыт и с большой вероятностью базироваться на существующем продукте. Однако изменение целей может быть столь радикально, что использование текущих наработок будет невозможно и потребует создания системы с нуля. Это подробно описано в примерах третьей главы, где компания проходит цикл своего развития через череду проектов типа «Мозги», «Седина» и «Процедуры».

Концепция продукта

Цель стадии и характер работ

Хочу в очередной раз повторить свою любимую китайскую мудрость о том, что «перед тем как взбираться по лестнице, убедитесь, что приставили ее к нужной стене». Большинство ИТ-проектов начинается с прямого запроса со стороны бизнеса в стиле «нужно разработать мобильное приложение для нашего сервиса». Работа над такими проектами – это уважаемая профессия, но она, к сожалению, не отвечает на вопрос, поставленный китайцами много тысяч лет назад. Для задач, которые выполняются в рамках уже найденного решения, это нормально, ведь вы не спрашиваете себя, туда ли вы идете, делая очередной шаг. Но когда вы находитесь только в начале пути или стоите на перекрестке, вопрос вполне уместен и даже неизбежен.

Именно так все и выглядит при запуске новой компании или ее трансформации. Цифровые продукты – это просто инструменты, обеспечивающие работу бизнес-модели, поэтому первым вопросом должно быть: «В чем заключается бизнес-модель и какова принципиальная схема технологического решения, которая ее поддерживает?» Может выясниться, что не нужно ни мобильное приложение, ни онлайн-сервис, а лучше использовать личные встречи с клиентами или обойтись представительством компании в соцсети. Можно сэкономить кучу средств, еще даже не начав проект.

Но если цифровой инструмент все-таки нужен, то какой именно и каковы шансы создать его с учетом возможностей бизнеса и технологических ограничений? На этот вопрос отвечает концепция продукта. Это первый шаг, когда интуитивное видение владельца компании переходит в конкретную схему того, как все будет устроено. Цель – выбрать один из возможных вариантов и уменьшить неопределенность. Ведь даже определив конечную точку, невозможно двигаться к ней одновременно по нескольким маршрутам.

Требования к участникам

На этой стадии задача бизнеса – найти компетентного партнера в лице проджект-раннера, который поможет ответить на поставленный вопрос. Задача проджект-раннера – помочь бизнесу сформулировать принципиальную схему решения, выполнить техническую экспертизу, создать действующий прототип, понять, есть ли специалисты для реализации замысла и проверить, что у бизнеса достаточно ресурсов на проект. В некотором смысле разработка концепции продукта – это проект внутри проекта, от которого зависит успех его большого брата.

Все это проджект-раннер делает не один, он привлекает профильных специалистов. Их состав – это первая версия гибкой команды, которая в дальнейшем будет работать над проектом. Кто именно войдет в нее, решает проджект-раннер. По мере того, как складывается принципиальная схема решения, образуя собой сложную систему, в команду добавляются ключевые участники, отвечающие за ее отдельные части. Это могут быть профессионалы в области бизнеса и дизайна интерфейсов, исследователи пользовательского поведения и маркетологи, специалисты по нейросетям и технической архитектуре программных продуктов. Короче, все те, кто обладает достаточными компетенциями, исходя из модели, которая начинает приобретать первые контуры.

Способ оценки и планирования

Стоимость разработки концепции является ответом на вопрос: «Сколько нужно заплатить, чтобы узнать, как за доступный бюджет и срок получить то, что требуется?» Ответ на него зависит от того, насколько нестандартная стоит задача и как далеко готов зайти владелец компании в желании придумать по-настоящему новую бизнес-модель. Чаще всего дело ограничивается адаптацией уже работающих схем у аналогичных компаний. В этом случае стоимость может быть фиксированной и включать оплату работы проджект-раннера и нескольких участников команды на оговоренный период.

Если речь идет о поиске принципиально новой бизнес-модели, стоимость может состоять из трех частей – фиксированной, почасовой и опционной. Первая часть относится к креативным задачам по формулированию принципиальной схемы решения и образа цифрового продукта, вторая – к исследовательской работе, и третья предполагает, что у проджект-раннера будет возможность получить долю или опцион в бизнесе в зависимости от результатов проекта.

Независимо от амбиций владельцев и соотношения между фиксированной и почасовой оплатой, общая стоимость стадии концепции не должна превышать 10–15 % от бюджета проекта. Даже если по итогу работы станет понятно, что не удается найти хорошее решение и нет смысла переходить к реализации цифрового продукта, потери бизнеса останутся приемлемыми. Гораздо хуже сразу начать активную проектную работу, пытаясь на ходу искать концептуальные решения, и в итоге потратить почти весь бюджет на напрасные усилия.

Прогнозирование сроков работы над концепцией аналогично оценке стоимости. Есть доступное бизнесу временное окно для того, чтобы понять, в каком направлении можно развивать компанию. Оно зависит от рыночной ситуации и темперамента владельцев. Концепция должна давать принципиальный ответ – стоит ли игра свеч и есть ли возможность запустить компанию с новой бизнес-моделью. Завершив эту стадию, у команды должно оставаться достаточно времени для реализации проекта. Поэтому работу над концепцией продукта всегда стоит четко ограничивать по длительности – по моему опыту, она не должна превышать двух месяцев. Это связано и с психологическими аспектами: отсутствие видимых результатов может привести к потере мотивации и контроля над ситуацией.

Критерий прохождения контрольной точки

Многим кажется, что на этой стадии нужно подготовить лишь презентации, схемы решения и наброски макетов интерфейса на уровне дизайна. Это неверно. Такие результаты не уменьшают неопределенность, а остаются хорошо оформленными гипотезами. Чтобы их проверить, недостаточно фокус-групп и глубинных интервью. Нужен действующий прототип продукта, который позволит убедиться в том, что найденная бизнес-модель действительно привлекает клиентов компании и дает качественные результаты.

Главным критерием успешного завершения стадии и прохождения контрольной точки можно назвать снижение неопределенности до уровня, когда бизнес сможет сказать: «Да, мы готовы рискнуть и продолжить проект» или «Риски слишком высоки, мы останавливаем работы». Это еще одна причина не обращаться сразу в компании, занимающиеся разработкой, и тем более не использовать гибкие методики типа Scrum. Такие компании зарабатывают на продаже человеко-часов своих специалистов и выигрывают независимо от того, терпит ли проект неудачу или начинает приносить пользу его владельцам. Не в их интересах, чтобы бизнес мог отказаться от проекта на ранней стадии, когда бюджет еще не израсходован. Делая упор на быстрый переход к разработке, они упускают выбор той самой стены, к которой предстоит приставить лестницу.

Модель продукта

В отличие от описанной ситуации, проджект-раннер действует иначе. Его мотивация связана с успехом проекта, и он, как и владельцы компании, хочет как можно раньше понять, стоит ли инвестировать свое время. Такого результата можно добиться, только проработав все уровни проекта и потом связав их вместе. На уровне бизнеса это выражается в понимании реалистичности принципиальной схемы решения и определении способа ее реализации. Владелец озвучивает свое видение бизнес-модели, а проджект-раннер помогает выбрать подходящие технологические инструменты. Только тогда начинают фигурировать мобильные приложения, онлайн-сервисы, голосовые ассистенты, нейронные сети и другие модные и не очень термины.

После выбора проджект-раннер и команда могут перейти к трем уровням модели продукта – функциональному, интерфейсному и техническому. Формулируют, что цифровой продукт должен делать, как выглядеть и как быть устроен. Нельзя ограничиться, например, только внешним видом, нужно найти сочетание формы и внутренней реализации, ведь это разные стороны одной монеты. Безусловно, это должно быть детализировано не больше, чем требуется для проверки работоспособности идеи и возможности ее реализации. Дополнять модель продукта должен действующий прототип, который отражает видение дизайна и подтверждает, что не осталось открытых технических вопросов, способных помешать разработке.

Только после этой работы у проджект-раннера появляется достаточно информации, чтобы понять, можно ли уложиться в сроки и бюджет. Несмотря на то, что модель продукта на стадии концепции только обретает контуры, это уже расчет, основанный на фактах, а не предположениях. Благодаря этому можно сформулировать требования к специалистам для следующих стадий и выяснить их доступность, как и текущую стоимость привлечения. Организационный уровень становится прогнозом и задает границы, в которых должен оставаться проект.

Высокоуровневое проектирование

Цель стадии и характер работ

Если на стадии концепции целью было найти решение как таковое, не затратив лишних средств, то дальше, убедившись в его работоспособности, можно готовить почву непосредственно для разработки цифрового продукта. Фактически теперь начинается проектирование в том виде, как об этом все привыкли думать. Я имею в виду проработку системы на уровне UX, дизайна и технического устройства. Но, учитывая принцип выпуска продукта подобно череде эпизодов сериала, лучше проявить предусмотрительность и сначала выполнить ту часть проектирования, которая относится не к конкретным функциям, а к продукту в целом. Согласитесь, экономически выгодно сделать один раз то, что можно использовать в дальнейшем, не затрачивая каждый раз средства и время.

Для такой подготовительной работы в «Методе параноика» предусмотрена стадия высокоуровневого проектирования. Ее цель – выстроить архитектуру системы и создать инструменты, с помощью которых можно сделать продукт более надежным, а работу над отдельными версиями быстрой и недорогой. Только так можно получить настоящий эффект от гибкого подхода к разработке. В противном случае что толку от того, что участники проекта договорились не ограничивать бизнес в его желании произвольно менять список задач для каждой итерации, если за это они вынуждены копить технический долг и подолгу стабилизировать систему?

Чтобы этого добиться, нужно выполнить несколько требований. Во-первых, не брать за основу техническую реализацию, полученную на стадии концепции продукта. Архитектура продукта не должна содержать компромиссные решения, которые были оправданы на коротком отрезке проверки гипотез, но не подойдут при масштабировании системы. Вспомним легендарного Алана Купера и его историю продажи стартапа компании Майкрософт, из которого возник один из первых инструментов визуальной разработки – Visual Basic. После того, как сделка была завершена и началась работа внутри корпорации, он принял решение выкинуть весь старый код и начать проектирование с нуля. Это привело к внутреннему конфликту с руководством Майкрософт, но в результате Купер и команда отстояли свою позицию и смогли подойти к разработке с учетом иного масштаба требований, что в дальнейшем хорошо сказалось на качестве продукта.

Во-вторых, при высокоуровневом проектировании нужно опираться на реальные функции системы, а не на абстрактные стандарты. Любые архитектурные шаблоны или распространенные подходы к дизайну интерфейсов всегда имеют подходящий контекст применения и сами были рождены для решения вполне конкретных задач. При работе над уникальным цифровым продуктом необходимо учитывать его специфику. Откуда же ей взяться на раннем этапе? Секрет в том, чтобы сразу начать проектирование нескольких ключевых функциональных частей продукта, даже если они не войдут в первую версию. Уровень проработки должен позволить команде разработки наметить программные компоненты и сверстать наброски пользовательского интерфейса, но не наполнять их реальным содержанием. Это поможет увидеть, как сочетаются разные требования, и вывести общие правила.

В-третьих, высокоуровневое проектирование должно касаться всех аспектов продукта, а не ограничиваться только его функциями или внешним видом. Их будет недостаточно, чтобы сделать работу над очередной версией предсказуемой и не требующей серьезных затрат на базовые механизмы системы. Более того, иногда разные уровни продукта могут вступить в противоречие и, если узнать об этом где-то в середине проекта, то цена вопроса на переделку уже готовых частей может оказаться слишком высокой. Очевидно, что у проектировщиков на данной стадии есть больше возможностей учесть разные факторы, чем у разработчиков при работе над отдельной функцией продукта, и этим нужно воспользоваться.

Описанные требования к процессу высокоуровневого проектирования меняют характер работ. В отличие от предыдущей стадии, здесь гораздо больше определенности. Поиск решений аккуратно зажат в границах сформулированной концепции продукта и в значительной степени заключается в выборе наиболее подходящих способов его реализации, нежели чем в нахождении видения продукта как такового. Кроме того, дело не ограничивается непосредственно проектированием. Единственный способ проверить, насколько качественно оно выполнено – разработать на его основе внутреннюю версию системы, то, что мы называем «нулевым релизом». Это запрограммированные компоненты архитектуры, на которые будут опираться реальные функции продукта. Подразумевается также реализация базовых механизмов пользовательского интерфейса в виде схематичных форм с возможностью навигации по основным разделам продукта.

Требования к участникам

Над высокоуровневым проектированием работает вторая версия гибкой команды, которая формируется по результатам стадии концепции продукта. Состав команды зависит от первоначальной модели продукта, но есть и постоянные участники, те, кого принято называть «несущей конструкцией проекта». Среди них, прежде всего, проджект-раннер, но его роль на данной стадии меняется. Он уже в большей степени занимается координацией и выступает носителем целей проекта, а инициативу по проектированию перехватывают другие участники. Они отвечают за ключевые части продукта, например, интерфейсы взаимодействия с пользователями или внутреннюю бизнес-логику.

В зависимости от устройства продукта, базовыми компетенциями ключевых участников могут быть дизайн-системы, проектирование сценариев голосовых интерфейсов или мобильных приложений, серверная архитектура или высоконагруженные базы данных, интеграция с банковскими сервисами или настройка нейронных сетей. Тем не менее, любой участник должен обладать и другими компетенциями, т. е. быть мультидисциплинарным, исходя из природы той части системы, за которую он отвечает.

Несмотря на название «высокоуровневое проектирование», в работе участвуют не только проектировщики. Разработка «нулевого релиза» составляет существенную часть задач, а значит, нужны специалисты, способные ее выполнить. Речь идет о системных компонентах продукта, и этими задачами должны заниматься не просто программисты в роли исполнителей, а ключевые участники – профессионалы высокого уровня. Они должны задать культуру разработки и стандарты качества, которые будут поддерживаться на протяжении всего проекта.

Способ оценки и планирования

Более предсказуемый характер работ диктует иной способ оценки и планирования. Концепция продукта в качестве вводной информации дает первоначальное представление о наборе необходимых функций, технической архитектуре и платформах, на которых он должен быть реализован. Получается, можно четко очертить круг задач по высокоуровневому проектированию каждой части, например, пользовательского интерфейса, бизнес-логики или обработки данных и распределить их между участниками.

Это означает, что оценка на данной стадии будет более предсказуемой, и уже можно говорить об ожидаемых сроках и стоимости выполнения задач. Тем не менее зафиксировать их заранее не получится, только обозначить примерные границы. Хотя задачи уже не носят эвристический характер, поиск решений при проектировании может пойти непредсказуемым путем. Дополнительным фактором неопределенности служит еще и необходимость проводить исследования, которые могут сильно повлиять на способы решения проектных задач. Это связано и с пользовательским поведением, и с особенностями технической реализации.

Все это в равной степени относится и к задачам по созданию «нулевого релиза». Нельзя заранее сказать, какой точно бюджет потребуется для разработки базовых компонентов архитектуры и сколько нужно времени, ведь их перечень и требования к ним рождаются в процессе высокоуровневого проектирования. Даже если бы эти требования были известны сразу, то неопределенность все равно сохранялась бы, поскольку разработка системных механизмов продукта тоже своего рода исследовательская работа, связанная с проверкой гипотез и поиском наиболее удачных способов реализации на программном уровне.

Хорошая новость состоит в том, что в сравнении со стадией концепции продукта, где сроки и стоимость имеют неопределенный характер и должны быть искусственно ограничены в виде некой условной доли от общего доступного бюджета, в случае с высокоуровневым проектированием ясности гораздо больше. Благодаря первому правилу принципа проектирования, которое требует, чтобы каждое решение в проекте уменьшало неопределенность, постепенно происходит качественный переход от исследований и креативного процесса к типовым задачам с четкой постановкой. В результате каждая следующая стадия становится все более предсказуемой с точки зрения необходимых затрат.

Критерий прохождения контрольной точки

Должен признаться, если что и раздражает меня больше самонадеянных программистов, отмахивающихся от необходимости предварительно спроектировать сложную систему и зафиксировать решения в виде документации, так это проектировщики, уверенные, что их работа заканчивается, когда они передали готовые спецификации в разработку. Большее высокомерие еще надо поискать. Особенно это поражает, когда они требуют от бизнеса принять их работу без четких критериев для ее оценки. Кто решает, действительно ли техническая архитектура надежна, или насколько продуман дизайн интерфейса приложения? Они говорят: «Мы специалисты, нам виднее!»

Единственным достоверным критерием качества проектирования служит реально работающая система. Поэтому в фирменном проектном процессе высокоуровневое проектирование включает задачи по разработке. В противном случае не было бы объективного способа подтвердить прохождение контрольной точки проекта. Но что же является минимальным результатом, достаточным для проверки, ведь у нас нет цели и возможности на ранней стадии получить полноценно функционирующий продукт? Напомню, модель продукта имеет три уровня – функциональный, интерфейсный и технический. На каждом из них должна быть возможность убедиться, что высокоуровневое проектирование позволяет достичь целей проекта.

Ответ – «контурная раскраска». Так мы называем разработанную систему с базовыми архитектурными компонентами, но без прикладной функциональности. Вместо действующих форм в интерфейсе пользователь увидит заглушки, представляющие намеченные в роадмапе проекта основные разделы мобильного приложения или онлайн-сервиса. Между ними должна быть возможна навигация, а дизайн – соответствовать выбранному стилю.

Такой подход сильно облегчает взаимодействие проектной команды с бизнесом, ведь теперь можно заранее «потрогать» и оценить продукт на смартфоне или в браузере, а не в виде слайдов. Не нужно беспокоиться, что у разных людей по-своему работает воображение, и можно разговаривать, держа в уме одинаковую картинку. Все участники видят контуры будущего продукта, и дальнейшая работа над проектом в каком-то смысле будет похожа на постепенное «раскрашивание» еще не реализованных разделов, которые будут наполняться функциональностью версия за версией.

Помимо этого, есть и психологический эффект. Для бизнеса «нулевой релиз» воспринимается как готовый продукт, который появляется у них в руках. Это создает другое настроение и энтузиазм. Не нужно ждать долгие месяцы проектирования и разработки – продукт уже можно показать партнерам при личных встречах, фантазировать и примерять к предстоящим изменениям в компании, показывать и обсуждать с коллегами. С образом будущего в руках роадмап проекта больше не нечто абстрактное, что можно проигнорировать, а наоборот – что-то живое и реальное. Так можно вовлечь бизнес в реальную работу над будущими «эпизодами сериала».

На техническом уровне смысл разработки базовых архитектурных частей в том, чтобы как можно раньше провести нагрузочное тестирование, проверить отказоустойчивость и убедиться в работоспособности критически важных интеграций с внешними сервисами. Архитектура также проверяется на простоту добавления новых прикладных функций. Сразу реализуются механизмы авторизации, хранения данных, развертывания и обновления продукта на пользовательских и серверных устройствах.

Модель продукта

Следуя принципу сериала, решения, принимаемые на стадии высокоуровневого проектирования, преследуют две цели: создать общие правила и механизмы для развития продукта, и более детально спланировать маршрут достижения конечной точки проекта в виде последовательности «эпизодов» или версий продукта. Все это должно быть отражено в его модели. Рассмотрим, как это выражается на каждом уровне.

Для бизнеса важно сопоставлять свои ожидания от промежуточных результатов проекта с изменениями на уровне процессов компании. Поэтому первой и важнейшей частью модели является согласованное видение того, в каком порядке будут появляться новые функции продукта. Оно должно учитывать потребности бизнеса и возможности проектной команды, а также логику технологического процесса разработки продукта.

Уровни модели продукта – функциональный, интерфейсный и технический – должны описывать выбранную архитектуру продукта и одновременно служить инструкцией для проектирования прикладных функций на последующих стадиях. Функциональный уровень должен давать представление о сценариях взаимодействия пользователей с системой в масштабах всего проекта, структурируя их на разделы и локализуя группы функций продукта. В зависимости от типа канала интерфейсный уровень должен описывать либо визуальный, либо иной язык, на котором система «общается» с пользователями. Иногда об этом говорят как о дизайн-системах. Технический уровень должен описывать архитектуру программных компонентов, способы их реализации и расширения под новые прикладные задачи продукта.

Понятно, что имея на руках столь обширную картину всего проекта, проджект-раннер вместе с остальными ключевыми участниками уже сможет дать более точный прогноз по возможным расходам на реализацию всего проекта в целом и первой версии продукта в частности. Оценка сложится из требований к специалистам, которых необходимо будет подключить в команду, из объема работ, который им предстоит выполнить, и стоимости их привлечения. Вообще можно сказать, что высокоуровневое проектирование – это стадия, когда подбираются ключевые участники, которые будут принимать активное участие в течение всего проекта при работе уже над конкретными версиями продукта.

Детальное проектирование

Цель стадии и характер работ

Первые две стадии – концепция продукта и высокоуровневое проектирование – были последовательными шагами формирования цели проекта и подготовки инструментов для ее достижения. Следующая часть фирменного проектного процесса – это «ран», цикл выпуска версий продукта, состоящий из детального проектирования и разработки. Он будет повторяться до тех пор, пока проект не достигнет цели или не выяснятся ограничения на уровне архитектуры продукта. В первом случае проект завершится, во втором – вернется на стадию высокоуровневого проектирования.

В контексте принципа сериала «ран» нужен, чтобы двигаться короткими шагами, а не делать все сразу. Так достигается тактическая гибкость проекта, когда команда может сфокусироваться на нескольких новых функциях и найти наилучший способ их реализации применительно к текущей ситуации в бизнесе. Сделав шаг, можно оценить эффект, скорректировать маршрут и наметить следующий шаг, держа перед глазами конечную цель проекта. Кстати, большинство специалистов в профессиональной жизни обычно работают в контексте одного шага. Они практически никогда не поднимаются на уровень выше, и поэтому склонны мерить работу именно в таком масштабе. Но важно разделять цели всего проекта и отдельного шага.

И это неудивительно, ведь один «ран», как эпизод сериала, тоже, по сути, проект в проекте. То, что он разделен на две стадии, имеет несколько причин. Прежде всего важно не смешивать разный характер работ при проектировании и разработке, как и связанную с ними неопределенность. Несмотря на то, что после готовности концепции продукта и высокоуровневого проектирования уровень ясности в проекте становится высоким, проектирование конкретных функций остается исследовательской работой, хотя и на локальном уровне. Иначе это бы не был тип «Мозги». Если смешать вместе поиск решений и их воплощение, то работа над каждой версией станет совершенно непредсказуемой.

Из этого следует цель стадии детального проектирования – максимально прояснить содержание функций продукта, запланированных для новой версии и определить, как они должны быть реализованы. Это похоже на подготовку нового эпизода сериала – сначала пишут сценарий и делают подробную раскадровку, а потом приступают к съемкам.

Еще одна причина, почему нельзя объединить работу над очередной версией продукта в одну стадию, заключается в том, что проектированием и разработкой занимаются разные специалисты. Чтобы сформулировать требования к программистам, нужно знать детали реализации. Безусловно, в команде остаются ключевые участники, ведь архитектура продукта не меняется от версии к версии, тем не менее новая функциональность может потребовать уникальных по своим компетенциям специалистов.

Требования к участникам

Каждая стадия в проекте равна новой версии гибкой команды. В ней по-прежнему участвует проджект-раннер как координатор и носитель идей проекта. Он следит за тем, чтобы проект не сбился с пути и двигался в сторону общей цели, даже на уровне отдельной версии продукта. Но основную работу по детальному проектированию выполняют ключевые участники, отвечающие за те части системы, которые затрагивают новые функции.

В отличие от стадии высокоуровневого проектирования, здесь требуются прикладные знания и соответствующий уровень абстракции. Например, те, кто проектирует пользовательские сценарии на функциональном уровне, должны разбираться в особенностях работы компании именно в той части, с которой они связаны. Аналогично с интерфейсом, где делается упор на проработку каждой детали будущей реализации. На этой стадии участники проекта меньше думают на системном уровне, зато должны хорошо разбираться в конкретных инструментах и приемах проектирования. То же относится к техническому уровню, где ранее определенная архитектура задает рамки, в которых необходимо скрупулезно детализировать алгоритмы поведения конкретных прикладных компонентов.

Способ оценки и планирования

Раз целью высокоуровневого проектирования было упростить и удешевить работу над отдельными версиями, а заодно и сделать ее более предсказуемой, то здесь, при оценке стадии детального проектирования, все ранее затраченные усилия дают о себе знать. К началу этой стадии уже есть реализованная архитектура и правила добавления новых функций на каждом уровне продукта. Не нужно ничего придумывать с нуля, можно использовать готовые инструменты. Функциональные границы версии продукта, которую предстоит спроектировать, уже определены. Фактором неопределенности выступают только пользовательские сценарии и то, как они будут отражены на уровне новых функций продукта.

В таких условиях прогнозирование стадии может быть достаточно точным, хотя это не означает полной предсказуемости. У участников должна быть творческая свобода, поскольку принцип сериала для того и разбивает проект на самостоятельные «эпизоды», чтобы в них могли найти место идеи, которые не были очевидны в начале проекта. Иногда участники могут даже ставить эксперименты в стиле «штанги Талеба», когда часть функций новой версии решает согласованные задачи, а другая служит способом проверки новых гипотез на реальных пользователях.

Способ оценки стадии получается комбинированным. Большую часть задач можно определить заранее, например, подготовку дизайна интерфейсов или логику внутренних компонентов. Грубо говоря, можно с некоторой погрешностью сказать, сколько форм или процедур потребуется спроектировать, а значит и установить стоимость, исходя из среднего времени на единицу такой работы. Но это прогноз, который нельзя фиксировать как окончательную стоимость работ и сроки, так как в процессе анализа результатов исследований и выстраивания логики поведения системы обязательно будут внесены изменения в первоначальную оценку объема работ.

Вообще всегда, когда речь идет о проектировании, нельзя заранее с абсолютной точностью предсказать количество усилий, которые потребуется затратить проектной команде. Поиск решений сопряжен с неопределенностью, и чем более нестандартная задача стоит перед проектом, тем выше ее уровень. Если вы попытаетесь навязать участникам команды жесткие сроки и бюджет, то поставите их в ситуацию, когда они либо не будут успевать проверить все возможные варианты и всегда будут выбирать самый простой, но не самый лучший, т. е. будет страдать качество продукта, либо вообще откажутся от проверки выбираемых ими решений.

Поэтому вторая часть оценки стадии детального проектирования складывается из задач по непосредственной разработке критических механизмов, необходимых для подтверждения гипотез проектировщиков. Если их не проверять, то разработчики на следующей стадии столкнутся с неопределенностью, которая выявится уже при реализации. Здесь опять же речь идет только о возможном прогнозе, точность которого постепенно повышается от версии к версии продукта по мере того, как накапливается статистика работы команды.

Критерий прохождения контрольной точки

Критерии проверки результатов стадии детального проектирования не так прямолинейны, как при высокоуровневом проектировании. Там было необходимо сразу реализовать базовые компоненты системы на основе принятых проектировщиками решений. Вопрос имел слишком большое значение для всего проекта, чтобы откладывать его на более поздние этапы работы. При выпуске отдельной версии продукта стадии проектирования и разработки разделены, что требует другого подхода для прохождения контрольной точки между ними.

В роли такого подхода выступает правило «шкуры на кону» и действует сразу на две группы участников проектной команды – тех, кто выполнил детальное проектирование и тех, кто на его основе будет вести разработку. Механизм работает так: проектировщики передают результаты своей работы разработчикам, пройдя процедуру защиты, и пока разработчики не примут их, подтвердив готовность реализовать новую версию в соответствии с подготовленной моделью продукта, работа проектировщиков не считается завершенной. В дополнение к этому есть понятие авторского надзора на период разработки, когда проектировщики должны отвечать на возникающие у разработчиков вопросы, если документация неполная или описанные в ней решения не работают, и проверять на итоговой стадии разработки, что конечный результат соответствует переданной документации.

В таком подходе нет ничего странного, если понять, что в роли проектировщиков обычно выступают ключевые участники, отвечающие за части системы, которые обновляются или создаются при работе над новой версией продукта. Они выполняют роль проджект-раннеров «на местах», а их локальной командой выступают разработчики, специалисты, отобранные на основе результатов проектирования. Поэтому чем меньше проблем они создадут проектировщикам, по факту проджект-раннерам в рамках конкретной части системы, тем последним выгоднее. Это мотивирует проектировщиков тщательно продумывать детали устройства продукта, чтобы не отвлекаться на стадии разработки. Ясно и непротиворечиво поставленная задача позволяет сократить усилия на авторский надзор.

Еще одно преимущество прохождения контрольной точки в формате защиты результатов проектирования в том, что разработчики не выступают в роли пассивных исполнителей воли проектировщиков, а могут влиять на проектные решения. Часто именно разработчики обладают актуальными знаниями о технологиях и инструментах разработки, и было бы странно не воспользоваться таким активом. К ним можно обратиться еще на стадии проектирования, чтобы потом не терять время при переходе к стадии разработки. Так разработчики будут рассматривать проектные решения как свои, либо как те, к которым имеют непосредственное отношение, что повысит их вовлеченность в реализацию.

Модель продукта

Если цель проектирования – дать возможность умереть плохим идеям, не заплатив за это смертью самого продукта, то нужно определить границу между предварительным поиском решений, проверкой гипотез и воплощением сформулированного замысла на техническом уровне. Для этого нужно учитывать все три правила принципа проектирования и помнить, что проектирование должно снимать с разработчиков необходимость разбираться с вопросами, которые не входят в круг их ответственности, и давать им возможность сфокусироваться на том, что они умеют лучше всего – находить оптимальные способы реализации представления о поведении продукта на программном уровне.

Проектирование должно учитывать все факторы, важные для построения модели продукта, и среди них много того, что неочевидно для разработчиков. Например, юридические аспекты или вопросы стоимости поддержки. Выделенное проектирование позволяет интегрировать это на уровне архитектуры, в то время как разработчики решают локальные задачи и баланс всей системы находится вне их контроля. Получается, что при проектировании нельзя ограничиваться только формулированием функциональных требований, пусть и детальным, а нужно идти глубже, на уровень устройства продукта.

В случае с тремя уровнями модели продукта это выглядит следующим образом. На функциональном уровне необходимо описать контекст работы продукта с точки зрения сценариев и точек контакта пользователей с системой. Иногда это называют CJM, их цель – выявить набор функций продукта, закрывающих все требуемые сценарии. Функции предстоит наделить внутренней логикой, опирающейся на структуру данных. Удивительно, но даже многим опытным проектировщикам кажется, что это ответственность разработчиков. На самом деле продукт – это набор алгоритмов, и именно они позволяют ответить на вопрос «Что должна делать система?».

На следующем уровне модели продукта функции должны найти отражение в виде спроектированных интерфейсов. В общении с коллегами я не устаю повторять, что для получения качественного результата от разработчиков мало на стадии проектирования «отрисовать основные формы». Необходимо показать как они работают во всех режимах, включая даже редкие ошибки системы. То, что событие происходит только в критические моменты, не значит, что оно не должно быть корректно запрограммировано. И конечно это должно быть увязано с внутренней логикой на функциональном уровне.

Технический уровень традиционно принято отдавать на откуп разработчикам, и здесь кроется одна из причин скрытых дефектов продуктов или неэффективной реализации. Если логика функций не разложена на архитектурные компоненты системы, то такие решения принимаются на стадии разработки. Они могут не учитывать, что подразумевалось как на стадии детального проектирования, так и при создании архитектуры. Постановка задач на стадии разработки должна исключать вариативность в вопросах требуемого поведения системы, в том числе и на уровне ее внутреннего устройства.

Разработка

Цель стадии и характер работ

Стадия разработки – вторая часть «рана» в цикле выпуска новой версии продукта. Здесь фокус смещается с системного уровня на инструментальный. Это не означает, что поиск решений заканчивается, и начинается чисто механическая работа. Разработка требует не меньше изобретательности от специалистов, чем проектирование, но на другом уровне абстракции. Цель стадии разработки – воплотить решения в реальности.

Мне нравится думать об этом как о совместной работе композитора и исполнителей. Я видел, как профессиональные музыканты тщательно готовятся к выступлению. От их интерпретации произведения зависит, почувствует ли слушатель задуманное композитором. То же касается связки драматурга, режиссера и актеров. Чтобы история, описанная в сценарии фильма, ожила для зрителя, от режиссера вместе с актерами требуется огромная работа. Важно учитывать каждый нюанс, но всегда остается место для импровизации. Похожим образом проектировщики работают с командой разработчиков, чтобы достичь идеального «звучания» продукта.

Требования к участникам

После прохождения контрольной точки, которая разделяет детальное проектирование и разработку, ответственность переходит к следующей версии гибкой команды. Ключевые участники становятся режиссерами, сверяются с моделью продукта и добиваются от разработчиков «правильной» игры.

Требования к специалистам формируются на стадии проектирования и команда дополняется новыми членами. От них не ожидают мультидисциплинарности, как от ключевых участников. Они должны профессионально владеть инструментами и быть компетентными в выбранном технологическом стеке, будь то серверная или клиентская разработка, верстка интерфейсов или программирование сценариев голосовых систем, настройка платежных шлюзов или обучение нейронных сетей. Их задача – качественная реализация новой версии продукта выразительными средствами, определенными архитектурой системы.

Способ оценки и планирования

При переходе к стадии разработки рабочий процесс в проекте меняется и приобретает более предсказуемый характер. Неопределенность на этой стадии должна достичь своего возможного минимума. Все, что предшествовало разработке в проекте, делалось именно с этой целью. Объем работы, который предстоит выполнить, существенно превышает тот, что был на стадии проектирования, и значит, чем меньше потерь, связанных с неэффективным использованием ресурсов, тем лучше. Грубо говоря, сделать дизайн двадцати экранов мобильного приложения – это одно, а запрограммировать их – совсем другое. Особенно когда это включает в себя сложную внутреннюю логику системы. Если разработчикам придется каждый раз тратить лишнее время на проработку нерешенных проектировщиками вопросов, то в итоге часы сложатся в дополнительные дни, недели или месяцы, которые не позволят проекту вписаться в расчетные сроки и границы бюджета.

Так что предсказуемость – это то, что ожидается на данной стадии. Она закладывается еще во время проектирования, в момент защиты проектировщиками своих решений. Специалисты, знакомясь с ними, одновременно оценивают их с точки зрения возможных трудозатрат на реализацию. Если модель продукта полна и подробна, разработчики могут точно оценить работу.

Дополнительное преимущество состоит в том, что сразу имея на руках всю необходимую информацию, есть возможность учесть взаимное влияние задач друг на друга. Элияху Голдратт в своей теории ограничений писал: «Оптимизируйте систему в целом, а не ее отдельные части». Так и здесь, общий взгляд на задачи позволяет построить оптимальный технологический процесс разработки всей стадии целиком, бережно используя время специалистов и доступный бюджет.

Критерий прохождения контрольной точки

У стадии разработки есть две заинтересованные стороны, которые могут подтвердить ее успешное завершение. Для прохождения контрольной точки, отделяющей новую версию продукта от пользователей, нужно получить одобрение со стороны бизнеса и проджект-раннера вместе с ключевыми участниками, выполняющими проектирование. Бизнесу нужен работающий продукт, а проджект-раннеру – завершение проектного цикла.

Каждая сторона оценивает результат со стороны интересующих ее свойств готового продукта и своей способности оценить их качества. Бизнес проверяет продукт с точки зрения его потребительских качеств, то есть «работает/не работает», и то, насколько функции соответствуют ожиданиям. Аргумент команды о том, что «все тесты пройдены», не будет убедителен. Поэтому бизнес хочет посмотреть на систему в действии, и единственный способ подтвердить успешное прохождение контрольной точки в глазах бизнеса – показать реальную работоспособность продукта.

Проджект-раннер выступает своеобразным адвокатом проектной команды, а заодно и более тонким ценителем их работы. Он налаживает контакт между бизнесом и специалистами, выступает в роли переводчика для сторон, которые говорят на разных языках. Он управляет ожиданиями бизнеса и помогает найти соответствие между требованиями и функциями продукта. Он также понимает внутреннее устройство системы и способен дать более полную оценку результатов работы специалистов.

Будучи доверенным лицом бизнеса, проджект-раннер может вынести вердикт о готовности новой версии. Для этого он смотрит не только на внешнее поведение системы, но и на ее реализацию. Это его совместная работа с ключевыми участниками, которые спроектировали очередной «ран». Она включает в себя как классическое тестирование, когда система рассматривается как черный ящик, который должен вести себя в соответствии с требованиями, так и то, что мы называем «алгоритмическим тестированием».

Часто то, что «выглядит как утка, крякает как утка и плавает как утка», уткой все же не является. Например, разработчики могли неверно интерпретировать внутреннюю логику системы, описанную в спецификации, и запрограммировать поведение, которое не приводит непосредственно к ошибкам в работе продукта, но сказывается на надежности или имеет долговременные последствия для накапливаемых в системе данных. Такие дефекты нельзя выявить, наблюдая за системой снаружи. Чтобы избежать таких ситуаций, необходимо проверить реализацию, «посмотреть код» на соответствие требованиям. Это можно сделать только в прямом контакте, когда разработчики защищают свой код, объясняя и показывая проектировщикам, как были реализованы те или иные части спецификации. Опыт подсказывает, что такой подход радикально повышает надежность продукта и сокращает период стабилизации.

Важно помнить, что цель – не узнать о плохом результате в конце стадии, а периодически отслеживать ход работ и вовремя давать обратную связь, чтобы у команды было время учесть замечания. Ставить перед фактом, показывая только итоговый вариант – плохая идея. И здесь важна инициатива не только проектной команды, но и бизнеса. Он должен рассматривать себя как участника проекта, а не как «клиента», который ждет сразу готовый результат. Работа на стадии разработки должна быть построена так, чтобы к моменту ее завершения продукт был готов, и прохождение контрольной точки было в некотором роде формальностью.

Модель продукта

Может показаться, что раз модель продукта на стадии разработки служит для команды «сценарием к эпизоду», то она остается без изменений. Поскольку процесс разработки тоже связан с принятием решений, он вносит коррективы в ранее принятые решения на стадии проектирования, и если при этом модель служит способом их структурированного хранения, то она неизбежно обновляется. И здесь важно не упустить этот аспект, оставив все на уровне кода или верстки.

В этой книге много раз было сказано, что проектная документация – это не скучные документы, фиксирующие решения, а инструмент коммуникаций между участниками. Если на стадии разработки выясняется, что какие-то решения оказались ошибочными или неполными, то разработчики сообщают об этом в контексте проектных артефактов, например, спецификации или дизайна интерфейса, а проектировщики отвечают им, уточняя документацию.

Одним из способов добиться этого является схема работы, при которой результаты работы принимается только в случае, когда они соответствуют актуальной модели продукта. В результате у всех участников вырабатывается доверие к документации, и они опираются на нее при принятии решений. В случае с гибкой командой, которая на разных стадиях проекта может отличаться по составу, это вообще единственный способ сохранить «память» о продукте.

Глава 10

Принцип вовлеченности бизнеса

Структура главы:

• Ответственность бизнеса

• Действующий бизнес

• Стартапы

• Customer Development и архитектура бизнеса

Ответственность бизнеса

В компаниях, где бизнес-модель выстроена вокруг цифровых технологий, многое не похоже на традиционные отрасли. Чем сложнее инструменты, тем меньше работает подход «Чтобы на утро все было готово!» Не будет готово ни утром, ни днем, ни даже вечером. Если бизнес хочет строить свою работу вокруг сложных технологических инструментов, ему придется отказаться от принципа «Клиент всегда прав» в отношениях со специалистами и принять свою часть ответственности за результат проекта.

Да, проджект-раннер помогает владельцу сформулировать схему решения, основанную на цифровых продуктах, и тем самым вносит свой вклад в построение компании, но он не придумывает за него бизнес. Проектная команда во главе с проджект-раннером отвечает за «технологический продукт». Они делают «Газель», но не создают транспортную компанию. Владелец должен обернуть «технологический продукт» инфраструктурой, чтобы получить на выходе «бизнес-продукт». Только он понимает всю схему работы будущей компании и может сформулировать высокоуровневые требования к ее частям, включая цифровые сервисы.

Однако, даже если бизнес принимает свою ответственность и ясно обозначает требования к будущему цифровому продукту, неопределенность сохраняется на протяжении всего проекта. Особенно это заметно, когда работа идет в формате сериала и предполагает выпуск промежуточных «эпизодов». С каждой новой версией неопределенность только накапливается. Команда не получает обратной связи и в конце проекта продукт и реальность, проводником которой должен был бы быть бизнес, расходятся настолько, что не имеют между собой никакой связи.

Причина в том, что технологический продукт и бизнес-инфраструктура должны создаваться вместе. Не параллельно во времени и пространстве, чтобы в конце удачно сойтись в одной точке, а вместе, взаимно влияя друг на друга. Нельзя создать идеальный продукт в отрыве от среды, в которой ему предстоит выполнять свои функции. Если посмотреть на него как на растущее дерево, то он должен «врасти» в почву и создать экосистему с окружающим миром. У тех, кто будет ее населять, также должно быть время, чтобы адаптироваться к ней и возможно внести свои коррективы в форму и свойства растения.

Многим неочевидно, но команда не может задать все вопросы сразу. К ним нужно прийти через предшествующие уточнения и выводы. Получается, что когда бизнес включается в проект, тогда и только тогда начинается подгонка продукта под реальную среду. Чем позже начать это делать, тем выше будет итоговая цена. Может так получиться, что придется переделывать весь продукт целиком, если он строился на неверных или неполных предпосылках. Что-то похожее происходит, когда проектная команда презентует уже финальную версию продукта руководству компании, а до этого общалась только с отдельными сотрудниками, цель которых была в том, чтобы продукт соответствовал формальным требованиям, а не актуальным целям бизнеса. При этом я оставляю за скобками вопрос того, кто должен будет заплатить за эту ошибку.

На таких встречах часто звучит фраза: «Вы же профессионалы и должны были все предусмотреть!», – но по факту приемка проекта в момент его полной готовности – это приговор компетентности для представителей бизнеса, а не специалистов. Последние обычно заложники ситуации, когда у них нет возможности выстроить регулярные коммуникации с первыми лицами компании. Это обосновывается тем, что якобы нет смысла проверять еще не готовый продукт и тратить драгоценное управленческое время. Но в том и дело, что постоянный диалог с командой – самое эффективное вложение в проект со стороны бизнеса, которое окупается качественным продуктом в ожидаемые сроки.

Согласно принципу вовлеченности, бизнес не должен быть «воскресным папой» проекта, участвуя в его жизни первый раз в момент первоначальной постановки задачи, и второй – оценивая готовый результат. Важно выступать полноправным участником в течение всего периода работы над цифровым продуктом. Чем большее значение для компании имеет продукт, тем сильнее должны быть вовлечены его первые лица. Я неспроста делаю упор на то, что проджект-раннер работает именно с владельцами бизнеса и первыми лицами компании. Только они обладают нужным уровнем абстракции, компетенции и ответственности для принятия самых важных решений в проекте.

По сути, если вернуться к схеме дерева решений, проектная команда концентрируется на уровнях модели продукта, а бизнес действует на своем уровне. Проджект-раннер взаимодействует со всеми участниками и, опираясь на организационный уровень, собирает весь «проектный бутерброд», чтобы тот не развалился. Давайте теперь посмотрим, как при таком подходе принцип вовлеченности работает для разных видов компаний.

Действующий бизнес

Может показаться странным, но сложнее всего добиться вовлеченности в проект от действующего бизнеса. Особенно если речь идет о кардинальной перестройке компании, а значит о проектах типа «Мозги». Цель в них – придумать уникальное технологическое решение в связке с новой бизнес-моделью, которое к тому же должно быть адаптивным, чтобы в будущем поддерживать работу компании продолжительный период времени. Такие истории не рождаются в суете, а, наоборот, требуют спокойного и вдумчивого подхода. С этим, как правило, у менеджмента компаний большие проблемы.

Думать – это, вероятно, самая большая роскошь в современном мире. Для этого нужно побыть наедине с собой достаточное время и при этом без внешних раздражителей. Современное жизненное пространство «фонит», и человек даже не замечает, насколько сильно. Каждая реклама говорит вам, что делать, новости и люди вокруг вызывают эмоциональную реакцию, как, впрочем, и все остальное. То, что сейчас принято называть «думанием», является просто непрерывной обработкой входящих запросов без возможности услышать себя. Как пошутил один ученый в области изучения человеческого мозга, «сознание – это то, что появляется, когда вы просыпаетесь, и пропадает, когда вы приезжаете в офис».

Чтобы понять, связана ли ваша работа с умственной деятельностью, посмотрите на свой календарь и список задач. Если там нет пустых дней, когда вы можете свободно думать, то, к сожалению, не связана. Без возможности уделить достаточно времени на поиск и обдумывание идей вы не сможете сформулировать что-то стоящее. Вспомните: самые интересные и неожиданные решения приходили к вам на прогулке или в долгой поездке, когда вас не отвлекали, и вы могли надолго погрузиться в размышления. В такие моменты ничего не сдерживает ход мыслей, ум легок и свободен.

Все совсем не так, когда вы занимаетесь оперативным управлением. Проблема не только в непрерывном решении возникающих вопросов, но и в постоянной смене контекста. Только что вы с финансовым директором обсуждали бюджет следующего квартала, и вот вы уже на совещании отдела производства. «Длинные» мысли не успевают получить развития. Да, я знаю, многие предприниматели гордятся многозадачностью, и даже утверждают, что в этом секрет их успеха. Но мой опыт говорит, что это путь в никуда.

Когда вы сосредоточены только на текущих вопросах, то не думаете о будущем. Это значит, что у вас нет стратегического взгляда на свой бизнес. Практическая сторона стратегии заключается в создании возможностей для компании в будущем и использовании их на тактическом уровне. Фокусируясь только на настоящем, можно лишить себя завтрашнего дня. Если вы не думаете сами, то за вас это делают другие – сотрудники, партнеры, конкуренты, и, конечно же, в своих интересах. В результате вы оказываетесь в наименее выгодной среди всех остальных позиции.

Создание цифрового продукта в проектах типа «Мозги» всегда связано с будущим, поскольку это инструмент, вокруг которого будет выстраиваться новая бизнес-модель. Не может быть ситуации, при которой компания уже работает по придуманной схеме, но технические средства для этого еще не созданы. Они рождаются одновременно. Поэтому действующему бизнесу необходимо разделять задачи поддержания текущей деятельности и вопросов перехода к новой модели работы.

В этом правиле ярко проявляется разница между владельцем компании и менеджментом, хотя они часто совмещаются в одном человеке. У них разные задачи. Владелец придумывает бизнес-модель и ищет способы ее воплотить, а менеджмент обеспечивает ежедневную работу через оперативное управление запущенным механизмом. Это требует разного подхода. Первый думает о новых возможностях, вторые – об эффективности текущей деятельности. У них разный горизонт планирования, и то, что владелец разглядит в качестве хорошей возможности для бизнеса в будущем, менеджмент может воспринимать как угрозу статус-кво в настоящем.

Если в инновационном проекте в качестве представителей бизнеса участвуют те, кто занимается оперативным управлением, то команда испытывает на себе все описанные выше противоречия целей разных ролей. Я неоднократно видел, как хорошие идеи отвергались, потому что не решали текущих задач, или им не давали достаточно времени на развитие. Идеям, как и растениям, нужно время, чтобы вырасти. Давить и кричать на морковку: «Расти!» – бесполезно – у растений свой естественный цикл роста. Точно так же нет смысла использовать приемы оперативного управления в поиске новых решений. Здесь другие правила.

Конечно, нельзя игнорировать интересы тех, кто в дальнейшем будет использовать цифровой продукт в качестве инструмента в бизнесе. Но когда вы поручаете рядовым сотрудникам собеседование с новыми людьми в компанию, они выбирают в первую очередь удобных и приятных для себя коллег, и только во вторую тех, кто будет решать задачи бизнеса. Так происходит и при принятии проектных решений. Это уместно при развитии существующего продукта для сложившейся бизнес-модели в формате проектов типа «Процедуры», но на начальной стадии, когда формируется новая модель, решения должны соответствовать стратегическим целям владельца, а не быть политическим компромиссом в угоду интересов разных подразделений.

Если владелец бизнеса хочет добиться результата в преобразовании своей компании, то должен выстроить с проектной командой здоровую творческую атмосферу и выйти на время из оперативного управления. В зависимости от размера бизнеса это может быть творческий отпуск или организация регулярной работы внутри автономного подразделения, занимающегося перспективными направлениями развития.

Стартапы

В противоположность действующему бизнесу, основатели стартапа думают только о будущем. У них еще нет настоящего, о котором стоило бы беспокоиться. Если владельцы существующей компании, даже проходящей через преобразования, могут опереться на прошлый опыт при поиске новой модели, то у тех, кто только начинает путь, царит полная неопределенность. Под вопросом сама возможность построить работающий бизнес на основе первоначальной идеи. Все это требует учесть множество факторов, и цифровой продукт – далеко не единственный среди них.

Внести ясность можно только проверив гипотезы на практике. Но как понять, если что-то не получается, дело в неработающей бизнес-модели или может в плохом исполнении продукта или услуги? В зависимости от темперамента основателей, события обычно развиваются по одному из двух сценариев.

В первом случае происходит долгая проработка всех возможных вариантов, многочисленные исследования и фокус-группы, после чего создают детальный бизнес-план. Затем подключаются профильные специалисты, включая команду, ответственную за реализацию цифровых продуктов. Их задача – реализовать полноценную систему со всеми запланированными функциями. При таком сценарии запуск стартапа предполагает одновременную готовность всех частей, отражающих бизнес-модель. Ожидается, что таким образом получится сразу вдохнуть жизнь в новую компанию.

Во втором случае основатели действуют по принципу «Сначала ввязаться, а потом посмотреть». Тщательность подготовки единичных решений заменяется многочисленными набросками, которые никогда не обретают законченный образ. Можно сказать, что это путь проб и ошибок, продиктованный нетерпением в попытке быстрее понять, стоит ли тратить деньги и силы на полноценную организацию бизнеса. Но, даже набрав обороты, в компании не прекращаются эксперименты, больше похожие на продолжающийся поиск концепции, чем на построение стабильных процессов для масштабирования. Цифровой продукт, вокруг которого выстроена бизнес-модель, по качеству так и остается на уровне прототипа, просто с большим количеством функций.

Оба сценария являются следствием неопределенности, в которой находятся основатели стартапа. Желая взять ее под контроль, они либо перестраховываются и долго откладывают встречу с реальностью, либо сразу бросаются в работу, но действуют бессистемно. Проблема в том, что в случае неудачи ни первый ни второй подход не дают возможности локализовать причину. Чтобы это сделать, нужно быть уверенным хотя бы в одной части уравнения – в самом продукте. Без этого рассуждения о том, насколько была верна бизнес-модель не имеют смысла. Возможно, с ней все в порядке, но качество продукта не устраивает ваших клиентов. Даже если вы запускаете кафе, то какой бы новаторской ни была бизнес-модель, сам кофе необходимо приготовить хорошо. Инструмент должен позволять это сделать.

Когда речь идет о запуске стартапов, где услуги и продукты создаются благодаря цифровым инструментам, оба описанных сценария ставят проектную команду в сложную ситуацию и не дают нужной для их работы вовлеченности бизнеса. В первом случае, когда основатели стремятся предусмотреть сразу все, специалисты могут комплексно подойти к созданию системы, но в процессе разработки не получить обратной связи от внешней среды. Из-за этого решения не пройдут эволюционный отбор, следовательно при запуске система не будет соответствовать реальным запросам и сценариям поведения пользователей.

Когда основатели сразу переходят к делу, пропускают этап анализа и действуют «по наитию», ни сама ситуация, ни отсутствие внятного образа будущего не позволяют проектной команде сделать качественный, работающий цифровой инструмент. Возможно, он учитывает прямые запросы клиентов, но не решает задачи бизнеса комплексно. Более того, при развитии каждая новая функция и каждое изменение становятся все дороже и снижают и без того невысокую надежность из-за отсутствия продуманной архитектуры и целостности системы. Дешевизна на старте оборачивается отложенными затратами в будущем.

Есть подход, чтобы справиться с естественной неопределенностью стартапа и избежать обозначенных ловушек. Я говорю об этом с уверенностью, потому что несколько раз был свидетелем подобных историй. Главное отличие основателей таких стартапов в том, что они никогда не впадали в крайности, а рассматривали неопределенность как норму. С одной стороны, они не торопили события и не пытались быстрее избавиться от сомнений в выбранном направлении, понимая, что не все находится в их поле зрения, и тем самым позволяли случаю сыграть им на пользу.

С другой стороны, поиск бизнес-модели и связанных с ней технических решений не носил хаотичный характер, а был наполнен концептуальным взглядом. Принимая то или иное решение, участники стартапа понимали причины, по которым они это делают. Благодаря этому уточнялась общая картина, постепенно превращаясь из набора гипотез в системную модель. Таким образом компания, с первых дней взаимодействуя с реальностью, шаг за шагом обретала ясные черты, не сбиваясь с намеченного пути в угоду сиюминутных метаний.

Customer Development и архитектура бизнеса

Независимо от того, стоите ли вы на пороге радикальной трансформации действующего бизнеса, или вам предстоит запуск стартапа, в основе всегда лежит потребность в нахождении новой бизнес-модели. Модель может строиться вокруг уникальных товаров, которые вы собираетесь производить, или вы нашли более дешевую технологию производства существующей продукции. Возможно, вы придумали сервис, чтобы дать людям больше возможностей, или дело в необычном формате оказания услуг. Так или иначе, вам предстоит нащупать путь воплощения своей задумки в реальность. Если компания строится с применением цифровых инструментов, к вопросам организации бизнес-инфраструктуры еще добавляется задача их создания.

Вопросу о том, как пройти путь от первоначальной гипотезы до работающей компании по новой бизнес-модели, посвящено множество книг и подходов. Одна из самых ярких – «Четыре шага к озарению» Стива Бланка, где он вводит понятие Customer Development. Это комплексный метод разработки новых продуктов в процессе взаимодействия с будущими потребителями. К сожалению, в России прижился лишь фрагмент метода, называемый «кастдев», суть которого в интервьюировании потенциальных клиентов. Такова наша человеческая природа – все упрощать, по пути теряя главное. Если ваш подход более основательный, стоит прочитать эту книгу.

В некотором смысле «Метод параноика» дополняет концепцию Бланка, объясняет, как подойти к созданию цифрового продукта, который выполняет функцию инструмента для новой бизнес-модели. Роль проджект-раннера здесь соединяет уровень, на котором компанию видят владельцы, и продуктовые уровни, где работает проектная команда. В стартапе проджект-раннер становится компаньоном основателей и берет на себя часть, связанную с цифровыми продуктами. Он опирается на принципы проектирования, гибкие команды и организацию проекта в формате сериала.

Чтобы понять, как происходит совместная работа, нужно вспомнить фирменный проектный процесс из четырех стадий: концепция продукта, высокоуровневое проектирование, детальное проектирование и разработка. Каждая из них служит точками взаимодействия между бизнесом и специалистами во главе с проджект-раннером, и каждая предполагает свой особый формат. На первых стадиях он требует глубокой вовлеченности со стороны владельцев и основателей, затем их участие должно состоять в обратной связи на результаты работы команды. Более подробно это будет описано в «Черной» книге, которая станет руководством по внедрению принципов метода на практике.

Важно понимать, что, будучи владельцем или основателем, вы не можете оставаться только в роли администратора или финансиста. Когда вы создаете компанию, основанную на современных технологиях, вам необходимо в них разбираться. По сути вы – архитектор своего бизнеса и должны понимать природу всех частей системы, которую строите. Только так вы сможете увидеть картину своего бизнеса в целом. Специалисты из разных областей помогут разобраться с деталями, но как известно, человеку все можно объяснить, но понять за другого человека нельзя. Это вам придется сделать самостоятельно.

Глава 11

Технология продуктовой разработки

Структура главы:

• Применение метода на практике

• Области применения технологии

• Воронка неопределенности и стадии проекта

• Модель продукта и проектирование

• Проектная команда и управление

• Оценка и планирование работ

• Внедрение технологии и «Черная» книга

Применение метода на практике

«Красная» книга, которую вы держите в руках, описывает методологию создания уникальных цифровых продуктов. В ее основе лежит идея, что неопределенность – это ключевой фактор в таких проектах. Вы не можете полностью ее убрать, иначе получится типовое решение. Игнорировать неопределенность и рассчитывать только на удачу тоже рискованно – можно исчерпать ресурсы и совсем ничего не получить. Неопределенность в подобных проектах необходимо контролировать, начиная с бизнес-требований и заканчивая организационными вопросами. «Метод параноика» представляет собой набор принципов, которые как раз служат этой цели.

Все начинается с понимания, что уникальные решения всегда рождаются только на стыке разных дисциплин. Важно, чтобы специалисты не были ограничены формальными ролями и в их зону ответственности входило несколько уровней проекта. Для этого они должны обладать компетенциями в каждом из них. Собрать такую команду – уже вызов. Поскольку видение цифрового продукта рождается по ходу проекта, невозможно собрать всю команду сразу. Специалисты должны подключаться по мере того, как «проявляется» образ будущего решения, а значит состав участников должен гибко меняться.

Для организации работы подобным образом нужен особый стиль управления – продюсерская модель. Она позволяет структурировать команду вокруг ключевых участников и распределять ответственность между ними. Что более важно – продюсерская модель позволяет формировать команды с нуля индивидуально под каждый проект, привлекая специалистов независимо от того, работают они самостоятельно или внутри компании. Выполнить столь сложную задачу может только тот, кто смотрит на проект комплексно и обладает достаточными полномочиями. Я говорю о роли проджект-раннера, которую вводит «Метод параноика».

В отличие от классических продакт-менеджеров, ориентированных прежде всего на свойства и метрики продукта, и менеджеров проектов, отвечающих за организацию работы, проджект-раннер берет на себя ответственность за весь проект. Это касается и видения продукта, и организации работы команды, и стоимости разработки. Без личной ответственности, «шкуры на кону», невозможно принимать взвешенные решения.

В уникальных проектах полных неопределенности легко потерять ориентиры, склоняясь либо в сторону технического устройства продукта, забывая о его пользовательских свойствах, либо делая ставку на новизну, но упуская коммерческую целесообразность. Справедливо и обратное. Найти баланс – задача проджект-раннера. Отдельные специалисты всегда смотрят на вопросы исходя из своей зоны ответственности и не видят общей картины. Проджект-раннер добивается, чтобы продуктовые решения учитывали как бизнес-требования, так и организационные возможности.

Еще одна задача проджект-раннера – быть инициатором проекта. Ключевое различие между раннером и менеджером продукта в том, что раннер нацелен на создание нового продукта, а менеджер – на развитие существующего. Раннера интересует принципиальная схема решения, а менеджера – метрики для оценки эффективности продукта.

Когда продукт уже существует и команда работает над его развитием, многие вопросы не стоят так остро. Но если мы говорим о создании новых продуктов, к тому же инновационных, то чаще всего нет даже команды. Поэтому у менеджера в распоряжении уже готовая проектная инфраструктура, а раннер должен все создать с нуля. Это похоже на предпринимательский подход, требует самостоятельности, полномочий, ответственности и разных компетенций.

Логично, что первая необходимая компетенция проджект-раннера – умение «собирать» проект целиком, формируя команду и необходимую проектную инфраструктуру. Выполнить это можно только опираясь на технологию. В «Методе параноика» это технология продуктовой разработки.

Процесс похож на производство автомобилей: сначала строится конвейер, обучается персонал, а затем детали постепенно превращаются в готовую продукцию. Так и идеи по устройству будущего цифрового продукта проходят разные стадии, трансформируются из гипотез в проверенные решения, чтобы в конечном счете собраться в виде действующего сайта, сервиса или мобильного приложения.

В технологии продуктовой разработки функцию конвейера выполняет воронка неопределенности – базовый фреймворк, задающий общие принципы работы и стадии проекта. Следующий аспект технологии – модель продукта, в которую складываются все продуктовые решения, включая структуру проектной документации, форматы артефактов и инструменты проектирования. Дальше необходимо разобраться с требованиями к участникам проектной команды, их функциями и с подходами к управлению. Последняя часть – методика оценки и планирования работ. Технология нацелена на работу в условиях высокой неопределенности, обычные методы тут неприменимы.

Получается четыре обязательных компонента технологии, без которых невозможно выстроить работу проектного офиса или отдельного проекта, получая на выходе цифровые продукты с предсказуемым качеством и в границах доступных сроков и бюджета:

• воронка неопределенности и стадии проекта;

• модель продукта и проектирование;

• проектная команда и управление;

• оценка и планирование работ.

Полное описание технологии продуктовой разработки по «Методу параноика» – это тема отдельной книги. Здесь я дам вводные по каждому компоненту, чтобы у вас было общее представление как происходит переход от методологии к ее практическому использованию. Каждому компоненту посвящен отдельный раздел, но я начну с высокоуровневого вопроса: «Для каких задач требуется такая технология?»

Области применения технологии

Цифровые продукты не имеют самостоятельной ценности. Их смысл и значение проявляются только в рамках задач, для которых они создаются. Задачи могут быть разными, но с точки зрения бизнеса есть два варианта: зарабатывать на разработке или на использовании продукта в другой деятельности.

Заказная разработка

Первый вариант – заказная или аутсорсинговая разработка. Ваш бизнес строится на решении тех задач, с которыми ваш клиент не может справиться самостоятельно. Прежде всего это управление проектной работой, проектирование, дизайн, программирование, тестирование, развертывание и поддержка продукта. Все это может выполняться комплексно либо от вас потребуется только часть из общего списка. Ваша ключевая метрика эффективности – какую добавочную стоимость удается получить с каждого специалиста.

Знание предметной области заказчика важно, но ваша истинная цель – удовлетворить ожидания клиента. Как ни странно, иногда реальная полезность продукта не так важна, ведь даже заказчик может не знать, что ему нужно. Зато люди, которые с его стороны отвечают за проект, имеют свои критерии успеха. Например, им должен нравиться дизайн, бюджет и сроки должны остаться в оговоренных рамках, или с вами просто должно быть удобно и приятно работать.

Чем больше размер компании, тем меньше можно увидеть связь функциональных качеств продукта и коммерческих результатов от его использования. Для малого и среднего бизнеса это имеет значение, они нацелены на развитие, и каждая «фича» рассматривается как возможный конкурентный рычаг. В корпорациях все несколько иначе. Там акцент на удержании своего рынка, а значит важна предсказуемость. Ваши услуги могут быть дороже, но если вы гарантируете надежность продукта, выберут вас.

Внутреннее использование продуктов

Второй вариант – создание цифровых продуктов для внутреннего использования, чтобы усилить или изменить бизнес-модель. Неважно, будут использовать конкретный продукт сотрудники или клиенты компании. Его ценность определяется экономическим или другим эффектом, например, маркетинговым, который он приносит на вложенные в его разработку средства.

Ключевая компетенция бизнеса – найти принципиальную схему решения и сформулировать требования к продукту. Управление проектом по его созданию может быть как внутри собственной команды, так и на стороне подрядчиков. Если продукт критически важен для бизнеса, большинство продуктовых и проектных компетенций должно быть внутри. Часто достаточно небольшой команды во главе с проджект-раннером, который привлекает внешние команды и координирует их работу.

Здесь лучше всего проявляется разница между проектным и продуктовым подходом. Первый характерен для задач с ясным конечным результатом, когда нужно, например, получить первую версию цифрового продукта. В этом случае хорошо себя проявляют внешние аутсорсинговые компании, ориентированные на проектный формат работы. Но для дальнейшего развития продукта с учетом регулярных изменений в бизнесе нужна постоянная вовлеченность команды. Она должна накапливать знания, понимать внутреннюю специфику бизнеса и измерять свой успех через эффективность продукта. Такое можно ожидать только от собственных специалистов, работающих в рамках продуктового подхода.

Тиражируемые продукты

Помимо создания цифровых продуктов на заказ и для внутреннего использования, существует третий вариант – разработка тиражируемых продуктов. Они могут поставляться как онлайн-сервисы, мобильные приложения или ПО для установки у клиента. Может показаться, что между тиражируемыми и продуктами, разработанными на заказ, есть сходство. Но это не так. Заказной продукт всегда создается под индивидуальные требования клиента, а тиражируемый воплощает в себе обобщенные представления о решении пользовательской или бизнес-задачи. Добиться такой универсальности крайне сложно.

Бюджет на создание тиражируемого продукта значительно выше стоимости обычной заказной разработки. И это не учитывая затрат на маркетинг и продвижение, часто многократно превышающих расходы на создание самого продукта. Очевидно, что преуспеть в таком бизнесе можно только за счет масштабирования продаж – либо доминируя в рыночной нише, когда ваш продукт считается отраслевым стандартом, либо адаптируя одно и то же решение под задачи в разных отраслях.

Давайте зададимся вопросом, в чем ценность тиражируемого цифрового продукта для конечных потребителей, особенно бизнес-систем? Прежде всего, их можно использовать сразу, и не тратить драгоценное время на самостоятельную разработку. Клиент фактически покупает себе время. Но дело не только в этом. Самый сложный вопрос в проектной работе: «Каким продукт должен быть?» С четко поставленной задачей выполнить разработку не так сложно, как сформулировать, ответив на тысячи разных вопросов при проектировании. Интересно, что ответы часто лежат вне области технических решений и связаны с прикладной сферой применения продукта. Таким образом, компания, покупающая тиражируемый цифровой продукт, приобретает отраслевой опыт, который «зашит» в продукт. Если его внедрение сопровождается консалтингом по оптимизации бизнес-процессов компании, то истинная ценность продукта еще больше проявляется в этом. Правильный подход к бизнес-консалтингу может приносить гораздо больше прибыли, к тому же подкрепленный комплементарным продуктом, чем просто продажа технического решения.

Индивидуальная настройка технологии

В каждом описанном варианте создаются цифровые продукты, но технология их разработки будет отличаться во всех четырех компонентах: стадиях проекта в рамках воронки неопределенности, подходах к проектированию модели продукта, требованиях к участникам команды, способах оценки и планирования работ. Требуется индивидуальная настройка технологии продуктовой разработки в зависимости от области ее применения.

Это связано с разными целями. Заказная разработка ориентирована на максимальную эффективность команды, которая должна выдать результат в ограниченные сроки. Создание продуктов для внутреннего использования направлено на отдачу в самом бизнесе и часто имеет длинный «хвост» доработок и обновлений. Тиражируемые цифровые продукты должны удовлетворять потребностям широкой аудитории, что требует особого подхода к поиску и тестированию новых функций.

Отдельно хочу сказать про технологические стартапы. Они могут относиться к каждой из перечисленных категорий, но от обычных компаний их отличает нацеленность на поиск новой бизнес-модели и связанный с этим уровень неопределенности. Поэтому контроль неопределенности, который встроен в технологию продуктовой разработки по «Методу параноика», требует в стартапах еще большей «паранойи».

При использовании технологии для создания цифровых продуктов нужно понимать, что ее базовая версия «из коробки» будет выдавать усредненный результат. Чтобы получить максимум, потребуется тонкая настройка всех компонентов. Дальше я расскажу о каждом из них и покажу, на что необходимо обратить внимание. При этом хочу напомнить, что подробному описанию технологии посвящена отдельная книга – «Черная».

Воронка неопределенности и стадии проекта

Воронка неопределенности, как базовый фреймворк, задает общую систему координат проекта и вектор, по которому должна быть направлена вся работа над продуктом. При движении слева направо по оси времени цель проектной команды – сужать пространство возможных способов решения исходной задачи, чтобы получить единственный реализованный вариант.

Работа над проектом делится на стадии. В конце каждой из них происходит проверка на целостность всех решений, но внутри стадии участники имеют пространство для творческого поиска. Характер задач на каждой стадии меняется и по мере сужения воронки неопределенности должен становиться более предсказуемым. Технология продуктовой разработки устанавливает набор стадий и конкретные критерии их успешного завершения. В зависимости от области применения и особенностей проекта у них могут быть свои особенности. В девятой главе, описывающей принцип сериала, приведен пример типичного набора стадий.

Решения относительно устройства продукта также структурируются. Это вертикальная ось фреймворка, на которой выделяются разные уровни. Помимо уровней, связанных с продуктом, есть уровни проекта, например организационный и бизнес-уровень. Напомню, что благодаря им получается взять уровни продукта в «тиски», зажав между тем, что НУЖНО и что ВОЗМОЖНО. Концепция «тисков» дополняет фреймворк воронки неопределенности, объясняя, за счет чего должно сужаться пространство возможностей.

Уровни, на которые нарезается воронка неопределенности – это уровни абстракции. Они позволяют смотреть на продукт во всем его многообразии, при этом не быть раздавленным его сложностью. Для цифровых продуктов есть три типовых уровня: функциональный (что система делает), интерфейсный (как система взаимодействует с пользователями) и технический (как система устроена). Набор уровней – такой же настраиваемый параметр при внедрении технологии продуктовой разработки, как и стадии проекта.

На пересечении стадий и уровней локализуются решения относительно устройства продукта, выраженные в виде проектных артефактов – схем, спецификаций, макетов и дизайна интерфейса, описаний пользовательских сценариев, чек-листов для тестирования, бюджета, плана проекта, требований к команде и программного кода. Некоторые артефакты нужны только на отдельных стадиях, другие развиваются и дополняются на протяжении всего проекта. Таким образом получается общая система координат проекта, понятная каждому участнику, и отвечающая, кто, когда и над чем должен работать.

Модель продукта и проектирование

В отличие от производственного конвейера, по которому движутся отдельные части будущего автомобиля, воронка неопределенности работает с идеями. Они поступают на вход, превращаются в гипотезы и, доведенные до проверенных решений, постепенно собираются в комплексное описание компонентов архитектуры или всей системы. Структурой, в виде которой описывается продукт, является его модель.

Модель продукта нужна везде, где применяется проектирование. Проектирование же – это то, без чего невозможно создать что-то сложное. Когда мы говорим о движении идей, гипотез и решений по воронке неопределенности, то на самом деле мы говорим о процессе проектирования. Поэтому логично, что модель продукта выступает в роли контейнера для проектных артефактов. По сути, модель продукта – это набор таких артефактов.

Структура модели задается уровнями проекта и подобна изображению, состоящему из пазлов. Если элемент отсутствует или он неполон, то общая картина не складывается. Например, можно детально описать поведение системы на функциональном уровне и визуально представить ее интерфейс, но если на техническом уровне не будет архитектуры и устройства программных компонентов, то работа команды разработчиков будет непредсказуемой.

Конкретный набор артефактов и требований к ним – часть технологии продуктовой разработки. В зависимости от типа разрабатываемых систем один и тот же уровень проекта, например, интерфейсный, может быть представлен по-разному. В мобильных приложениях это навигационные карты переходов, детальные макеты экранов и примеры анимации отдельных элементов форм. Для системы с голосовым вводом потребуются сценарии диалогов, справочник синонимов, набор интентов и прочее.

По мере продвижения проекта от стадии к стадии структура модели продукта меняется. Например, на концептуальной стадии не требуется детально прорабатывать функции и техническое устройство. Достаточно общего представления о возможностях продукта и ключевых элементах архитектуры. Тщательная работа над этими аспектами будет происходить на более поздних стадиях. Технология продуктовой разработки должна это учитывать и структурировать модель продукта не только по уровням, но и по стадиям.

Теперь, если представить точки пересечения стадий и уровней проекта, то это будут пазлы или ячейки модели. Работа над ними не идет последовательно, например, снизу вверх, когда сперва выясняются детали на уровне бизнес-требований, потом на функциональном. Наоборот, поскольку решения рождаются на стыке разных дисциплин, то процесс проектирования часто затрагивает сразу несколько уровней, как игла швейной машинки проходит несколько слоев, чтобы их сшить.

При внедрении технологии продуктовой разработки необходимо выявлять жизненный цикл артефактов и порядок перехода между ними в процессе проектирования. Иногда даже небольшая настройка способна сэкономить существенную часть бюджета. Например, при проектировании систем со сложным пользовательским интерфейсом лучше не прорабатывать все детали сразу, а отдать первоначальные эскизы экранов на экспертизу разработчикам. Их уточнения, что технически возможно реализовать, а что нет, избавят от большого количество переделок на стадии реализации.

В отличие от методологии, задающей принципы работы, технология определяет конкретный набор артефактов, процесс работы над ними и инструменты для проектирования и разработки. Это еще один аспект технологии, который нужно учитывать при внедрении. Кроме вопросов удобства и эффективности инструментов, нужно учитывать их стоимость и популярность. Последнее важно, когда речь заходит о доступности специалистов с нужными компетенциями.

К инструментам относятся не только специализированные программы, например, Figma, но и различные методики. JTBD, например, отлично работает на функциональном и бизнес-уровне, помогает выявлять требования к продукту во время подготовки концепции. Scrum используется на более поздних стадиях, когда выполнено детальное проектирование и происходит переход к разработке, давая команде возможность двигаться спринтами уже внутри отдельной стадии.

Технология продуктовой разработки по «Методу параноика» не заменяет подобные методики и фреймворки, а создает общее пространство для разных инструментов, эффективных в зависимости от стадии или уровня проекта.

Проектная команда и управление

Работа над проектными артефактами, поиском идей и превращением гипотез в решения, не происходит сама по себе. Этим занимаются члены проектной команды. Чтобы сформировать такую команду, проджект-раннеру и другим ключевым участникам нужно понимать ее устройство и требования к специалистам, из которых она состоит.

В типовых проектных подходах при формировании команды принято идти от ролей, предполагая, что этого достаточно для получения результата. Технология продуктовой разработки разворачивает эту связь на 180 градусов и в качестве отправной точки использует модель продукта. Действительно, если для создания продукта нужна модель, состоящая из разных артефактов, то за каждый из них должен кто-то отвечать.

Невозможно определиться с требованиями к составу команды, пока не ясна структура модели продукта. Как только это определено, можно выявлять роли участников. Общее правило состоит в том, что в проекте не может быть ни одного артефакта, за который никто не отвечает. В противном случае, как вы помните, не получится создать полную картину продукта.

Изначально можно опираться на типовой набор артефактов и ролей, но только для того, чтобы потом уточнить их исходя из потребностей конкретного проекта, либо его типового формата в рамках проектного офиса. «Черная» книга описывает технологии продуктовой разработки по «Методу параноика» и дает такие «пресеты», но и в этом случае нужна индивидуальная настройка. В конце концов, над проектом работают люди, и их личные качества не всегда совпадают с типовыми ролями.

Если говорить более строго, в рамках технологии роль участника определяет его область деятельности с привязкой к уровням проекта, полномочия в принятии решений, которые выражаются в том числе в артефактах, условиях мотивации и ответственности за результаты работы. Не стоит думать, что одна роль всегда связана с одним уровнем, например, функциональным или техническим. Большинство ключевых участников работают на стыке дисциплин. Например, роль, которую обычно принято называть менеджером продукта, отвечает за объединение решений сразу на трех уровнях – функциональном, интерфейсном и техническом.

Кроме областей деятельности и ответственности за артефакты, технология задает правила организации работы. В гибких командах управление не директивное, когда одни роли подчиняются другим, а происходит через влияние результатов одного участника на работу других. Здесь есть иерархия уровней модели продукта, а не людей. Область деятельности участника дает ему полномочия в принятии решений. Это важно при работе над уникальными продуктами, где нет и не может быть полномочий без компетенций и ответственности.

Отдельно хочу остановиться на роли проджект-раннера, ведь он носитель технологии и с него начинается ее развертывание в рамках конкретного проекта. Его уникальность в том, что он связан со всеми уровнями проекта скорее как идеолог и координатор, нежели специалист, непосредственно выполняющий технические задачи. Его основной инструмент – это «тиски», зажимающие пространство решений об устройстве продукта между бизнесом и организационным уровнем. Его цель – коммерциализация продукта: внутри компании, при создании тиражируемого продукта или при разработке на заказ.

Оценка и планирование работ

Последний компонент технологии продуктовой разработки дает участникам инструменты для оценки и планирования работ. Без них нельзя говорить о подходе, позволяющем работать над уникальными проектами. Они полны неопределенности, и если нет возможности взять ее под контроль, то и получить необходимый результат не получится.

Обычно под способом оценки подразумевается та или иная схема, которая позволяет предсказать трудозатраты при реализации проекта. Часто это носит либо эмпирический характер, когда исполнители сами дают прогноз, либо опирается на статистику похожих проектов. Но если мы имеем дело с чем-то принципиально новым, то у нас нет ни статистики, ни достоверных прогнозов специалистов. Хотя отдельные задачи могут быть похожи, их сочетание и процесс поиска новых решений уникальны.

Для планирования работы в таких условиях используется метод инверсной оценки. Он базируется на принципе распределения задач по уровню неопределенности на разных стадиях проекта. Сначала решаются концептуальные, но менее предсказуемые задачи, затем прикладные и более прогнозируемые. Соответственно, на первых стадиях определенность в оценке может достигаться только за счет внешних ограничений в сроках и бюджете. На более поздних стадиях происходит инверсия, и источником определенности становятся найденные внутри проекта решения.

Этот метод противоположен традиционным подходам, когда бизнес запрашивает у потенциальных исполнителей оценку еще до начала проекта. Обычно это приводит к тому, что компании-подрядчики предлагают работать по схеме T&M. При кажущемся удобстве у этого есть последствия: без четких внешних ограничений нет ясных приоритетов, и одна и та же задача может быть решена разными способами, влияющими на стоимость и характеристики продукта. Кроме того, у бизнеса нет фиксированных границ по срокам и бюджету, позволяющих понять, что команда затягивает проект.

В четвертой главе задается базовый принцип, который звучит так: скорость уменьшения неопределенности должна быть выше скорости исчерпания бюджета и сроков. Если бизнес не обозначает границы доступных ресурсов, вытекающих из экономической целесообразности проекта, то в проекте нет критериев для оценки динамики снижения неопределенности.

Очевидно, что все стадии проекта нельзя оценивать одинаково, не учитывая уровень неопределенности. Технология продуктовой разработки определяет формат планирования и оценки для каждой стадии индивидуально. В общем случае первые стадии проекта должны иметь фиксированные оценки и быть посвящены концептуальным и системным задачам. Последующие стадии, направленные на детальное проектирование и реализацию, могут использовать T&M и опираться на привычные способы планирования, так как они будут базироваться на достоверных данных.

Граница между внешней и внутренней определенностью задается в рамках конкретного применения технологии. Например, важно определить соотношение между общим доступным сроком реализации и временем на поиск концепции продукта. Иногда это 10 %, иногда 30 %, в зависимости от отраслевой специфики и типа проекта. То же относится и к детальному проектированию и реализации. Разные технологические среды диктуют свои подходы к инструментам оценки отдельных задач.

Внедрение технологии и «Черная» книга

Независимо от того, создаете ли вы конкретный продукт внутри своей компании или запускаете проектный офис для выпуска тиражируемых решений на рынок, вам потребуется технология продуктовой разработки. Она повышает шансы на успех в условиях неопределенности, которой и так достаточно в любом проекте. В противном случае придется бороться не только со сложностью задачи, но и с плохой организацией проекта.

Общий алгоритм настройки технологии следующий:

• определить базовый тип проекта и его основные характеристики, включая критерии успешного выполнения;

• подобрать набор стадий («нарезать» воронку неопределенности);

• выявить уровни проекта (настроить «тиски»);

• определить структуру модели продукта и шаблоны артефактов (из чего собирается «пазл»);

• построить цикл работы над моделью в рамках каждой стадии (в каком порядке собирается «пазл»);

• выявить роли ключевых участников и их зоны ответственности (кто за какие части «пазла» отвечает);

• подобрать параметры для инверсной модели оценки и планирования (найти точку перехода от внешней определенности к внутренней).

Быстро выполнить такую работу нельзя, каждый шаг требует тщательной настройки с учетом специфики компании, проекта и людей. Иногда нужно пройти несколько проектов, чтобы сформировалась оптимальная схема. Для получения работающей технологии у вас есть несколько вариантов: пригласить готовую команду, которая сама является носителем такой технологии, настроить самостоятельно с нуля методом проб и ошибок или адаптировать уже отработанные варианты с помощью методолога.

На создание продуктовой разработки по «Методу параноика» у меня ушло больше 20 лет практической работы. Мы с коллегами ставили эксперименты на себе и на других, разрабатывали тиражируемые цифровые продукты и делали их на заказ для разных компаний. Продюсерская модель управления, описанная в этой книге, родилась из этого опыта и объединила различные подходы в рамках общей методологии.

Последние несколько лет, после выхода первого издания «Красной» книги, я с командой консультирую компании, помогая им настроить процессы в проектах. Это привело к необходимости собрать материалы и наработки в формате, позволяющем быстро перейти от методологии к практическому использованию. Так появился замысел «Черной» книги.

Описание технологии сейчас доступно онлайн

Этот ресурс регулярно дополняется по мере того, как «Метод параноика» находит применение в разных компаниях. Моя задача – дать ключи для понимания технологии через примеры, представить разные «пресеты» для быстрого развертывания, шаблоны проектных артефактов, карты ролей участников и базовые параметры для оценки и планирования проектов.

Помимо онлайн-ресурса, планируется подготовка бумажного издания, которое должно стать своеобразной настольной книгой проджект-раннера.

Москва, 2024

Примечания

1

Источник: https://habr.com/ru/post/388699/.

Content

Вадим Митякин
Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

Пролог

В ловушке предсказуемости

Цифровые продукты в бизнесе

Что такое «Метод параноика»

Проджект-раннер и продюсерская модель управления

Области применения метода

История создания метода

Структура книги

Что изменилось во втором издании

Благодарности

Глава 1 Цифровые продукты в бизнесе

Технологии необходимы, но недостаточны

Цифровые технологии в бизнесе

О важности бизнес-инфраструктуры

Критерии успешности продукта

Как искать технологические решения для бизнеса

Точка отсчета

Мобильные приложения

Голосовые интерфейсы и искусственный интеллект

Отраслевые концепты

Дилемма бизнеса и IT-специалистов

Глава 2 Как устроена индустрия создания цифровых продуктов

Зачем нужно знать устройство IT-индустрии

Типы проектов

Форматы работы

Экономика проектов

Бизнес-модели

Приходы и расходы

Экосистема IT-индустрии и продюсирование проектов

Глава 3 Оценка проектов, планирование и неопределенность

Кто прав: бизнес или специалисты?

Почему невозможно точно оценить проект

Что делать с неопределенностью в проектах

Тип проекта как индикатор уровня неопределенности

Бизнес на пороге кардинальных изменений

Новое направление в бизнесе или стартап

Работающий бизнес, развивающий свои цифровые сервисы

Типы проектов в жизненном цикле развития бизнеса

Бизнес и цели проекта

Живое воплощение неопределенности, или выбор специалистов для работы над проектом

Тендерные процедуры

Критерии выбора исполнителей для управления неопределенностью

Ограничения традиционных подходов к управлению проектами

Слабая вовлеченность бизнеса в проектную работу

Навязываемые сроки

Большие релизы в стиле «все и сразу»

Проект без капитана

Проектирование и неопределенность

Негативная эволюция

Новое время и неопределенность

Документация

Проектирование и бизнес

Итог

Глава 4 Принцип контроля неопределенности

«Метод параноика» и продюсирование проектов

Как взять неопределенность под контроль

Цели бизнеса

Понимание того, каким должен быть продукт

Выбор специалистов, необходимых для работы над проектом

Организация проектной работы

Ресурсы, необходимые для реализации проекта

Воронка неопределенности

Принципы метода

Принцип проектирования

Принцип гибких команд

Принцип продюсирования

Принцип сериала

Принцип вовлеченности бизнеса

Описание принципов

Глава 5 Принцип проектирования

Сложные системы должны быть спроектированы до реализации

Новая роль проектирования

Первое правило: каждое решение должно уменьшать неопределенность

Второе правило: каждое решение требует своего уровня абстракции, компетенции и ответственности

Третье правило: все решения должны быть связаны

Проектировщик – генеральный конструктор продукта

Глава 6 Кодекс проектировщика

Насмотренность, исследования, мастерство

Насмотренность проектировщика

Как работает штанга Талеба

Штанга для контроля неопределенности в проектах

Стратегия штанги для профессионального развития

Поиск источников информации

О ценности первоисточников

Экспедиции в мир других

Аналитика ≠ проектирование

Для чего нужны исследования в проектировании

Извращенная корпоративная модель использования исследований

Для чего нужны исследования в вашей профессиональной жизни

Личная история исследования голосовых систем

Как классический маркетинг мешает договориться с бизнесом

Продюсирование как альтернативная модель работы в IT-отрасли

Глава 7 Принцип гибких проектных команд

Команды в разных типах проектов

Сила и слабость фиксированных команд

Выбор участников гибких команд

Проектирование проектных команд

«Железобетонное» правило

Правило многоуровневой команды

Правило предварительной проверки команды

Управление гибкими командами

Коммуникации между участниками

Глава 8 Принцип продюсирования

Продюсирование проектов и роль проджект-раннера

Между Сциллой и Харибдой

Функции проджект-раннера

Трансформация бизнеса через цифровые технологии

Ложная дилемма предпринимателя

Кто должен заниматься сексом с вашей женой

Доверенное лицо бизнеса

До цифрового продукта

Цифровой продукт обретает конкретные черты

Неопределенность в тисках ограничений

Баланс вместо компромисса

Скрепы проектного бутерброда

Организация проектной работы

Творчество против определенности

Жизненный цикл гибкой проектной команды в продюсерском подходе

Шкура проджект-раннера на кону проекта

Цена привлечения проджект-раннера

Сочетание интересов бизнеса и специалистов

Как стать проджект-раннером

Глава 9 Принцип сериала

Замкнутый круг прогнозирования

Оценка проектов типа «Мозги»

Решение уравнения от обратного

Как принцип сериала берет под контроль неопределенность

Организация проектов типа «Мозги»

Контрольные точки проекта

Гибкие проектные команды и продюсерский подход

Модель продукта

Фирменный проектный процесс

Проект как выпуск эпизодов сериала

Концепция продукта

Цель стадии и характер работ

Требования к участникам

Способ оценки и планирования

Критерий прохождения контрольной точки

Модель продукта

Высокоуровневое проектирование

Цель стадии и характер работ

Требования к участникам

Способ оценки и планирования

Критерий прохождения контрольной точки

Модель продукта

Детальное проектирование

Цель стадии и характер работ

Требования к участникам

Способ оценки и планирования

Критерий прохождения контрольной точки

Модель продукта

Разработка

Цель стадии и характер работ

Требования к участникам

Способ оценки и планирования

Критерий прохождения контрольной точки

Модель продукта

Глава 10 Принцип вовлеченности бизнеса

Ответственность бизнеса

Действующий бизнес

Стартапы

Customer Development и архитектура бизнеса

Глава 11 Технология продуктовой разработки

Применение метода на практике

Области применения технологии

Заказная разработка

Внутреннее использование продуктов

Тиражируемые продукты

Индивидуальная настройка технологии

Воронка неопределенности и стадии проекта

Модель продукта и проектирование

Проектная команда и управление

Оценка и планирование работ

Внедрение технологии и «Черная» книга

Примечания