Nikolai
мне будет интересно понять механику Вашей работы
Alexandr
а вы скрам гайд читали? вы там видели что то про аналитиков, отделы, сеньоров?
Nikolai
отдел = команда
Alexandr
:) вы какой то извращенный перевод видимо читали
Alexandr
а скорее всего просто не читали
Alexandr
советую прочитать, он небольшой, тогда вам будет проще общаться тут
Nikolai
прочитал, все что написано, уже известно
bebebe
Евгений
бейте на команды так, чтобы команда могла выполнить все задачи спринта самостоятельно... и аналитику провести, и фронт и бэк... и все на свете
Nikolai
PM является точкой входа инфы из других отделов и по всем проектам, общается с PO (руководством компании, директором по маркетингу и тд) распределяет задачи на тим лидов в зависимости от специализации front/back формирует вместе с тим лидами бэклог спринта, проводит собрания, периодически может уточнять требования контролирует сроки и принимает результат, запрашивает список правок у заинтересованных лиц тим лид на бэке одновременно является архитектором всей системы Это если вкратце
Nikolai
Алексей, приветствую)) последний раз виделись на Lego4Scrum в Ингрии
Nikolai
А как сейчас? Что не устраивает?
Nikita
> распределяет задачи на тим лидов в зависимости от специализации front/back В скраме нет тимлидов, фронтов, бэков и пмов
Nikita
У вас точно не скрам
Victor
в скраме может быть только 3 роли
Alexey
в скраме может быть только 3 роли
Скрам это каркас и определяет только три роли. Но каркас должен быть дополнен "мясом" - техниками, ролями, практиками необходимыми для достижения целей бизнеса.
Victor
PO, SM, DT, больше никого в скраме нет
Nikolai
Привет, привет!
Ну то что я веду сразу две команды разработчиков, в сумме 15 человек
Nikolai
На фронте тим лид и.о. пока что
Nikolai
не совсем понятно куда
К чемпионству конечно))
Alexey
Ну то что я веду сразу две команды разработчиков, в сумме 15 человек
На основании описания, я вижу, что так, как задачи ставятся лидам, то тут явно две специализированные команды есть и смысла как-то по другому их делить их нет. Если нет проблем с координацией работ по технологическому стеку. Постановка задачи лиду (как "точке входа" команды) и единая точка входа РП соответствует роли "владелец продукта" по отношению к этим двум командам, внутри каждой команды роль "владелец продукта" - у тимлида. Если хочется устранить себя из общения между командами, то инициативу захватит Архитектор и тут нужно оценить последствия. Разворот в feature-команды может иметь смысл если есть проблема с координацией на стеке технологий, но могут быть нежелательные явления. И это решение не единственное из возможных.
Yuriy
Всем доброго дня. Быть может кто натыкался на материалы по разработке KPI для Product Manager'а?
Артур
Всем доброго дня. Быть может кто натыкался на материалы по разработке KPI для Product Manager'а?
Ну так: валовая выручка, валовая прибыль, маржинальность, оборачиваемость склада, нелидвиды. Все очевидно и просто
Yuriy
Выручка, прибыль и тд может рости не зависимо от работы PM. Например сезонность. То есть мы не можем говорить о том, что это заслуга PM. Или например если PM не имеет влияние на отдел продаж. Это тоже не может быть его KPI
Yuriy
Прибыль. Тут тоже много внешних факторов, которые надо учесть в вычислении KPI
Yuriy
Риск менеджмент, корпоративная стратегия и тд. PM может не иметь на них никакого влияния, или минимальное влияние. А вот они могут влиять на выручку, прибыль, маржинальность, оборачиваемость склада, нелидвиды
Артур
Сезонность учитывается квартальными коэффициентами. Если сезонность очень сильная, то ежемесячными планами.
Артур
Ну)) значит надо чтобы у него было влияние))
Yuriy
в общем случае kpi выглядит на вскидку F("коэфицент влияния pm"*"значение"*"корректирующий коэфицент внешних факторов")
Артур
К прибыли в любом случае должен быть привязан
Yuriy
это я согласен
Yuriy
вопрос как определить, что PM делает дело
Yuriy
можем корректировать прибыль на общи рост рынка
Yuriy
но остаются еще его зоны ответсвенности и куча других факторов =(
Артур
Значит надо определить нормативы. Рост рынка такой-то, значит надо показать рост такой-то. Нормативная маржинальность (перемножив получим прибыль). Норматив на неликвиды
Артур
Норматив на оборачиваемость склада зависит от формата бизнеса и может быть очень разный. Иногда проще им пренебречь. И системы рассчета очень разные
Yuriy
основную проблему я вижу в том, как привязать "размытое" влияние PM к ответсвенности за продукт.
Yuriy
например решение совета деректоров о уменьшении финансирования повлияет на продукт не в лучшую сторону, но как учесть хотя-бы большую часть множества факторов
Yuriy
или например "феил" одного из продуктов предприятия и подпорченая репутация, повлияют на продажи всех продуктов
Yuriy
Для вас есть разница между Product Owner и Product Manager ?
Да. Product Manager в скрам команде будет выступать в роли Product Owner. Но на этом его ответсвенность не заканчивается
Yuriy
https://cdn-images-1.medium.com/max/1200/0*0iUEbmge6zbYzk1O.png
Petr
Зачем ему kpi?
Magistr
опять в этом чате пытаються всунуть kpi
Yuriy
Зачем ему kpi?
Собственики хотят понимать эфективность работы PM
Michael
а что не так с KPI? Они должны быть хоть какие-то)
Petr
Определяете ВМЕСТЕ с РМ основную цель продукта. Формируете ВМЕСТЕ метрики и период достижения. Метрики достиг - молодец.
Petr
И забудьте слово kpi. в скрам команде должна быть цель единая для команды
Yuriy
Работа PM, которая включает в себя PO в команде
Денис
Работа PM, которая включает в себя PO в команде
Я про метрики, они вам для роли PO нужны или в целом для PM (который вне команды по слайду)
Денис
?
Michael
И забудьте слово kpi. в скрам команде должна быть цель единая для команды
Ну ок, есть цель у команды, но она должна выражаться в цифрах. Эти цифры - KPI. Показатель эффективности работы всей команды. Это и ROI и ARPU и все что угодно
Денис
ну так тогда это к Scrum отношения не имеет.
Денис
для PM
Вы сначала определитесь, что вы хотите. Вам нужен PO судя по вашим словам. На эту роль вы сажаете PM, но метрики почему то для PM нужны
Денис
Просто это совершенно разные могут быть метрики. Это же прямо видно из слайда, присланного вами
Yuriy
PM выполняет роль PO в скрам команде. Но так же он выполняет и работу вне команды. Такую как координацию аналитиков, общение с владельцами и другими стейкхолдерами и тд
Денис
PM выполняет роль PO в скрам команде. Но так же он выполняет и работу вне команды. Такую как координацию аналитиков, общение с владельцами и другими стейкхолдерами и тд
Да это то все понятно. Просто вы говорите про PO (это работа в команде), а метрики хотите для PM. А это разные метрики. Поэтому я вам и говорю. Определитесь, что вы хотите. И сразу легче станет.
Petr
Ну ок, есть цель у команды, но она должна выражаться в цифрах. Эти цифры - KPI. Показатель эффективности работы всей команды. Это и ROI и ARPU и все что угодно
Так вот вам метрики :) есть пооблема в roi - сделайте roi. И не забудьте рассказать команде, как вы его считаете.
Mikhail
Коллеги, подскажите где почитать про разделения epic, userstory, task etc. У нас тут холивар, хочу сослаться на авторитетов)
Денис
PO — это роль в скрам команде. А работа PM
Юрий, вы так и не можете понять, что же вы хотите. Вы хотите оценить эффективность работы человека в команде на роли PO или вы хотите оценить PM в целом? Разберитесь с этим сначала - иначе у вас ничего не выйдет, чтобы вам тут не насоветовали.
Yuriy
PM в целом
Денис
PM в целом
Отлично. А цель создания продукта, за который отвечает этот человек есть? Она зафиксирована?
Petr
Он отвечает за что?
Petr
Имхо критерии оценки зависят не от роли, а от зоны ответственности
Yuriy
вам лучше задать этот вопрос в чатике продактов
А такой существует? Я знаю только каналы
Yuriy
Отлично. А цель создания продукта, за который отвечает этот человек есть? Она зафиксирована?
А вы не натыкались на какие либо материялы или шаблоны, что бы мне почитать и не придумывать "велосипед"?
Yuriy
Olga
Конкретно связанное с kpi для продактов я видела это http://www.mironov.com/pm-kpi/ Если там пошагать по ссылкам, можно найти assessment tool, но для оценки команды
Petr
А вы не натыкались на какие либо материялы или шаблоны, что бы мне почитать и не придумывать "велосипед"?
Увы, но велосипед придется придумывать каждый раз. Каждый продукт уникален. И у каждого продукта есть свой список первоочередных проблем, которые ждут решения. Поэтому цели живые и постоянно меняются.