psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Задачка-водокачка № 21
psilonsk


Что-то давно не было у нас наших любимых задачек-водокачек. Исправляюсь.)

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

Читаем и отвечаем.

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

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

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

История первая
Венчурная компания с иностранным капиталом и иностранным менеджментом. Делает клон успешного американского сервиса в высококонкурентной нише. Первую версию заказывает у небольшой разработческой конторы в ближнем зарубежье. ТЗ на трех листах А4. Основная фабула ТЗ: "сделайте как у них". Со стороны заказчика работает начинающий менеджер проекта. Я со стороны подрядчика согласовываю состав задач, требования, сценарии и обеспечиваю сдачу пилотной версии в срок. После этого мне предлагают делать второй релиз в Москве. Я соглашаюсь. Переезжаю. Формирую команду разработки и запускаю второй этап. В это время в проект пытаются "вдохнуть жизнь", но особых успехов нет. Бизнес-лидер и СТО проекта уходят. Я с командой разработки продолжаю бороться за проект (все верим в успех), перерабатываем функционал из аналога американского сервиса делаем аналог европейского. Заканчиваются деньги. Начинаются задержки зарплаты. Приглашают нового бизнес-лидера. Он решает, что я не нужен... Проект агонизирует еще полгода после моего ухода и закрывается. Оба экс-менеджера продуктов делают успешные карьерные шаги вперед. Еще через полгода в этом же сегменте с несколько измененной концепцией другие люди делают очень успешный продукт.

История вторая
Крупный медиа-холдинг. Целый департамент интернет-проектов. Покоряем регионы. Региональные проекты очень трудно вкатываются в работу. Сроки срываются, результаты не соответствуют ожиданиям. Меня перебрасывают с внутренних проектов на аудиты и кризисное управление. Летаю за Урал, борюсь за проекты, достигаю определенных успехов, но уже поздно. Начальник отдела развития (куратор этой истории) уходит руководить крупным интернет-сервисом (лидером своей ниши), департамент фактически расформировывают...

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

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

Итак, вопросы:

1. Что делать менеджеру проектов продуктовой разработки, если он не верит в видение менеджера продукта? Есть ли у этого вопроса ответ, отличный от "валить из этой компании"?

2. Что делать, если менеджер продукта уже "ушел на повышение", а менеджера проекта просят довести-таки проект до очередной вехи в плане? (продуктовой экспертизы хватает, но нет большого желания тянуть лямку за ушедшего менеджера продукта).

3. Имеет ли какой-то смысл в этих реалиях приходить на новые проекты с ожиданиями вырасти вместе с проектом или же стоит "делать что должен, и будь что будет"?



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

Другие задачки-водокачки можно найти по соответствующему тегу.



promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
Общее ощущение - человек перерос менеджера проектов и регулярно порывается лезть (или попадает) в менеджеры продуктов, но де-факто не созрел. Не умеет формулировать свой вижен, продавать его, навязывать вижен команде разработки, искать спонсора.

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

Я бы рекомендовал попробовать самому выступить в роли менеджера продуктов на каком-нибудь не сильно большом продукте и попытаться научиться всему этому.

А теперь можно ответить на вопросы :)

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

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


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

дети так маленькие делают "а я?! а я тоже могу!", но по факту еще не могут

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


1) Ситуация - когда есть и менеджер продукта и менеджер по его разработке - считаю изначально конфликтной. Должно быть единоначалие и единственность ответственности. Если topic-starter "перерос" должность менеджера продукта - пусть узнает предметную область (тот же бизнес-анализ и финансовый анализ), понимает как производить продукт-как-сервис - чтобы он легко и эффективно внедрялся.
2) Во всех перечисленных продуктах - везде какой-то слабый аналитический компонент. "Сделайте как у них" - это чаще всего свидетельство отсутствия собственных проектировщиков, незнание рынка и функционала. И технологии тут второстепенны. Чаще всего "догоняющий" работает по дисконтной схеме - делая "аналогичный" функционал более дешевыми (и разумеется малокачественными) ресурсами. Но в этой экономии - главное знать границы. И не увлекаться «изобретением велосипедов», а глубже изучить – какую же боль и проблему у потенциальных потребителей – решает это ИТ решение . И уже предложить для решения этой проблемы – наилучшее и эффективное программно-техническое решение.

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

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

На эти вопросы и даст ответ «знание рынка» (customer experience), и наоборот – "голая идея", "голый проектный менеджмент" без знания экономики и психологии потребителей, увы, но ничего не стоит.

Edited at 2015-07-08 10:57 am (UTC)

Задачи любого наемного сотрудника это:
1. заработать балбла
2. свалить в другое место с повышением (или с дауншифтом, что тоже надо ясно осознавать)

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

Работать за идею можно (и периодически нужно), но надо точно понимать, что это работа не за деньги.

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

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

Т.е. он сначала берет на себя ответственность за проект, а потом закономерно получает по шапке после его провала.

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

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

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

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

3. если бы он понимал куда он хочет расти, то стало бы понятно как и с какими проектами это делать.

1) при желании можно рассказать свое видение менеджеру продукта. Примет - хорошо, не примет - либо работать по его заветам, либо искать другое место.
2) Дотягивать проект, но сразу оговорить с руководством, что именно дотягивается проект, а не развивается продукт. Либо договариваться на иных условиях. Либо уходить.
3) Вероятность вырасти - ненулевая, я б рисковал.

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

