«Должностная инструкция Product Owner-а»

Собираю список того, что должен/не_должен делать хороший Product Owner в команде. Какие действия PO были эффективными, а какие деструктивными. Практика приветствуется:)

>>>Вступление и описание проблемы

Должностная инструкция Product Owner-аВ очередной раз натолкнулся на то, что маркетинговая машина SCRUM (наиболее успешный sales в мире agile) захватывает «неокрепшие умы» и все хотят побыстрее приобщиться к этой успешной и модной практике.

Но SCRUM – это не только ежедневные stand-up-ы и «стикеры на доске», хотя с виду это кажется именно так :).  Поэтому в реальной жизни многие команды и Заказчики сталкиваются с проблемой. И из этой проблемы есть 2 выхода: или сказать, что agile – это красивая обертка за которой ничего нет, или почитать литературу (а потом нанять консультанта :)).

Литература говорит, что agile – образ мышления (тот самый mindset), который определяет поступки для каждой роли. Вот только плохо получается объяснить Заказчику, что ему нужно менять свой mindset. Самым добрым вариантом ответа может стать фраза «…давайте я буду бизнес делать, у меня на него mindset настроен…», а недобрый вариант может начинаться с «… не учите батьку… ваше дело кодить».

Да и вообще менять mindset взрослого человека – дело хлопотное и дорогое. Поэтому лучше просто сказать, что конкретно нужно делать или чего избегать, чтобы роль Product Owner-а была максимально эффективной в команде. А если перевести это в цифры и деньги, то такой список будет явно выигрывать у идеи «просто поменяйте образ мышления».

>>> Собираю идеи

Очень хочется, чтобы активные участники блогов и аджайлисты ответили на 2 простых вопроса:

1. Что нужно делать Product Owner-у, чтобы команда была максимально эффективной и ощущала себя командой?

2. Какие действия PO приводят к тому, что эффективность и сплоченность команды падает?

По мере поступления ответов буду обновлять пост и составлять некую «Должностную инструкцию Product Owner-а»: что нужно и не нужно делать (what to do and not do).

Полагаю, что такой список будет очень полезен для наших команд, чтобы мы могли поделиться лучшими идеями и в удобном виде представить их Заказчику (и РО). Статистика говорит, что посты в теме «Советы Заказчику» являются лидерами «хитов» на моем блоге, а значит и команды и Заказчики этим пользуются.

Немножко о формате:  Важно отметить, что полезным будут практические советы. Ответ «нужно чтобы Product Owner любил команду» будет абсолютно правильным в сакральном смысле, но не очень полезным в практическом. Вы же не придете к РО с запросом: «Пожалуйста, ознакомься… пункт 5 говорит о том, что нас надо любить. Будь добр, начинаем со следующего спринта». :)

Для того, чтобы задать «тон дискуссии» размещу несколько своих советов одним из комментариев к этому посту.

Даже одна идея от каждого посетителя – уже большой вклад в общее дело :) Не стесняйтесь, пишите идеи.

P.S. Лучше сразу залогиниться на сайт (в правом верхнем углу), а потом писать коммент. Прикручена регистрация со всех соц.сетей, так что это 1 клик :).

 

