Комментарии 29
Ну действительно, причем тут менеджер? Это ведь product designer! Человек, болеющий и отвечающий за качество продукта, в чем-то проектирующий его, а не присматривающий за сроками, безликий и ни в чем, конкретно, не разбирающийся «менеджер».
Мне кажется, UXer больше всего подходит на такую роль ;-)
Мне кажется, UXer больше всего подходит на такую роль ;-)
Ага, особенно если продуктом является библиотека шифрования.
Product manager, product owner, product designer — хоть горшком назови, задача одна, выпускать успешный продукт. Не обязательно быть UXером, чтобы понимать, что продукт нужно ориентировать на задачи пользователя. Даже если это библиотека шифрования.
Как показывает практика UXer в роли ПМа может создать очень неприятный перекос в приоритетах.
ПМ должен думать не только о качестве продукта, но также и о комфорте команды, о перспективах роста продукта.
ПМ должен думать не только о качестве продукта, но также и о комфорте команды, о перспективах роста продукта.
нет, PM это обычно человек вырастающий из разработчиков, системных архитектов или SME. Хороший технарь, легко понимающий нюансы внутреннего планирования продукта, а не только «сделайте мне красиво». Плюс надо иметь опыт в сфере, иметь контакты с клиентами и сообществом, иначе откуда узнаешь чего именно надо клиентам в следующей версии?
К сожалению не совсем так. Возможно, прочитав эту статью Вы не верно поняли, чем занимается Продакт менеджер. Справедливости ради, отмечу, что статья тоже несколько однобока. Отвечая именно Вам, а не автору статьи, скажу, что UX бэкграунд это весомое подспорье, которое пригодится на этапе проектирования продукта но не более. Мало толку от юзабилити, если сам по себе продукт не решает проблем пользователя или не имеет чёткого позиционирования и стратегии вывода на рынок.
>>Я не удивлюсь, если действительно «каждый» хочет стать менеджером по продукту. Это одна из немногих профессий, для которой не
>>требуется быть экспертом в какой-либо специфической сфере. Чтобы управлять продуктом, не нужно знать,
>>как создавать модели данных или писать код;
Ага да, есть такие люди, бывают полезными, когда начальство понимает что орать на тех кто делает всякое полезное нельзя, но поорать на кого-то все-таки хочется.
>>требуется быть экспертом в какой-либо специфической сфере. Чтобы управлять продуктом, не нужно знать,
>>как создавать модели данных или писать код;
Ага да, есть такие люди, бывают полезными, когда начальство понимает что орать на тех кто делает всякое полезное нельзя, но поорать на кого-то все-таки хочется.
Судя по всему, у героини поста должность совмещала обязанности как менеджера по продукту так и менеджера проекта, раз она общалась с непосредственными исполнителями. Вообще-то это две разные роли.
А как по вашему повышать вовлеченность команды? Если у команды не будет уелостного видения продукта и понимания того, как и для чего его использую пользователи, то они такого нагородят. У меня на практике есть яркие примеры таких «франкенштейнов», которых затем в спешном порядке приходилось вытаскивать за уши.
ИМХО роли в команде зачастую определяются внутренним устройством компании, а не базовыми методологиями или стандартами. Совмещение ролей также очень часто зависит от стадии жизненного цикла продукта. В общем нюансов куча.
ИМХО роли в команде зачастую определяются внутренним устройством компании, а не базовыми методологиями или стандартами. Совмещение ролей также очень часто зависит от стадии жизненного цикла продукта. В общем нюансов куча.
А как по вашему повышать вовлеченность команды? Если у команды не будет уелостного видения продукта и понимания того, как и для чего его использую пользователи, то они такого нагородятТак не важно кто этим занимается — РП или ПМ. Кроме того, может быть схема когда вовлечены только несколько ключевых исполнителей (архитектор, тимлид и т.п.) а рядовым исполнителям просто спускают конечные задачи.
роли в команде зачастую определяются внутренним устройством компании, а не базовыми методологиями или стандартами. Совмещение ролей также очень часто зависит от стадии жизненного цикла продуктаАбсолютно верно. Более того, если уровень загрузки и компетенция сотрудника позволяет — лучше именно совместить. Я долго работал менеджером проекта, задачи мне ставил менеджер по продукту. Он не был мне начальником, скорее заказчиком, внутренним. И знаете, отношения заказчик-исполнитель не способствуют продуктивной творческой деятельности. Вроде как делают один продукт, одно дело, а де-факто цели получаются разные. А дальше как лебедь, рак и щука.
Но разумеется экстраполировать на любые проекты нельзя, очень много нюансов.
PM просто обязан общаться с разработчиками — обязательно с руководителями команд и иногда напрямую с программистами. как иначе донести до них свои требования к очередной версии?
А если регулярно с ними не встречаться и не общаться, то как можно эти требования вообще составить? Ведь вся эта работа это составление технических и маркетинговых компромиссов, относительно ресурсов и временных ограничений.
Если требовать звезд с неба, их можно получить, но это будет за счет других, не менее востребованных фичеров или времени. А GTM штука тонкая, никого не ждет.
Так что надо постоянно жонглировать возможностями Dev/QC/SA/TS, требованиями клиентов и рынка вообще и временными рамками. Картинка с курицей без головы очень подходит
А если регулярно с ними не встречаться и не общаться, то как можно эти требования вообще составить? Ведь вся эта работа это составление технических и маркетинговых компромиссов, относительно ресурсов и временных ограничений.
Если требовать звезд с неба, их можно получить, но это будет за счет других, не менее востребованных фичеров или времени. А GTM штука тонкая, никого не ждет.
Так что надо постоянно жонглировать возможностями Dev/QC/SA/TS, требованиями клиентов и рынка вообще и временными рамками. Картинка с курицей без головы очень подходит
PM просто обязан общаться с разработчиками — обязательно с руководителями команд и иногда напрямую с программистами. как иначе донести до них свои требования к очередной версии?Не обязательно. У менеджера по продукту может быть единая точка входа в разработку — руководитель проекта. Я так работал долгое время. Традиционная схема заказчик-исполнитель.
А если регулярно с ними не встречаться и не общаться, то как можно эти требования вообще составитьВообще-то требования к продукту должны исходить от потенциальных клиентов или менеджера продукта, но никак не от разработчиков.
Не обязательно. У менеджера по продукту может быть единая точка входа в разработку — руководитель проекта. Я так работал долгое время. Традиционная схема заказчик-исполнитель.
это если проекты разовые. Если идет разработка стабильного продукта (или как еще называть «долгоиграющий» продукт, который развивается от версии к версии годами), то руководитель проектов не нужен — проекта, собственно, не существует.
Вообще-то требования к продукту должны исходить от потенциальных клиентов или менеджера продукта, но никак не от разработчиков.
требования — да. разработчики могут тут разве что подкинуть мысли и идеи для фичеров (типа «я тут ковырялся, и такая фигня прикольная получилась, может пристроим куда нибудь?»).
Но когда я прихожу к тимлиду с требованиями, а он мне говорит «нет технической возможности», что мне делать, топать ножкой? Именно поэтому я и писал о компромиссах, PM должен задействовать всех, от клиентов и сейлсов с интеграторами, до разработчиков, тестировщиков и саппорта.
У меня бывало и такое что фичер приходилось убрать из версии за месяц до публичной беты, потому что начальник саппорта говорил что не успевает натренировать людей на поддержку фичера.
это если проекты разовые. Если идет разработка стабильного продукта (или как еще называть «долгоиграющий» продукт, который развивается от версии к версии годами), то руководитель проектов не нужен — проекта, собственно, не существует.И снова позволю себе с вами не согласиться :) Последние 3 года трудился руководителем проектов именно на «долгоиграющих» продуктах. Это были отраслевые тиражируемые коробочные решения. В таких продуктах четко различаются две стадии:
1. Разработка первой версии до выхода на рынок. Это классический проект с бюджетом, сроками и качеством. Причем первая версия может разрабатываться не один год.
2. Дальше, в зависимости от организации процесса в компании, тоже могут быть проекты. У нас проектом назывался очередной большой релиз. На него формировался набор требований, фиксировался ресурс и конечно сроки. Причем к такой схеме мы пришли от «беспроектной», как вы описали. Это был хаос хотелок клиентов патчей и релизов. Абсолютно неуправляемый и непрозрачный для руководства процесс.
Но когда я прихожу к тимлиду с требованиями, а он мне говорит «нет технической возможности», что мне делать, топать ножкой?Это ответ, что называется «на отъе… ись». Как аргументируют? Нет нужных компетенций или нет людей?
1. Разработка первой версии до выхода на рынок. Это классический проект с бюджетом, сроками и качеством. Причем первая версия может разрабатываться не один год.
тут я полностью согласен. у нас это еще называли startup mode
2. Дальше, в зависимости от организации процесса в компании, тоже могут быть проекты. У нас проектом назывался очередной большой релиз. На него формировался набор требований, фиксировался ресурс и конечно сроки. Причем к такой схеме мы пришли от «беспроектной», как вы описали. Это был хаос хотелок клиентов патчей и релизов. Абсолютно неуправляемый и непрозрачный для руководства процесс.
у нас очередная версия проектом не было, да и понимание того что за время разработки версии требования и условия могут измениться тоже диктовали такой подход. у нас было достаточно клиентов которые реально могли диктовать что им нужно в следующем релизе (и менять требования о ходу дела), и хватало зависимостей от апстрима и интегрируемых продуктов, которые вполне могли не успевать за нашим расписанием. Так что scrum/agile/etc более чем помогали.
Конечно же элементы управление проектом там были, куда без них? Но продход не был как к очередному проекту — все намного сложнее
Это ответ, что называется «на отъе… ись». Как аргументируют? Нет нужных компетенций или нет людей?
нет нужных фичеров в апстриме или в интегрируемом продукте. свои велосипеды создавать займет годы. Или требуемое клиентом абсурдно с т.з. данной технологии и выступает против всех нормальных best practice в отрасли. Да мало ли на самом деле возможных причин :)
у нас очередная версия проектом не было, да и понимание того что за время разработки версии требования и условия могут измениться тоже диктовали такой подходВерно, поэтому мы старались сокращать очередной релиз до 2-4 месяцев, не более. Чтобы можно было зафиксировать требования на этот срок. Ну практически как итерация в agile.
нет нужных фичеров в апстримеЕсли често не понял ни про «фичеров» ни про «апстрим». Что это значит?
Верно, поэтому мы старались сокращать очередной релиз до 2-4 месяцев, не более. Чтобы можно было зафиксировать требования на этот срок. Ну практически как итерация в agile.
ну тогда наверное то что у вас считалось проектом, у нас таковым не считалось :) хотя совпадений по методологиям и подходам скорее всего более чем достаточно. у нас цикл был полугодичный, но опять же — много зависимостей.
Если често не понял ни про «фичеров» ни про «апстрим». Что это значит?
Основная паадигма для больших проектов, особенно с элементами опенсорса это использование готового везде где это возможно, вместо того чтоб пееписывать что либо под себя. В нашей системе например был модуль собирающий статистику и выдающий репорты, но вместо того чтоб писать обственный сервер репортов, мы просто взяли готовое, и интегрировали в наш продукт. Но если у них в данной доступной версии не хватало функционала, то и у нас он, появиться не мог, а тратить пару сотен человеколет на разработку собственного сервера статистики такого уровня было бы идиотизмом.
апсрим это вообще понятие из опенсорса — обычно нестабильный, свежий код который разрабатывается сообществом, а коммерческая фирма его берет потом, дописывает, тестирует, и превращает в настоящий продукт. но опять же, если в апстриме нет функционала, то фирма которая его принимает на обкатку обычно этот функционал не добавляет (хотя мы и тут делали исключения)
Как мило «беспокоюсь, не воспринимают ли меня простым дублером JIRA» :-)
очень неверная по многим пунктам статья. PM это очень тяжелая работа, и на ней надо быть очень хорошим техническим экспертом, иначе просто не вникнешь в тонкости планирования версии.
это я из опыта работы Sr PM в Red Hat, если что.
это я из опыта работы Sr PM в Red Hat, если что.
Руководитель продукта в большей степени режиссёр или если хотите дерижёр, а так же маркетолог и немного финансист. Техническим бекграундом он обладает куда в меньшей степени, нежели выше озвученными качествами. Не могу говорить за вас, но судя по всему Вы имели ввиду Проектного менеджера, хотя и он тоже в большей степени планировщик и коммуникатор, нежели технический эксперт.
нет, именно product manager. человек не понимающий внутренностей продукта не может управлять его разработкой. не обязательно лезть в код, но быть хорошим экспертом по продукту разработкой которого управляешь просто необходимо, иначе можно или самому нагородить глупостей, или по непониманию дать разработчикам увлечься какой нибудь ненужной клиентам чушью, которая им кажется интересной, но на самом деле не имеет отношения к требованиям рынка.
> человек не понимающий внутренностей продукта не может управлять его разработкой
> не обязательно лезть в код
Нет ли тут противоречия? Я не говорил, что он не должен знать продукт изнутри, но на высоком архитектурном уровне, а хороший технический эксперт это всё же более низкоуровневая роль. Кроме того, что вы скажете о тех продуктах и сферах, где технической подоплёки как таковой нет, а есть скорее технологическая — разница, думаю, понятна?
> не обязательно лезть в код
Нет ли тут противоречия? Я не говорил, что он не должен знать продукт изнутри, но на высоком архитектурном уровне, а хороший технический эксперт это всё же более низкоуровневая роль. Кроме того, что вы скажете о тех продуктах и сферах, где технической подоплёки как таковой нет, а есть скорее технологическая — разница, думаю, понятна?
Хорошая статья. «Не быть звездой, а управлять Вселенной» — вообще зачёт.
Я тогда заканчивала колледж по специальности «Психология»…
К моему удивлению, мне предложили стажировку на должности менеджера…
я действительно не знала, чем занимается менеджер по продукту…
диплом я защищала по психолингвистике…
Когда я узнала, что буду управлять QuickBooks, меня чуть не вывернуло…
Коллеги, видится мне это так:
1. Берут некую особь из золотой молодежи, без профессии и без опыта работы, и с помощью родителей или еще кого-то сажают на шею команде профессионалов, которые уже давно выпускают успешный продукт. Особь при этом еще и кривится — не на инновации её посадили.
2. Запас прочности опытной команды был достаточен, и они смогли повезти на своей шее и эту наездницу, причем обучая её по пути как надо работать.
3. По ходу движения свежеиспеченный эффективный менеджер делает для себя открытия как меньше лажать в работе, а теперь еще и делится с нами.
4. Но какова ценность её откровений? И даже если всё сказано правильно, не лучше ли почитать какого-нибудь другого автора на ту же тему?
Работаю ПМ 6 лет. В разных компаниях, разных командах и на разных стадиях жизни продукта ПМ может выполнять разные функции. Это и разработка концепта — для кого, зачем, сколько заработаем и сколько потратим. Это и дизайн продукта — функции, интеграция с другими продуктами, и сам дизайн. Если нет выделенного менеджера проекта или скрам мастера, то ПМ нередко сам управляет разработкой и планирует релизы. Если нет менеджера по маркетингу продукта, то надо заниматься еще и рекламой и ПР.
По моему опыту ПМ — это такой мини-босс, который не должен быть экспертом во всех областях, но должен иметь о них хотя бы базовое представление. Но некоторые области все же самые важные: вы должны быть экспертом по своим продуктам — их пользователям, функционалу, финансовым показателям, возможностям роста и конкурентам. Вы должно четко понимать, зачем компания делает продукт. И тогда есть шанс сделать что-то достойное.
По моему опыту ПМ — это такой мини-босс, который не должен быть экспертом во всех областях, но должен иметь о них хотя бы базовое представление. Но некоторые области все же самые важные: вы должны быть экспертом по своим продуктам — их пользователям, функционалу, финансовым показателям, возможностям роста и конкурентам. Вы должно четко понимать, зачем компания делает продукт. И тогда есть шанс сделать что-то достойное.
Из книжек по ПМ самая толковая — Shipping greatness
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хотите управлять продуктом? О чем молчат все менеджеры по продукту