После перехода из роли портфельного проджекта (PM) на роль портфельного продакта (тоже PM), как оказалось, границы для ролей полностью теряются, и из двух ролей превращаются в одну. Новая роль называется ИТ-выживальщик, из приятного - роль дополняется куполом цирка и клоунским носом. Выбираться из роли выживальщика можно, и более того, нужно. Собственно, статья о том, как я это пробую делать.
Роль 1: Проектная
PM по PMBoK: всеми любимые сроки, бюджет и содержание. Рисуем ганты, риски держим в голове (крайне не рекомендуется), еженедельные светофорные статусы "красный-жёлтый-зеленый" и все уверены, что мы там чем-то управляем, после такого пакета визуала, как правило, руководители могут снизить напор и дать возможность реально работать.
Под реальной работой имеется ввиду работа с командой, наставничество, воркшопы, конфликты и их решения, управление ожиданиями заинтересованных сторон, риски, освоенный объем и остальные задачи, которые действительно нужно отрабатывать. Таким образом, вся эта, мало волнующая руководство "суета", которая прямым образов влияет на стратегические цели, становится доступной к выполнению. Флаг в руки, дальше решают ваши реальные навыки и знания.
Два классических контура фактической и формальной работы - довольно понятны, если научиться временно отключать оценку на здравый смысл, которая необходима во время фактической работы, то внутренний конфликт скорее будет фоновым, и работать вполне себе можно, не исключается возможность показывать реальные результаты.
Из личной практики: если проект проваливается, и на проекте 2 человека на обе роли, продакт и проджет, то спрашивать всегда будут с проджекта. При том, что спрос будет и за баги, и за 2х часовые летучки, и за приоритеты разработки, и за содержание спринтов.
Роль руководителя проекта (Project manager) и ее проекция на портфель - мои основные роли. Самые близкие и уже родные. По этой ветке я дошел до портфелей и статуса PMP. Остается продвигаться только по масштабу проектов или портфелей, что на данный момент довольно сложно, рынок практически не предлагает масштабные проекты, так что ждем лучших времен в продуктовом контексте.
Роль 2: Продуктовая
PM по Agile/Scrum/Kanban: не про дедлайны, а про ценность пользователю, команду и метрики. Хотя на деле, нужно написать "типа как" не про дедлайны, "типа как" про пользователя и что-то там про команды с метриками.
Роль понятная на уровне исполнителя (т.е. нам с вами), а на уровне представления руководства - карикатура не пойми чего и на что. Я уже писал про Agile-театр, думаю, это самая подходящая фраза.
Тут уже гораздо сложнее отделаться визуалом, хотя пробовать и искать как - нужно. Из проблем - быстрые победы тут показать сложнее, так как нормальный продакт опирается на факты и метрики. Плюсом, его задача подсвечивать, что вообще-то у нас есть пользователи и клиенты, на которых нужно ориентироваться, что часто не подходит под культуру компании.
Если говорить прямо, то продактам должны платить за то, что они хорошо работают. Но руководство не может оценить хорошую работу продакта, так как это прямые затраты без всеми любимых проектных ограничений. Так что привязываемся к метрикам выручки, притягиваем к этому прямой путь от каждого действия (даже проведения воркшопа с командой) - к выручке. После чего, есть вероятность, что появится пару часов в день на фактическую работу.
Из личной практики: тут как раз обратная проблема, если около вашего продукта нет проджекта, то вся его работа будет падать на вас. Из моего любимого - это производственный план на вывод продуктов в рынок, или нормирование на поток проверки гипотез.
На самом деле - поганая роль. На клиентов на нашем рынке практически не ориентируются. Приходится заниматься фактической работой в не рабочее время и упираться в сопротивление всех смежных подразделений и руководителей. Либо по глупости, либо из-за недопонимания, либо из-за сложности признать, что рынок диктует правила игры - клиентов не ставят в приоритет. Задача найти ценность, чудесным образом превращается в задачу - всучить ценность. Остается только держаться за привязку к выручке и попыткой доносить, как и кто на нее влияет, пока, эта самая выручка (а еще лучше прибыль) не перевесит затраты на содержание вашей продуктовой команды, после чего от вас отстанут на какое-то время и дадут немного поработать.
Роль 3: Гибридный выживальщик
Тут сразу спойлер: в России не бывает чистого продакта или проджекта, если речь идет про ИТ‑направление, то чаще всего по принципу «зачем платить больше», обе роли запихиваются в одного сотрудника.
Говоря про гибдир, я не имею ввиду подход к управлению проектом, речь именно про культурно‑смысловую составляющую этих ролей, то есть что и как нужно делать, а главное, с какой целью.
На этой роли начинается чистый цирк, для примера, внедрение регламентов работы для продуктовой команды (функции каждого сотрудника и КПИ на них), количественные KPI на содержание спринтов, директивный запуск спринтов без участия формирования самого спринта командой и продактом. У меня настолько длинный список серии «например», что хватит на посты по этой теме на весь год.
Слово «гибрид», подразумевает, что нужно взять обе роли, две фактических и две формальных работы. Если у вас 1 проект и 1 продукт — то это еще возможно. Когда речь заходит про портфели, то даже теоретическую возможность уже не разглядеть. Остается делить фактическую работу с формальной более суровым образом.
Как вариант: оставить на фактическом поле, то проектное что связано с бюджетом, то продуктовое, что связано с ценностью для рынка. Максимально автоматизировать формальную отчетность, для этого придется совместить рабочие пространства команды с вашими формами отчетности. Для чего, все равно придется построить прибитые гвоздями процессы. В таком формате из процессов выкидывается все лишнее - никаких дополнительных действий и шагов. Процессы нужно превратить в контрольные точки - тогда у команды все же останется хоть какая-то гибкость и кросс-функциональность. Все управленческо-организационное полностью переводится в режим MVP. Все встречи, которые могут проходить без вас - проходят без вас.
Как особый вид изощрений - привязывать OKR к Ганту и срастить процессы управления проектом с жизненным циклом управления продуктом на уровне артефактов. Но такие вещи стоит делать только если вы работаете с околонаучной средой.
После всех этих, абсолютно не влияющих на стратегические цели изощрений, у вас может появиться пару минут в день на фактическую работу. При всей моей нелюбви к продуктовым театрам в наших реалиях (хотя сама идея мне нравится), в такой ситуации ставку лучше сделать именно на продуктовой культуре. Так как имея пару минут в день на реальную работу, надежда остается только на продуктовые команды, которые вывезут на себе привязку к выручке и содержательную часть, что откроет возможность постепенно отказываться от проектных раундов финансирования и в конце-концов заняться нормальной работой)
П.С. я прекрасно понимаю, что в мире теории есть только "портфель". Проектные или продуктовые портфели не приветствуются. Еще я понимаю, что можно было использовать сокращения CPO или PMO, на крайний случай, PM и PJM. Но фактическое состояние дел, говорит, что никакие условные обозначения не работают на прикладном уровне. Обозначения PM (Portfolio manager) для разных по содержанию портфелей, выбрано не случайно, оно полностью гармонирует с полной кашей на этих ролях.
О фактической работе, и личных активностях пишу в своем канале, кому близко вышеописанное - присоединяетесь буду рад https://t.me/PevnyiProject