May 18th, 2011
  1. May 18th, 2011 at 06:37 | #1

    Должен делать:
    1. Product owner-ы должен проводить сессию подготовки к Planning-у, чтобы проработать возможные варианты вопросов.
    2. Лучшие Acceptance Criteria получаются у PO. Он пишет их, понимая бизнес (отвечая на вопрос «зачем», а не «как»).
    3. Хороший РО говорит «Мне нужна эта фича, придумайте как сделать ее технически». Тем самым дает возможность команде сделать это правильно, а также перекладывает ответственность за это решение.
    4. Хороший РО хоть раз присылал команде какой-нибудь презент.
    5. РО должен честно сказать, если команда выпустила фичу с неподходящим уровнем качества.

    Не должен делать:
    1. Навязывать эстимейты, мотивируя это тем, что «все равно нужно все сделать к такой-то дате».
    2. Настраивать членов команды друг против друга.

  2. May 18th, 2011 at 07:22 | #2

    По “классическому” ажайлу продукт овнер – представитель бизнеса\заказчика.

    Сплачивать команду и делать всем хорошо – не его работа, а работа – скрам мастера(что рекомендуеться не совмещать с продукто овнером, т.к. у них может быть конфликт интересов).

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

    ПО отвечающий еще и за мотивацию команду это уже ближе к ватерфолу.

    • May 18th, 2011 at 08:09 | #3

      Ок, принято, что РО не должен думать о мотивации команды.
      Должен ответить на любой вопрос – хорошо, но обще. КАК ему добиться этого?
      Вот подумал, что он еще должен очень хорошо управлять собственными тасками, чтобы не упустить вопрос от команды.

      • May 18th, 2011 at 18:42 | #4

        Сергей Бережной :
        Должен ответить на любой вопрос – хорошо, но обще. КАК ему добиться этого?
        Вот подумал, что он еще должен очень хорошо управлять собственными тасками, чтобы не упустить вопрос от команды.

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

        В практике моей работы были случай спросишь у как бы “продукт овнера”, а что делать в том то и том то случае: вот могу так и эдак сделать, а продукт овнер отвечает: ну я неуверенна мне над посоветоваться с “имя реального продукт овнера”, и думаешь про себя какого #%#$W#$ ! Какой же ты продукт-овнер если не можешь бизнес-решения принимать и ответственность за них на себя брать ?

  3. May 18th, 2011 at 08:45 | #5

    Из своего небогатого опыта Product Ownership:

    Сильно помогает проводить 1-2 тренировочных демо перед настоящими демо.

    Хорошо помогает проводить разбор полетов сразу после сдачи итерации, релиза, демо, etc:
    – что с точки зрения PO было сделано хорошо и чем это хорошо, что сделано плохо, чем это плохо и как было бы хорошо.

    > ПО отвечающий еще и за мотивацию команду это уже ближе к ватерфолу.

    Не обязательно отвечать за мотивацию, чтобы своими действиями мотивировать или демотивировать команду :)

  4. May 18th, 2011 at 09:30 | #6

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

    http://bit.ly/iX8g3G

    • May 18th, 2011 at 09:45 | #7

      А еще добавлю из “оригинальной статьи”

      Кто такой Product Owner?

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

      • May 18th, 2011 at 09:56 | #8

        Упрощаешь? Не всегда заказчику – особенно если бизнес крупный – есть дело до того, как ОДИН ИЗ его продуктов делают. Т.е. в сферическом рынке в вакууме оно так и есть. А вот в реальной жизни – даже не в каждом стартапе это так.
        Дополнительна сложность реальной жизни – вопросы финансирования. Эта тема всегда больная. И было бы ошибкой рассматривать PO как человека, который ведет переговоры о деньгах только со своей внутренней жабой.

  5. May 18th, 2011 at 09:51 | #9

    Product Owner я не был никогда, но мне кажется, что тут все просто – это 1/2 классического Project Manager, которая ответственна за коммуникации с заказчиком + Business Analyst
    Итого
    Scope
    0. Плотная коммуникация с заказчикам. На уровне “Че-то ты хмурый, братан, сегодня. Все ли хорошо в жизни, брат? Жена-дети-собака здоровы? Сам-то как?”
    1. Таски и приоритезация. Иначе говоря предварительный прескрининг хотелок заказчика и, при необходимости, адаптировать их для понимания командой + четкое понимание, как фичи для бизенса важны, а какие могут подождать
    2. Таки Acceptance Criteria. Как минимум анализ работы QA, если они есть. Как максимум деятельное участие в работе QA на уровне Acceptance. По-моему сюда входит честное обсуждение того, что сделано, что не сделано, что сделано хорошо, что сделано плохо, нет?
    3. Быть источником бизнесс-информации для команды в режиме 24/7/365. Уметь объяснить, уточнить, раскрыть бизнесс-задачу фичи, если она не ясна самому PO – уметь выяснить у заказчика ASAP. Сюда входит, в том числе, умение объяснить на ретроспективе, почему это хорошо, а это плохо. И как должно выглядеть то, что плохо, чтобы быть хорошо
    4. Расчет рисков и планирование стратегий реагирования на риски с точки зрения бизнесса. Т.е. каким функционалом можно пожертвовать, сколько денег есть на оплату оветаймов, сколько денег из этих денег можно выделить в качестве бонуса, etc.
    5. Вопросы мотивации команды в целом с точки зрения бизнеса. Т.е. команда поработала хорошо – вот вам ребятки бонус в N долларов, делите его как хотите. Тут важно – не “Васе 3 доллара”, “Пете 5 долларов”, “Алене 10 долларов”, а “Ивану 0 долларов”, а команде N долларов. У нас вдеь самоорганизующаяся команда? Вот пусть и самоорганизуются на распределение бонусов :) И конечно все разговоры и уговоры бизнеса на оплату бонусов, овертаймов, рисков также в компетенции PO
    Out of scope
    0. Любое техническое участие в проекте. Бывают конечно совсем экзотические случаи, когда объект деливери и есть код, и тогда без технического review by PO никакого acceptance не будет. Но by default – продукт есть черный ящик, который либо работает, либо нет.
    1. Вопросы мотивации, компетенции, производительности каждого члена команды. Фактически, у PO есть две метрики – сделанные фичи/запланированные фичи и дата dead line. Не его задача разбирать ПОЧЕМУ burdown chart хреновый, его задача – знать как реагировать на хреновый burdown chart и что делать в том или ином случае.
    2. Внутренняя кухня спринта. Да хоть один человек все делает, а остальные курят и в игрушки играют. Если дело сделано – плевать, если нет – тем более плевать кто виноват.

    • May 18th, 2011 at 09:57 | #10

      Антон,
      Мне кажеться, что ты круто описал функцию Proxy Product Owner-а, когда ее выполняет кто-то из команды.
      Даже осталось впечатление, что эту функцию выполняет SCRUM MASTER.

      Хорошо получилось для Proxy :)

      • May 18th, 2011 at 10:29 | #11

        АФАИК SM есть 1/2 классического Project Manager ответственная за процесс и техническую часть разработки. Тут можно тоже много и со вкусом писать про Scope и Out of Scope, но задачи бизнеса не совсем работа SM, нет?
        Я брал за основу развернутый случай PO, когда он не является владельце бизнеса и не платит из своего кармана. Если же PO == владелец бизнеса, то достаточно исключить из Scope пункты №№0, 4 и изложить в измененной редакции следующие
        3. Быть источником бизнесс-информации для команды в режиме 24/7/365. Уметь объяснить, уточнить, раскрыть бизнесс-задачу фичи. Сюда входит, в том числе, умение объяснить на ретроспективе, почему это хорошо, а это плохо. И как должно выглядеть то, что плохо, чтобы быть хорошо
        5. Вопросы мотивации команды в целом с точки зрения бизнеса. Т.е. команда поработала хорошо – вот вам ребятки бонус в N долларов, делите его как хотите. Тут важно – не “Васе 3 доллара”, “Пете 5 долларов”, “Алене 10 долларов”, а “Ивану 0 долларов”, а команде N долларов. У нас вдеь самоорганизующаяся команда? Вот пусть и самоорганизуются на распределение бонусов

        Так уже не Proxy?

      • Dmytro Lapshyn
        May 18th, 2011 at 15:20 | #12

        Proxy PO потому и придумали, что редкий заказчик в достаточной мере выполняет пункты 1-3 (с четвертым и пятым обычно проблем меньше, так как здесь заказчик сразу ощущает эффект в денежных единицах)

        А пункт 0 из оригинального описания Антона – этим, скорее, занимается project manager или даже account manager. Который может быть и Proxy PO по совместительству, да.

  6. May 18th, 2011 at 11:11 | #13

    > Быть источником бизнесс-информации для команды в режиме 24/7/365
    Жестко как. Прямо уж и домой сходить нельзя? :)

    > Вот пусть и самоорганизуются на распределение бонусов

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

  7. Dmytro Lapshyn
    May 18th, 2011 at 15:22 | #14

    skipper_joe :
    Идея самоорганизующейся команды – не работает сама по себе.

    Работает, но при условии достаточной профессиональной зрелости всех или по крайней мере подавляющего большинства ее участников. Впрочем, в аутсорсе с его тенденцией экономить на labor cost можно сказать что, да – сама по себе не работает.

    • May 19th, 2011 at 10:43 | #15

      Dmytro Lapshyn :
      Работает, но при условии достаточной профессиональной зрелости всех или по крайней мере подавляющего большинства ее участников.

      У самоорганизующейся команды есть несколько отрицательных моментов:
      1. Непонятно кто несет ответственность за ошибки (перед Product Owner’ом?) в случае проколов. Хорошо если кто-то из команды взял ответственность на себя. А если нет?
      Я неоднократно наблюдал ситуацию когда члены команды – специалисты достаточно высокого уровня и видимо обладают “профессиональной зрелостью” но прокол происходит где-то между зонами их ответственности и никто не хочет и/или не может решать проблему. Что тогда делать?
      2. Непонятно кто должен принимать решения о составе команды – добавлять и убирать людей из команды, принимать решение о премия/повышениях (см. исходный пост про бонус).

      Т.е. это работает только пока в проекте все хорошо и внешние условия не меняются.

      • Dmytro Lapshyn
        May 23rd, 2011 at 15:42 | #16

        skipper_joe :
        1. Непонятно кто несет ответственность за ошибки (перед Product Owner’ом?) в случае проколов. Хорошо если кто-то из команды взял ответственность на себя. А если нет?

        Встречный вопрос – так уж ли на самом деле Product Owner’у важно, виноват конкретный Вася или Петя? Для него команда – это “черный ящик”, который либо выдает нужную производительность, либо нет. И, если PO что-то не устраивает, он дает обратную связь всей команде (“Ребята, мне в последнее время не нравится скорость вашей работы”) – а дальше уже дело Scrum Master’а / Coach’а созвать народ на ретроспективу и совместно с командой (!) определить причину проблем выработать план по реализации улучшений.

        skipper_joe :
        Я неоднократно наблюдал ситуацию когда члены команды – специалисты достаточно высокого уровня и видимо обладают “профессиональной зрелостью” но прокол происходит где-то между зонами их ответственности и никто не хочет и/или не может решать проблему. Что тогда делать?

        Вот как раз на этот случай и есть “тренер”, т.е. Scrum Master / Coach (название отличается в зависимости от выбранной методологии, но суть, вообщем-то, одна и та же).

        skipper_joe :
        2. Непонятно кто должен принимать решения о составе команды – добавлять и убирать людей из команды

        Принимать окончательное решение по людям должен Project Manager, исходя из соображений бюджета и доступности ресурсов. НО: ИМХО за командой остается право как наложить вето на найм определенного человека (если, например, команда явно понимает, что с ним не сработается), так и решения по исключению кого-либо из команды должны ей же и инициироваться.

        И да, это не опечатка: Agile не исключает роли PM целиком и полностью, но отбирает полномочия по директивному управлению.

        skipper_joe :
        2. Непонятно кто должен … принимать решение о премия/повышениях (см. исходный пост про бонус).

        Бонус выделяет заказчик, далее, сама команда должна решать, что с ним делать – коллективно пропить/прогулять, раздать всем поровну, и т.п. Главное здесь, как правильно говорили выше – не допустить дележа из серии “Васе больше, Пете меньше”.

        Премии, ИМХО – те же бонусы, только выплачиваются не заказчиком, а нанимателем, и премироваться должна команда целиком. Как только начинается индивидуальная мотивация – про командный дух можно забыть.

        Повышения – тут зависит от конкретной организации, как правило, в этом принимают непосредственное участие PM и линейный функциональный менеджер сотрудника.

  8. May 18th, 2011 at 17:10 | #17

    Я згідний із думкою, що РО – це суміш між бізнес-аналітиком та проектним менеджером.

    Функції, які виконує РО зі сторони проектного менеджменту:
    1. Робить структурну декомпозицію робіт на бізнес-рівні. Останній рівень декомпозиції – юзер-сторі. Формує беклог продукту, тим самим зафіксувавши початковий об’єм робіт.
    2. Пріорітезує беклог
    3. Планує к-сть ітерацій на основі попередньої оцінки команди. Фактично за допомогою цього РО керує тривалістю всього проекту.
    4. Керує комунікаціями між всіма зацікавленими сторонами.
    5. Керує якістю проекту, через створення Acceptance Criteria та прийняття завдань на демонстраціях.
    6. Керує різного роду змінами в проекті між спрінтами на рівні замовника та виконавця. Керування змінами зводиться або до збільшення кількості спрінтів, або до зменшення кількості функціоналу.
    7. Координує бюджет проекту, знаючи вартість кожного функціоналу на рівні ЮС

    Функції, які виконує РО зі сторони бізнес-аналізу
    1. Визначає цілі проекта
    2. Збирає вимоги з замовника.
    3. Пріорітизує вимоги із замовником на основі цілей проекта.
    4. Деталізує вимоги до ЮС. Робить все необхідне, щоб ТЗ виконувалось із мінімальною кількістю запитаннь зі сторони виконавців.
    5. Координує змінами в вимогах.

    Що не входить в обов’язки РО
    1. Робити декомпозицію ЮС на задачі.
    2. “Роздавати” задачі людям
    3. Оцінювати задачі
    4. Визначати фокус-фактор команди
    5. Проектувати архітектуру системи

    Фактично РО – це проектний менеджер на “макро” рівні. А скрам мастер – проектний менеджер на рівні ітерацій.

    Відносини в них суттєво “ділові”
    Я специфікація на 1 спрінт на вході. На виході має бути функціонал, який відповідає специфікації. На демонстрації спрінта іде перевірка між входом і виходом та “закриття” ітерації формальним прийняттям продукту.

    • May 18th, 2011 at 19:13 | #18

      Костянтин,
      Дуже дякую, дуже багато класних iдей. Занотував.

      У меня вопрос:
      Как именно происходит “координация изменений в требованиях” и “управление коммуникациями между заинтересованными сторонами”?

  9. May 19th, 2011 at 08:33 | #19

    По-моему, основная функция PO – это все-таки Product Management, а не Project Management или Business Analysis. Хотя, безусловно, какие-то элементы PM и BA сюда попадают. Отсюда его основные функции:
    1. понимание своего бизнеса или бизнеса, в котором он работает
    2. понимание _целей_ разработки продукта, рынка, пользователей
    3. придумывание новых фич (опускание на уровень ниже)
    4. донесение всего этого добра до команды
    5. приоритезация, планирование
    6. проверка результата
    7. и последнее – право принятия последнего решения в рамках своих функций

    Является ли часть этих функций функциями PM или BA? Возможно, но все-таки PO должен быть больше ориентирован на создание успешного продукта, в то время как PM ориентирован на управление проектной командой, чтобы она создала продукт в рамках бюджета, сроков и т.д.

    BA – это вообще роль вынужденная, связующая. BA понимает специфику разработки ПО (чего часто не понимает клиент), и в то же время умеет понимать и анализировать бизнес-процессы, бизнес-цели и бизнес-нужды (чего часто не умеет проектная команда). В какой-то степени это очень умное передаточное звено, переводчик. Должен ли PO быть бизнес-аналитиком? Ровно настолько, насколько это нужно для выполнения своих функций – понять свой бизнес и нужды пользователей -> перевести это в требования, понятные команде (благо, agile упрощает этот процесс донельзя).

    Если же PO на нашей стороне и это просто proxy клиента, то да, здесь он должен быть наполовину BA, на 40% хороший коммуникатор, и еще на 10% – PM. Его функции немного дополняются необходимостью выяснять все у заказчика, но в целом суть остается той же.

    Отсюда что не должен делать PO, с моей точки зрения:
    1. Управлять командой напрямую, раздавать задачи (Вася делает это, Петя – это)
    2. Принимать технические решения. Можно советовать, принимать решения, которые зависят от финансирования, просить объяснений, настаивать, но если команда считает по-другому – пусть считает
    3. Влиять на процесс оценки задач. Опять же, если команда не занимается откровенным саботажем

    Сорри за многа букафф.

    • May 19th, 2011 at 10:55 | #20

      @Merle
      Вот с анти-примерами получилось классно! Четко описаны действия.

      А с тем что ДЕЛАТЬ, немножко обще:
      Как эффективно проверить результат?
      Как Эффективно придумать и приоритезировать фичи?

      Буду признателен за примеры…

      • May 19th, 2011 at 12:23 | #21

        Согласен, что обще написал. Моей целью было увести дискуссию немного в сторону Product Management, потому что это, на мой взгляд – самое главное для PO, а не PM и BA-активности, на которых стали заострять внимание.

        >> Как эффективно проверить результат?
        Я больше имел в виду контролировать, а не проверять. PO может проверить, что запланированные фичи сделаны, но вряд ли он должен проверять их качество. Он должен проконтролировать результаты проверки качества профессионалами из той же проектной команды.

        >> Как Эффективно придумать и приоритезировать фичи?
        Если мы говорим о продукте, то это вопрос анализа нужд пользователей и рынка, конкурентов, целей владельцев бизнеса, то есть это R в R&D. Как это делать эффективно – нужно смотреть опять же области, которые входят в продакт менеджмент.
        С приоритезацией немного проще: можно использовать ожидаемый ROI, ожидания пользователей от следующей версии, технические особенности (иногда фичу А нельзя или намного дороже сделать раньше фичи Б), здравый смысл, в конце-концов.

  10. May 19th, 2011 at 09:32 | #22

    > Как именно происходит “координация изменений в требованиях”

    Зі сторони команди, це можливість перервати спрінт через певні причини. В даному випадку, РО має розібратися в причинах з скрам мастером і надати наступний спрінт беклог.

    Зі сторони замовника – зібр фідбеків на презентації продукта і внесення їх в інші спрінти. Нові більш-пріорітетні ЮС витісняють менш-пріорітетні на наступний спрінт. Приймає рішення з замовником про необхідність створення додаткових спрінтів.

    “управление коммуникациями между заинтересованными сторонами”?

    Фактично РО створює план комунікацій на основі якого він буде збирати вимоги в проекті і писати ЮС. Формує динамічну звітність по проекту. Яка к-сть функціоналу була запланована, яка виконана, з якою ефективністю ми використовуємо бюджет (фокус-фактор), який функціонал був доданий в беклог, який відмінений.

    Зі сторони виконавця він має бути обов’язково присутній на плануванні спрінта і передати всі вимоги в вигляді ЮС від замовника до виконавця. Також він має бути присутній на скрам-мітінгах, щоб відповідати на поточні питання пов’язані із бізнес-вимогами.

  11. May 24th, 2011 at 21:31 | #24

    Dmytro Lapshyn :

    skipper_joe :
    1. Непонятно кто несет ответственность за ошибки (перед Product Owner’ом?) в случае проколов. Хорошо если кто-то из команды взял ответственность на себя. А если нет?

    Встречный вопрос – так уж ли на самом деле Product Owner’у важно, виноват конкретный Вася или Петя? Для него команда – это “черный ящик”, который либо выдает нужную производительность, либо нет. И, если PO что-то не устраивает, он дает обратную связь всей команде (“Ребята, мне в последнее время не нравится скорость вашей работы”) – а дальше уже дело Scrum Master’а / Coach’а созвать народ на ретроспективу и совместно с командой (!) определить причину проблем выработать план по реализации улучшений.

    skipper_joe :
    Я неоднократно наблюдал ситуацию когда члены команды – специалисты достаточно высокого уровня и видимо обладают “профессиональной зрелостью” но прокол происходит где-то между зонами их ответственности и никто не хочет и/или не может решать проблему. Что тогда делать?

    Вот как раз на этот случай и есть “тренер”, т.е. Scrum Master / Coach (название отличается в зависимости от выбранной методологии, но суть, вообщем-то, одна и та же).

    skipper_joe :
    2. Непонятно кто должен принимать решения о составе команды – добавлять и убирать людей из команды

    Принимать окончательное решение по людям должен Project Manager, исходя из соображений бюджета и доступности ресурсов. НО: ИМХО за командой остается право как наложить вето на найм определенного человека (если, например, команда явно понимает, что с ним не сработается), так и решения по исключению кого-либо из команды должны ей же и инициироваться.
    И да, это не опечатка: Agile не исключает роли PM целиком и полностью, но отбирает полномочия по директивному управлению.

    skipper_joe :
    2. Непонятно кто должен … принимать решение о премия/повышениях (см. исходный пост про бонус).

    Бонус выделяет заказчик, далее, сама команда должна решать, что с ним делать – коллективно пропить/прогулять, раздать всем поровну, и т.п. Главное здесь, как правильно говорили выше – не допустить дележа из серии “Васе больше, Пете меньше”.
    Премии, ИМХО – те же бонусы, только выплачиваются не заказчиком, а нанимателем, и премироваться должна команда целиком. Как только начинается индивидуальная мотивация – про командный дух можно забыть.
    Повышения – тут зависит от конкретной организации, как правило, в этом принимают непосредственное участие PM и линейный функциональный менеджер сотрудника.

    Якщо проколи зі сторони неякісних вимог (недостатня деталізація, недооднозначність, розмитість) – несе відповідальність PO

    Якщо продукт вкінці спрінта був випущений не в відповідності з вимогами – несе відповідальність Scrum Master

    • May 25th, 2011 at 08:47 | #25

      А что, Scrum Master должен как-то тестировать продукт, чтобы определить, соответствует от требованиям или нет? Ответственность за качество несет команда, SM лишь “модерирует” взаимоотношения между PO и командой, вовремя оповещает PO о проблемах и помогает их решать, следит за тем, чтобы команда занималась нужными с точки зрения PO задачами. Это мое понимание.

  12. May 25th, 2011 at 09:50 | #26

    Merle :
    А что, Scrum Master должен как-то тестировать продукт, чтобы определить, соответствует от требованиям или нет? Ответственность за качество несет команда, SM лишь “модерирует” взаимоотношения между PO и командой, вовремя оповещает PO о проблемах и помогает их решать, следит за тем, чтобы команда занималась нужными с точки зрения PO задачами. Это мое понимание.

    Scrum Master несе відповідальність за поставку продукту ітерації. Звісно, якщо опуститися на рівень нижче, то за якість продукту несе відповідальність виконавець і QA, але кінцева відповідальність за якість продукту згідно із специфікацією лежить на скрам мастері. Він розбиває ЮС на задачі. Він відповідає за оцінку, він деталізовує ЮС до технічного рівня. На основі його задач тестер складає тест кейси.

    • May 25th, 2011 at 10:46 | #27

      Не согласен. Насколько я понимаю (это важная оговорка!), вопросами детализации ЮС до уровня задач занимается команда. CM лишь создает условия для этого (проводит митинг, модерирует процесс, короче, фасилитирует :)). И до технического уровня он ничего детализировать не должен и зачастую не может, т.к. сам не всегда является техническим специалистом. То, что описываете вы – функции лида/менеджера проекта в классическом подходе к разработке (не важно, ватерфолле или итеративном).

  13. Jun 16th, 2011 at 21:04 | #28

    Как прочитавший эту страницу только сейчас, хочу спросить: Таки есть уже должностная инструкция Product Owner’а?

    • Jun 17th, 2011 at 06:03 | #29

      Константин, собираю. Хочется добавить еще и своих мыслей, да командировка выбила совсем из рабочего ритма :)

      • stasleo
        Feb 24th, 2014 at 23:50 | #30

        таки собрали? я что-то не нахожу в блоге. или плохо ищу.

      • Mar 2nd, 2014 at 21:58 | #31

        Да, собирал, но результат вышел довольно размытый. Так и не собралось единого мнения. Тогда пошел читать классиков типа Mike Cohn. Он как-то получше там пошел.

  14. Vladsky
    Jan 11th, 2013 at 10:41 | #32

    получилось ли создать такую инструкцию?

    • Jan 14th, 2013 at 19:11 | #33

      На тот момент количество ответов было небольшим. Поэтому тогда не вышло. Нужно подумать над “реинкарнацией” этой задачи.

      • stasleo
        Feb 24th, 2014 at 23:51 | #34

        да, было бы замечательно.
        а еще было бы замечательно понять разницу между ПМ, ПО и БА.
        ну и книг почитать каких…)

  15. Banditos
    Sep 26th, 2015 at 15:51 | #35

    Да-да, советуйте, плиз, литературу или ссылками делитесь.

Leave a comment