Pull to refresh

Comments 17

Скорость чтения публикации — 10 минут

это время, а не скорость.

согласна))) Если Вы потратите это Время на статью, и она Вам понравится, буду рада :).

Давайте разбираться.

1.   Дирижер

....

2. Спортивный тренер

...

3. Прораб

...

4. Шеф, су-шеф

...

5. Режиссёр

...

6. Ивент-менеджер

...

7. Учитель

...

Можно смело добавить в данный список еще врача, военного, политика, философа, уборщицу, сторожа, полицейского, демагога, дилетанта.

Очень похоже на продакта, правда?

-----------------

Нет такой специальности - "продакт".

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

У учителя, как и у тренера - главная функция - учить.

Нет такой специальности - "продакт"

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

Можно смело добавить в данный список еще врача, военного, политика, философа, уборщицу, сторожа, полицейского, демагога, дилетанта.

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

Для меня продакт-менеджер, это роль на стыке управления проектом (у проекта есть начало и конец), управления людьми (продакт-менеджер не создает результат, который "можно пощупать", он создает наилучшие условия для создания результата), взаимодействием с заказчиком и формированием стратегии решения проблем/задач заказчика. Это если очень упрощать.

Перечисленные Вами профессии мне не кажутся на 100% подходящими, так как:

  • как правило, они работают в одиночку для реализации своей задачи

  • они создают повторяющийся сервис, а не завершенный продукт

  • часто действуют по строгим правилам или стандартным процедурам, а не тестируют гипотезы или адаптируются под неожиданные задачи

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

Хотя, конечно, можно найти общее: врач - аналитика и принятие решений, политик - красиво говорит и "продает" идеи, полицейский - следит за соблюдением правил

Вспомнил старый анекдот.

Заспорили инженер, математик и философ кому меньше всего предметов надо для творчества.

Инженер - мне надо логарифмическая линейка, лист бумаги, карандаш и ластик.

Математик - мне линейка не нужна.

Философ - а мне надо лист бумаги и карандаш.

---------------------------

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

менеджер не должен мешать там, где все работает. Если появляются отклонения - идет медленно разработка (медленнее, чем запланировали вместе) или задерживается поставка релиза, он может вмешаться с целью помочь.

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

Лично я иногда прошу погрузить в детали, объяснить почему "код говно" и зачем надо рефакторинг делать прям сейчас, или почему нельзя сделать вот такой график, а можно другой. Потому что и самой интересно, и для планирования следующих задач пригодится.

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

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

>он может вмешаться с целью помочь

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

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

Или вместе выясняем что непонятно, то есть уточняем детали

Или меняем задачу, если она реально невыполнима в таком объеме и/или сроках

И обязательно в будущем учитываем этот опыт и закладываем больше времени на реализацию

Благодарю за ответ.

Лично я иногда прошу погрузить в детали, объяснить почему "код говно" и зачем надо рефакторинг делать прям сейчас, или почему нельзя сделать вот такой график, а можно другой. Потому что и самой интересно, и для планирования следующих задач пригодится.

Мне это напомнило случаи из прошлой жизни.

Случай 1:

Когда-то руководил научно-исследовательской группой в институте. Сам искал заказчика и заключал договор. Но когда надо было планировать расходы, то начальник ПФО начинала всех руководителей НИР вызывать на "ковер" и с пристрастием спрашивать "зачем заказываете этот чип? Зачем этот прибор?" Ей было интересно.

Случай 2:

Рассказал начальник исследовательского отдела НТЦ АвтоВаза. Было это еще в СССР. Надо было купить чипы для роботов в цех сборки. Пришли к главному инженеру подписать разрешение на валюту для закупки чипов.

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

это отличные примеры как делать не надо))

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

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

Судя по количеству минусов, я не совсем понятно доношу мысль :) Я точно не за микроменеджмент и контроль каждого разработчика.

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

В итоге, если спец захочет, то он навешает менеджеру лапшу на уши.

Расскажу еще один случай из прошлого.

Еще в СССР меня попросили на трикотажной фабрике запустить АРМ из Японии модельера трикотажных изделий В Ленинград приехал представитель фирмы-производителя данного комплекса и съехались спецы со всего Союза. В процессе беседы с ним, он рассказал, что он инженер-математик. Когда после Вуза пришел на фирму, то его поставили осваивать ручной вязальный станок,потом он осваивал полуавтомат и теперь запускает в работу АРМы и микроконтроллерные вязальные комплексы. Когда он демонстрировал свою работу на этом комплексе, то все присутствующие спецы со всего СССР, просто не верили своим глазам, так быстро и качественно он все сделал.

Полагаю, что таким и должен быть настоящий продакт-менеджер. Согласны?

таким и должен быть настоящий продакт-менеджер

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

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

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

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

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

для меня продакт-менеджер это не надзиратель за проектом и командой. Это полноправный участник проекта

Благодарю за беседу.

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

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

Вторая, это та, которую копируют с 90-х с США. Управленцем может тот, кто умеет рулить финансовыми потоками. При этом нет надобности знать то, чем управляешь. т е менеджер- это универсальный управленец - все равно чем управлять. Все управляется одинаково.

В итоге космической корпорацией может управлять журналист.

Крупной нефтяной компанией - переводчик.

ну и так далее..

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

две школы создания менеджеров

Да, это действительно два разных подхода. Я сама выросла в менеджера из геофизика и геолога. В этом подходе было много плюсов, но и минусы были.

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

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

  1. Не дирижер, а художественный руководитель. Именно он определяет какие постановки будут, кто целевой зритель

  2. Не тренер, а владелец команды. У тренера одна цель : побеждать. А у владельца еще на горизонте контракты, реклама

  3. Не прораб, а главный архитектор. Архитектор описывает ключевые характеристики готового продукта - здания

  4. Шеф, возможно

  5. Не режиссер, а продюсер фильма.

Да, спасибо, что правильно заметили. Я объединила проектное и продуктовое управление в одну роль

Sign up to leave a comment.

Articles