Подход с использованием проектной документации как среды для коммуникаций применим на всех стадиях проекта, от разработки концепции продукта до его стабилизации на этапе запуска и поддержки. В роли такой среды могут выступать разные типы артефактов проектирования: дизайн интерфейса, программные спецификации, архитектурные схемы, диаграммы активности и прочее. При правильном структурировании, когда все материалы связаны общей системой, у каждого участника проекта перед глазами есть общая картина и возможность легко найти нужную информацию.
Соединяя формат коммуникаций, основанный на документации, и гибкую организацию проектной команды, в которой изменения происходят в моменты прохождения контрольных точек, можно прийти к еще одному механизму ведения проекта. Речь о защите результатов. Если вы помните, в середине главы я настаивал, что при принятии решений участник должен нести за них ответственность. Одним из способов воплотить эту идею в жизнь является правило, что работа не считается выполненной, пока те, кто воспользуются ее результатами, не подтвердят, что они могут это сделать. Согласитесь, вряд ли можно с уверенностью утверждать что-то, основываясь на мнении только одной стороны.
Пока идет работа в рамках стадии проекта, авторы артефактов вольны видоизменять их по своему усмотрению, вовлекая всех остальных в обсуждение. Когда же проект приближается к очередной контрольной точке, чтобы перейти на следующую стадию, например, от концепции к проектированию или от одной итерации разработки к другой, результаты работы необходимо защитить перед командой следующей стадии проекта.
Суть защиты заключается в проверке всех решений на соответствие трем правилам принципа проектирования: каждое решение в проекте уменьшает, а не увеличивает неопределенность; каждое решение в проекте требует своего уровня абстракции, компетенции и ответственности; все решения в проекте связаны между собой. Подтвердить это в полной степени могут только те участники, кто принимает эстафету проекта. Причина в том, что ответственность в гибких командах локализована в небольших группах, образующихся вокруг ключевых участников, и защита результатов служит способом передачи ответственности между ними. Таким образом обеспечивается непрерывный жизненный цикл проекта, состоящий из периодов подготовки, защиты и использования решений, в том числе на организационном уровне.
Глава 8Принцип продюсирования
Структура главы:
• Продюсирование проектов и роль проджект-раннера
• Трансформация бизнеса через цифровые технологии
• Цифровой продукт обретает конкретные черты
• Организация проектной работы
• Как стать проджект-раннером
Продюсирование проектов и роль проджект-раннера
Между Сциллой и Харибдой
Настал момент уделить внимание главному персонажу этой книги – проджект-раннеру. Согласно принципу гибких проектных команд, в «Методе параноика» процесс принятия решений распределен между ключевыми участниками. Они отвечают за отдельные подсистемы или уровни абстракции цифрового продукта. Таким образом ключевые участники образуют «несущую конструкцию» проектной команды. Каждый из них ориентирован на техническое лидерство и координацию своей локальной рабочей группы. Как следствие, управление проектом происходит параллельно на всех уровнях с участием именно тех людей, кто обладает максимальным уровнем понимания вопросов.
Поскольку любая система или подсистема состоит из частей разной природы, то для работы над ней ключевому участнику проекта необходимо иметь компетенции в каждой из ее частей. Такие высокие требования к специалисту оборачиваются преимуществом, т. к. только на стыке дисциплин рождаются по-настоящему классные решения. Как нетрудно догадаться, среди участников проекта должен быть тот, кто смотрит на цифровой продукт на самом высоком уровне абстракции, включающем все его аспекты. Тот человек, который, работая с бизнесом, инициирует процесс понимания того, каким будет продукт, и кто те специалисты, которые должны будут участвовать в его создании. Тот, кто станет отправной точкой проекта, зерном, из которого вырастает команда.
Чтобы такой формат работы стал возможным, принцип продюсирования связывает остальные четыре принципа из пяти – проектирование, гибкие команды, сериал и вовлеченность бизнеса. По отдельности они, хоть и эффективные, но все же только инструменты, и должен быть кто-то, кто сможет их использовать. В «Методе параноика» эту роль выполняет проджект-раннер. Что интересно, принцип продюсирования, в отличие от остальных принципов метода, не устраняет напрямую ни один источник неопределенности, но зато наделяет плотью того, кто проводит в жизнь идеи других четырех принципов и создает возможность их воплощения на практике.
Что же отличает проджект-раннера от типичного менеджера проекта, а вместе с ним и продюсерский подход от классических методов ведения проектов? Разница в том, что проджект-раннер участвует в формировании концепции цифрового продукта, а не просто исполняет поставленную бизнесом задачу. Он обладает достаточными компетенциями для управления проектной работой, не ограничиваясь ролью идеолога продукта. Это основополагающее различие, которое делает проджект-раннера в глазах проектной команды представителем компании-заказчика, а в глазах бизнеса – партнером, помогающим найти технологическое решение. Еще одно отличие проджект-раннера состоит в понимании, для чего он занимается проектом.
Бизнес-модель любой компании всегда строится вокруг инструментов. Сегодня их роль все чаще выполняют цифровые продукты, без которых работа современных компаний невозможна. При создании нового бизнеса или трансформации компании нужен визионерский взгляд предпринимателя, чтобы увидеть возможность использования цифровых технологий для новой модели работы. Но одного видения для команды разработки недостаточно. Нужен тот, кто, обладая предпринимательскими качествами и знанием технологий, найдет решение бизнес-задачи в виде цифрового инструмента. Другими словами, тот, кто свяжет бизнес и специалистов в едином проекте.
Принцип продюсирования задает правила, по которым строится такая работа. Прежде всего данный подход нужен для ведения проектов типа «Мозги», где изначально не определены ни его параметры, ни способ решения задачи. Сначала требуется сформулировать концепцию продукта вместе с бизнесом, затем собрать команду под конкретный проект, передать участникам видение продукта и провести их через все стадии вплоть до запуска. Разделять функции создания концепции и дальнейшего контроля над реализацией продукта между разными ролями нельзя, так как при этом будет размыта ответственность проджект-раннера, который должен правильно расставлять приоритеты и учитывать все важные факторы на этапе проектирования.
Для других типов проектов продюсерский подход может быть избыточным. Проекты типа «Седина» предполагают, что решение задачи уже существует, и цель проекта – правильно его применить. В этом случае проектная команда выступает носителем знаний, а состав ролей специалистов подбирается под выбранное решение. Проекты типа «Процедуры» тоже могут обойтись без проджект-раннера, поскольку не требуется искать решение, связанное с изменением бизнес-модели компании. Работа направлена на доработку существующих цифровых инструментов. В таком случае можно использовать общепринятые подходы с привлечением аналитика, проектировщика и менеджера проекта.
Тем не менее здесь присутствует интересный момент. В проектах типа «Мозги» часто есть смысл использовать уже готовые наработки и технологии, а также вносить изменения в действующие системы. Поэтому все три типа проектов могут быть объединены для решения одной большой бизнес-задачи, и проджект-раннер должен скоординировать их работу. Все это только подтверждает идею из второй главы о том, что индустрия создания цифровых продуктов – экосистема дополняющих друг друга компаний, команд и отдельных специалистов.
Во второй главе мы рассмотрели понятие форматов работы, представленных в виде персонажей и названных по аналогии с медицинскими ролями, и впервые ввели понятие проджект-раннера. Настало время вернуться к этой концепции. По сути, продюсерский подход ближе всего к формату «Психотерапевта», так как предполагает постоянное общение с бизнесом и требует доверительных партнерских отношений. Задачи носят сложный и даже неопределенный характер, так что их нельзя поручить простым исполнителям. В то же время проджект-раннер не решает все задачи самостоятельно. Основные участники проектной команды и внешние специалисты могут выступать в ролях «Фармацевтов» (команды специалистов с типовыми компетенциями в разработке, дизайне и т. д.), «Сиделок» (маркетинговые и рекламные агентства) и даже «Нейрохирургов» (системные интеграторы, высококлассные профессионалы и уникальные креативные студии).
Вообще тема состава команды проекта крайне важна для понимания принципа продюсирования. Многие компании для своих проектов привлекают внешних участников, но относятся к этому скорее как к исключению. «Метод параноика», наоборот, всячески этому способствует и рассматривает такой способ как норму. Внутри одной компании невозможно собрать всех сотрудников, необходимых для уникального проекта. Во-первых, для работы нужны участники с разными и порой неожиданными компетенциями. Во-вторых, без крутых специалистов невозможно найти нестандартные решения. Эти профессионалы нацелены на интересные задачи и участвуют в разных проектах. Одна компания, какой бы она ни была, не сможет дать им такой возможности. К тому же цель проектов типа «Мозги» – привнести в компанию что-то новое, чего нет внутри, и для этого нужны люди со свежим взглядом.
Есть еще один важный аспект, связанный с внешними и внутренними участниками проекта. Проджект-раннер отвечает за результат проекта и должен иметь полномочия, включая право менять состав команды по своему усмотрению. Теоретически здесь нет проблем, но на практике бизнес часто не готов к такой гибкости и может настаивать на участии конкретных сотрудников. В случае же с внешними участниками подобный вопрос, как правило, не возникает.
Надо отдать должное историческому моменту, который мы проживаем. Тенденции были и раньше, но эпидемия COVID-19 и спровоцированный ею переход к удаленной работе изменили взгляд на вопрос найма. Теперь распределенные команды, работа вне офиса и привлечение специалистов под конкретный проект не считаются неприемлемыми даже для ответственных проектов внутри корпораций.
Если вернуться к первоначальному утверждению, что проджект-раннер находится на стыке между бизнесом и проектной командой, то из этого следует необходимость разговаривать с каждой из сторон на понятном языке. Этим языком является проектирование, но с разным диалектом. Для бизнеса это больше концептуальный взгляд на цифровой продукт и его связь с процессами в компании, а для специалистов – детализированная модель с упором на особенности реализации.
Одновременно со способом коммуникаций, проектирование в руках проджект-раннера также выступает в роли инструмента и позволяет определить, какие специалисты нужны и когда они должны включиться в работу, как это следует из принципа гибких проектных команд. Постепенно формируемая модель цифрового продукта в данном случае выполняет роль карты, которая с каждым шагом точнее определяет границы проекта и маршрут к финальной точке.
Идея ответственности завершает образ проджект-раннера. Будучи ключевым участником проекта, он не выполняет формальную роль исполнителя как менеджер продукта, администратор или проектировщик. Поскольку проджект-раннер рассматривает продукт на высшем уровне абстракции, это требует от него соответствующей компетенции и ответственности. Каждый уникальный проект для высококлассного специалиста – способ профессиональной реализации, что предполагает максимальную вовлеченность, без которой работа над подобными проектами невозможна. Награда может быть высока, но за нее нужно платить, в том числе тем, что часть рисков проекта проджект-раннер берет на себя.
Функции проджект-раннера
Если суммировать сказанное выше, то можно выделить три ключевые функции проджект-раннера, а вместе с ними и правила принципа продюсирования. Первая функция – найти способ решения задачи бизнеса с использованием цифровых инструментов. Область поиска не ограничивается технологиями и затрагивает все аспекты деятельности компании, это всегда совместная работа проджект-раннера с первыми лицами. Конечная цель – формулирование принципиальной схемы решения и выстраивание обновленной бизнес-модели в связке с продуктом.
Вторая функция – определить наиболее подходящий способ воплощения найденного решения в форме цифрового продукта. В «Методе параноика» используется подход, основанный на выявлении ограничений, которые определяют границы возможных вариантов реализации проекта. Ограничения или факторы, влияющие на устройство продукта, разнообразны, от бюджета и сроков до технологических возможностей. Если по отдельности они могут быть учтены каждым участником проекта, то собрать их вместе может только проджект-раннер. Его задача в том, чтобы, отталкиваясь от принципиальной схемы решения, создать первоначальное видение цифрового продукта, которое совместно с ключевыми участниками детализируется и превращается в полноценную модель продукта. Все это становится надежным способом для проверки гипотез, обсуждения и последующей передачи проекта в разработку.
И, наконец, третья функция заключается в организации проектной работы. Обратите внимание, что здесь акцент сделан на «организации», а не на «управлении». Задача проджект-раннера – выявить требования к проектной команде, подобрать подходящих специалистов и запустить процесс работы над цифровым продуктом. Управление же входит в само понятие проектного процесса и согласно принципу гибких команд распределено между ключевыми участниками. Проджект-раннер в данном случае выступает в качестве стартера проекта, за которым на сцену выходят остальные участники. Он участвует в проекте на всем протяжении и выполняет роль, которая называется «несущей конструкцией проекта».
На этом заканчивается введение в принцип продюсирования. Дальше я более детально раскрою уже описанные идеи. Для удобства следующие части главы организованы вокруг основных функций проджект-раннера, которые я только что перечислил. Завершает главу часть, интересная для специалистов, достигших потолка в своей профессии и для которых роль проджект-раннера может оказаться следующим шагом в развитии.