Почему вы тоже уперлись, что РО - это роль именно в Скраме. Сейчас роль/должность РО можно встретить в каждой второй команде. И не важно, что у них там за фреймворк внедрен. При это в Скрам командах, где есть РО от Скрама зачастую лишь какие-то элементы. Что же касается конфликтов РО и РМ - где есть РМ, там нет Скрама, так что и обязанности РО в такой конструкции не должны подчиняться Скрам-гайду (и тем более каким-то курсам) :)
Люблю такие ситуации, когда эффективные менеджеры внедряют фреймворки по планированию, обвешиваются метриками и трекингом всего подряд, делают красивые презы, как это эффективно и моно, а на деле команды задыхаются и результат отрицательный
Хорошая статья. Видел только один раз грамотных HRBP (причем не в IT) которые реально делали свою работу - Вели штатку и планы найма (не рекрутили, а именно управляли процессом) - Развивали сотрудников (имели skills матрицу и планы развития + следили за прохождением курсов) - Оценивали и продвигали сотрудников (вели полностью perfomance ревью) - Помогали сотрудникам (знали у кого какие планы/хобби/семьи/проблемы) Очень круто было, но видел всего раз...
Очень поддержу комент! Такое происходит из-за плохой софт-скилованости РО и РМа. РО должен понимать реальный темп разработки и тут надо баллансировать между его высоким поддержанием и предотвращению выгорания команды. РМ же должен помогать видеть реальную картину и принимать правильные решения.
Как договорились. РО и РМ должны заранее обговорить, кто лидирует эту активность. Но второй человек не устраняется полностью. Каждый должен держать руку на пульсе, просто один за это еще и отвечает.
вы опять очень близко примеряете выдуманный кейс к реальности. И ПМ, который не слушает советов и в одиночку решает катиться на прод, и тимлид, который делает 25-й рефакторинг, до своих должностей просто не дойдут в нормальных адекватных компаниях. Такие проблемы не появляются из ничего, всегда есть более мелкие предпосылки, которые отсеивают некомпетентных людей.
Извиняюсь, но я не увидел, как вы решили проблему, которую описали в начале статьи
"мы заметили, что ежемесячно команда не успевала выполнить все 100% из запланированного пула работ"
От того, что вы поняли, что у разработчика не 8 рабочих часов в одном дне, а 6 - проблему точности прогнозирования разработчиков не решают.
Все мы немного Игорь...
Да, конечно
Возможно эта моя ошибка, надо было в статье написать Product Owner/Product Manager, тогда у mgvoronin не было бы вопросов :)
Еще раз скажу - в моей статье нет ни слова про Scrum
Я работаю в очень крупной компании, у нас есть Product Owner - это прям должность (а не роль)!
Многие заигрались в Скрам...
Почему вы тоже уперлись, что РО - это роль именно в Скраме. Сейчас роль/должность РО можно встретить в каждой второй команде. И не важно, что у них там за фреймворк внедрен. При это в Скрам командах, где есть РО от Скрама зачастую лишь какие-то элементы.
Что же касается конфликтов РО и РМ - где есть РМ, там нет Скрама, так что и обязанности РО в такой конструкции не должны подчиняться Скрам-гайду (и тем более каким-то курсам) :)
Шах и Мат!
Уверен, что минусуют из-за слова Skype в заголовке (про который в статье ни слова).
Крутая история, вы большой молодец!
Я уверен, что внедрение usb-c в айфонах ведется по примерно такой же истории...
Чек листы не только с США пошли, но и с Японии, когда их начала глубоко внедрять Тойота для контроля качества.
п.с. первым пунктом любого чек-листа должен быть "завести чек-лист"
Люблю такие ситуации, когда эффективные менеджеры внедряют фреймворки по планированию, обвешиваются метриками и трекингом всего подряд, делают красивые презы, как это эффективно и моно, а на деле команды задыхаются и результат отрицательный
Поддержу ваш режим душнилы и спрошу: почему роль РО исключительно в Scrum?)
Хорошая статья.
Видел только один раз грамотных HRBP (причем не в IT) которые реально делали свою работу
- Вели штатку и планы найма (не рекрутили, а именно управляли процессом)
- Развивали сотрудников (имели skills матрицу и планы развития + следили за прохождением курсов)
- Оценивали и продвигали сотрудников (вели полностью perfomance ревью)
- Помогали сотрудникам (знали у кого какие планы/хобби/семьи/проблемы)
Очень круто было, но видел всего раз...
Уверен, что многие мои коллеги на самом деле просто боты..
Маркировка ИИ специальным знаком? После восстания машин, это будет отдельным пунктом для их мести...
Очень поддержу комент!
Такое происходит из-за плохой софт-скилованости РО и РМа. РО должен понимать реальный темп разработки и тут надо баллансировать между его высоким поддержанием и предотвращению выгорания команды. РМ же должен помогать видеть реальную картину и принимать правильные решения.
Как договорились. РО и РМ должны заранее обговорить, кто лидирует эту активность. Но второй человек не устраняется полностью. Каждый должен держать руку на пульсе, просто один за это еще и отвечает.
вы опять очень близко примеряете выдуманный кейс к реальности.
И ПМ, который не слушает советов и в одиночку решает катиться на прод, и тимлид, который делает 25-й рефакторинг, до своих должностей просто не дойдут в нормальных адекватных компаниях.
Такие проблемы не появляются из ничего, всегда есть более мелкие предпосылки, которые отсеивают некомпетентных людей.
нет РО и РМа и нет проблем)
а какой он должен быть?)
еще никогда Штирлец так не был близок к провалу...