Комментарии 21
Хорошо бы айтишникам перестать выдумывать велосипеды и множить сущности: в большинстве отраслей роли четко распределены, к этому шли столетиями и научились быстро реагировать на изменения и адаптировать роли и структуры. Но нет - у айти свой путь. :)
Вот согласен. С опытом тоже все больше к этому прихожу
Да большинство не может поставить цели C-level борду, кроме как "нужно больше денег и работать". Какие роли, какие структуры.
А за сроки надо спросить кого-то, но у нас ведь аджайл, спросить некого - вот вам и Деливери менеджер.
За 15 лет в этом плане ничего не поменялось. Раньше эту чушь слушал только на "выступлениях" топов перед всей компанией раз в год, теперь на C-level планерках, раз в неделю - две - четыре (зависит от компании).
Выдумывают не айтишники, а собственники или их эффективные манагеры.
Из недавнего - конвертнули 20к баксов по хреновому курсу, потеряли 150 долларов, надо доказать и наказать бухгалтера, а лучше уволить. А то что люди которые это слушали, а потом часть из них доказывала - стоили только по времени 350$ - никого не интересует.
Так и появилась роль ДМа.
Т.к. нужно менеджить несколько проектов под одним зонтиком с фокусом на СПОК клиента.
Несколько проектов это всего лишь несколько проджект-менеджеров, или один, но ведущий несколько проектов.
Customer success менеджер умудряется вести клиента по всему циклу его (клиента) бизнес-задач и как-то никому в мире не приходит в голову дробить их между несколькими customer success менеджерами или придумывать новую вакансию. Я же говорю - не изобретайте велосипед: он уже изобретен во всех необходимых модификациях.
То есть то, что роли, к примеру в областной поликлинике и на крупнотоннажном танкере "немножко" отличаются -- вас не удивляет. А то что роли в айти отличаются и от того, и от другого -- удивляет. А почему?
Что в поликлинике, что на танкере при наличии нескольких проектов, сходящихся "вершиной" к достижению *одной цели* они синхронизируются между собой в первую очередь самими руководителями этих проектов, а на верхнем уровне - вертикальным руководителем, отвечающим за вышеуказанную "цель". И только в айти придумывают какие-то доппрокладки в виде еще одного руководителя. Вот это меня удивляет. В поликлиниках и танкерах, работающих столетиями, как раз всё уже давно оптимизировано. Просто айтишникам лень учиться на опыте, ведь проще нагородить свое - бюджеты опять же.... :)
То что что-то в чем-то схоже, отнюдь не означает что структуры и роли там одинаковые. Структура той или иной компании зависит от:
а) Вида бизнеса -- даже внутри одной и той же отрасли, например структура продуктовой софтверной компании и софтверной компании пишушей софт на заказ будет отличаться кардинально.
б) Технологиями. Взять тот же флот: переход от парусов к паровым машинам потребовало кардинально сменить всё
в) Проектная компания или нет?
И тд. и тп.
Поэтому ваше предложение взять "хорошо известную и опробованную структуру и использовать в ИТ" неприменимо хотя бы потому, что в разных отраслях она своя и выстроена с учетом ее особенностей. Ровно так же, как и в ИТ-компаниях.
Да всё проще. Топ-менеджеры контор, которые перешли на аджайл, были неприятно удивлены, что по канонам владелец продукта ни грамма не менеджер. А у команды разработки нет менеджера и спросить за сроки не с кого. На вопрос "кто шил костюм?" отвечают "мы!".
Вот и завели вместо запрещённого в аджайле прожект-менеджера новую должность - деливери-менеджер.
Последние несколько лет нас одолевают “черные лебеди”. И они такие жирные, массивные. И точно такие же внезапные и непредсказуемые.
Вообще-то "черный лебедь" отличается предсказуемостью, просто в него не верят, пока он не появится.
Термин уже лет 5 как широко в ходу, во всяком случае, я его в среде слышу точно не меньше - видимо, прижился.
Но давайте будем честны, это и по сути своей не новая роль. Как-то надо было назвать ИТ-шного РПшника, точнее "РПшника в сфере разработки ПО" - вот, это он, Delivery manager.
Термин "Руководитель проекта" был не подходящим и ломал шаблоны в головах, так как вроде и проекта нет как ограниченного во времени предприятия с уникальным результатом, а есть регулярная производственная деятельность. Поэтому группы процессов PMBOKовские слабо получалось применять, не делать же, в самом деле, устав на каждый спринт. А вот зона ответственности за сроки, стоимость, объем и качество, и области знаний все те же, РПшные.
Выглядит как попытка прикрутить к скрамгайду, натянутому на сову, решалу, который будет снимать блокеры на всех уровнях производства сразу.
Поменьше бы воды отусу каждый раз лить ?
Во время прочтения всей статьи не мог поверить своим глазам - читаю практически про себя. А я работаю менеджером продукта, но не только в стратегии, а и в том, что перечислено в этой статье (так же забочусь о команде, помогая в этом владельцу продукта).
Добавил:
Почитал быстро статейки в "западных интернетах" и увидел, что в целом роли пересекающиеся, но все же Product Manager - чуть шире (что так же соответствует моей работе).
Грубо говоря, Delivery Manger отвечает за конкретную поставку конкретному заказчику (или пулу похожих заказчиков), а Product Manager отвечает за поставку всему разнообразию заказчиков и решает конфликты приоритетов и пожеланий. Понравилось описание, что Product отвечает за "портфель поставок".
То есть в целом корректно, что я "распознал" себя. Меня можно, получается, и Delivery, и Product менеджером звать.
Продакт менеджер отвечает за продукт и за его результаты (финансовые в первую очередь), деливери менеджер отвечает за поставку ценности заказчику. Это разные роли совсем.
Другое дело, что частенько на продакт-менеджера вешают ещё и управление командой проекта, вот тогда при разной сути, они становятся в чем-то похожими.
Пошел перепрочел несколько источников по терминологии, во многих упоминается в том числе то, что:
Задача специалиста — создать продукт, который удовлетворит потребности пользователей и принесёт компании прибыль.
То есть не отменяя то, что есть задача принести финансовые результаты своей компании, все же закрыть потребности заказчиков тоже нужно.
В целом мне вообще трудно представить как эти две стороны можно отделить друг от друга - как в прицнипе возможно принести прибыль продуктом, если он не приносит ценности конечным заказчикам? Кто же будет платить деньги за такой продукт. Возможно, в каких-то сферах такое возможно, но, по крайней мере в B2B я о таком не слышал никогда.
А вот прочитав концепцию DM вполне себе вижу применимость на своей же практике - не всегда с точки зрения продукта мне как менеджеру продукта стоит "ломать его" ради удовлетворения одного (пусть очень дорогого) заказчика. Другой вопрос, что его хотелки можно удовлетворить альтернативными методами. Например, в том числе в своем продукте для него сделать кастомный модуль именно для этого заказчика (и тех, кто захочет такой же модуль), но чтобы 100 других заказчиков не почувствовали на себе изменений и продолжили счастливую жизнь без этого кастома.
Первый раз слышу, что DeliveryM это менеджер над Продакт менеджером. Обычно на практике PM отвечает за стратегию, DM за тактику, PM думает куда и как будет развиваться продукт и принимает решения, а DM считает сколько нужно на это человекочасов и затем старается не выйти на обещание. Даже более, на практике вижу что DM работает 95% времени чисто внутри спринта, не принимая глобальных решений и скорее помогает контролировать уже имеющиеся ресурсы на более эффективной поставке, сокращая time 2 market отдельных задач. Для меня это не выглядит как менеджер менеджеров? Менеджер команды да, но не пма и с натяжкой тимлида (тимлид скорее в другой плоскости немного).
В моей практике, если говорить про заказную разработку, то продакт-менеджера нет вообще, поскольку управление продуктом -- на стороне заказчика. С заказчиком работает ДМ и либо сам же выполняет функцию проджекта, либо управляет несколькими проджектами.
Если говорить про продуктовую разработку, то там связка продакт-менеджера и проджекта(ов). Вариантов, когда одновременно были все три роли мне не встречалось.
Delivery Manager – очередной хайп или новый тренд управления