Совет Петру — снизить личную инерцию и деформацию восприятия. Обычно работая над проектом люди убеждают друг друга в его успешности (а некоторые по работе должны делать это) и постепенно начинают верить больше чем следовало — восприятие деформируется: перспективы радужные, препятствия преодолимые. Даже когда внешние условия сильно меняются, то это не сразу осознаётся, включается процесс инерции, и вот вы вроде на пути к релизу, но менеджер уже свалил.

Этот комментарий понравился.

Вы бы еще видели какие его автор пишет программы для эппловских продуктов )

Спасибо за оценку, мне правда приятно :)

>Совет Петру — снизить личную инерцию и деформацию восприятия.

То есть валить вслед за продакт менеджером? И может изначально готовиться уйти за ним?

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

я, вот, раньше думал, что 90-95% процентов проектов проваливается.
а сейчас прочитал и поменял мнение: 90-95% ПРОДУКТОВ проваливается. не работает. ни кому не нужная ерунда. а проекты - проекты этих продуктов могут быть реализованы оч хорошо. почему бы и нет?

"Я с командой разработки продолжаю бороться за проект (все верим в успех), перерабатываем функционал из аналога американского сервиса делаем аналог европейского." Зачем заниматься не своим делом и брать на себя работу и ответственность продакт-менеджера?
"Меня перебрасывают с внутренних проектов на аудиты и кризисное управление" Зачем было соглашаться на этой? и видимо не оговаривать спец.условия? Кризис-менеджеры-это специальные такие люди. У них есть умение это делать.
"То, что было запланировано, сделано и вышло в релиз, а экономического эффекта от этого внезапно нет. Скоро совет директоров." И что? вот сейчас самое время не повторять того, что было раньше. БТ, ФТ есть? согласованы? реализованы? ПСИ пройдено? Какие ещё к вам могут быть претензии? бизнес-эффективность не ваше дело.
Себя нужно грамотно защищать. Это основной скил в нашей деятельности.
1. Верю-не верю-это лирика. Можно обсудить этот вопрос. Но важно помнить, что это не ваша ответственность.
2.Доводить до очередной вехи. Но как менеджер проекта. Выпустил с пром и свободен.
3.Конечно имеет. Думаю у вас всё ок будет.Просто нужно перестать делать всё за всех.

Edited at 2015-07-09 10:48 am (UTC)

если раз за разом результат повторяется - это закономерность. Если все машины едут вам навстречу и бибикают - то скорее всего вы едете по встречке.


Сейчас меня тапками закидают, но выскажусь ) У меня опыта практически никакого нет.

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

1. Что делать менеджеру проектов продуктовой разработки, если он не верит в видение менеджера продукта? Есть ли у этого вопроса ответ, отличный от "валить из этой компании"?
Если с менеджером продукта есть хороший контакт, то попробовать сначала с ним обсудить. Но лучше всего на общем собрании в присутствии вышестоящего руководства выссказать свои сомнения и умозаключения (это хотя бы не будет оставлять вас крайним в конце). Если менеджер особо упорен и не принимает вас во внимание, и вы чувствуете, что останетесь виноватым потом вокруг, то лучше заранее сообщить вышестоящему руководству о своем видении ситуации.

2. Что делать, если менеджер продукта уже "ушел на повышение", а менеджера проекта просят довести-таки проект до очередной вехи в плане? (продуктовой экспертизы хватает, но нет большого желания тянуть лямку за ушедшего менеджера продукта).
Ссылаться на то, что это не входит в ваши должностные обязанности и вы не сможете гарантировать удовлетворяющий начальство результат, ждать назначения нового менеджера продукта.

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

А я вот соглашусь с вашими выходами.

Тоже не имею опыта.

А мне предпосылки очень грамотными показались.

И моё мнение. Вам надо или стать продакт менеджером. Вот продакт менеджером и всё. Либо конкурсным управляющим)

П. С. Продакт менеджером продукта попроще. И пораньше. Не доделывайте.

Edited at 2015-07-09 07:03 pm (UTC)

1. Что делать менеджеру проектов продуктовой разработки, если он не верит в видение менеджера продукта? Есть ли у этого вопроса ответ,
отличный от "валить из этой компании"?

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


2. Что делать, если менеджер продукта уже "ушел на повышение", а менеджера проекта просят довести-таки проект до очередной вехи в плане? (продуктовой экспертизы хватает, но нет большого желания тянуть лямку за ушедшего менеджера продукта).

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


3. Имеет ли какой-то смысл в этих реалиях приходить на новые проекты с ожиданиями вырасти вместе с проектом или же стоит "делать что должен, и будь что будет"?


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



Edited at 2015-07-09 08:53 pm (UTC)

1.Продолжать вкалывать

2. Так это вообще замечательно. Представьте, что ваш заказчик ушел в длительный отпуск, оставив описание того, что он хочет от продукта (предполагается, что значительная работа уже сделана) Ваша задача, как можно быстрее дойти до этой вехи, принимать работу то некому, а главное, и жаловаться, и вносить изменения, тоже некому. Главное не брать на себя его обязанности. И тоже вовремя свалить Ж)

3.Однозначно стоит.

  • 1
?

Log in