Проектный vs продуктовый подход в управлении

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

Итак, что такое проектный подход и когда мы его можем применять?

Подходы к управлению БС

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

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

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

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

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

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

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

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

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

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

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

Подходы к управлению

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

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

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

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

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

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

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

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

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

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

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

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

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

И здесь сидит кто? Владелец процесса, который точно знает: если у нас происходит критический инцидент на одной из цепей, то кто виноват? Система, процесс. Не люди.

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

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

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

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

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

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

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

Во-первых, это собрать компетенции. Вы знаете, сколько сегодня стоит хороший руководитель проекта? Он стоит хорошо. Слишком хорошо, чтобы это было правдой. Потому что он должен сегодня знать все подходы, которые есть: линейные, нелинейные, чем отличается Scrum от Kanban и так далее. Еще вышли новые, PMBOK восьмой, например, и все такие: «Чем он отличается?» Да ничем, но он должен об этом знать.

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

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

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

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

А вот наличие руководителя проекта как должности и роли – да. Если у вас такой роли нет, то, скорее всего, проектного управления у вас тоже как такового нет. Ну и, конечно, наличие стандарта.

Вам подходит проектный подход?

1. Наша основная деятельность состоит из временных инициатив с четко определенными началом и концом.

2. Успех измеряется достижением конкретных целей проекта (сроки, бюджет, объем работ), а не долгосрочными бизнес-метриками продукта.

3. Ресурсы (команда, бюджет) выделяются и контролируются строго в рамках конкретной инициативы.

4. Наше взаимодействие внутри команды обусловлено задачами проекта и часто меняется от проекта к проекту.

5. У нас есть выделенная роль «Руководителя проекта» (Project Manager) или четко описанная проектная функция.

6. Мы регулярно работаем с ограниченными сроками (дедлайнами) и четким планом работ.

7. Наш результат часто представляет собой разовый «орган» – внедренную систему, построенный объект, завершенное исследование.

8. Наша организационная структура – проектная или ярко выраженная матричная, где сотрудники подчиняются руководителю проекта на время его выполнения.

9. Мы фокусируемся на эффективности выполнения конкретной задачи (TPI), а не на оптимизации жизненного цикла чего-либо.

10. После сдачи результата и закрытия проекта наша команда обычно расформировывается или переводится на новую задачу.

Продуктовый подход: организационная структура и ключевые критерии

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

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

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

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

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

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

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

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

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

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

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

Кто разрабатывает глубокую, длинную, дотошную Customer Journey Map – карту клиента, карту пути клиента, точки контакта клиента с продуктом? Мало кто. Подумайте об этом. Это очень интересное мероприятие.

Что такое путь клиента? Это то, что лежит в основе продуктового подхода. Если у вас нет карты пути клиента, то нет у вас продуктового подхода.

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

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

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

Вам подходит продуктовый подход?

1. Наша основная деятельность сосредоточена на долгосрочном развитии и поддержке конкретного продукта или сервиса.

2. Успех измеряется показателями на протяжении всего жизненного цикла продукта (прибыль, удовлетворенность клиентов, доля рынка).

3. У продукта есть постоянная кросс-функциональная команда, которая несет за него ответственность.

4. Взаимодействие между функциями (разработка, маркетинг, продажи) тесное и постоянное, так как все они связаны общим продуктом.

5. У нас есть четкая роль «Менеджера по продукту» (Product Manager), который определяет стратегию.

6. Продуктовая стратегия является ведущей для нашей компании или нашего направления.

7. Наш результат – это постоянно развивающееся «лицо и тело» компании, которое видят клиенты.

8. Наша организационная структура сформирована вокруг продуктов, а не функций или проектов.

9. Мы фокусируемся на сквозных процессах, обеспечивающих жизненный цикл продукта, от входа (идея) до выхода (доставка клиенту).

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

Заключение

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

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

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

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

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

Зачем вам этот руководитель проекта, зачем ему платить? Не понимаю. Миллион? Или 500 000 даже? Уже подумали: «А может, и в проектное перейти?» Поэтому нет, риски есть. И они финансовые и абсолютно исчисляемые.

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

Если владелец продукта – это проектная роль, то менеджер по продукту – это продуктовая функция, продуктовая должность. Поэтому имейте это в виду.

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

И то же самое говорите, если вы менеджер по продукту. Говорите: «Я не менеджер по продукту, это стоит в десять раз больше, поэтому, пожалуйста, давай разберемся как-то, кто я есть».

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.