Це гарна ідея призначити одного з членів команди scrum або майстра scrum власником продукту?

Нещодавно у нас був проект, в рамках якого клієнт був зайнятий гастролями. Як завжди було сформовано команду scrum, керівництво вирішило призначити нашого аналітика власником продукту, оскільки Клієнт не зможе активно брати участь. Аналітик був тим, хто тісно співпрацював із клієнтом для аналізу вимог та складання специфікацій.

Клієнт не має часу переглянути перші два випуски. Все пройшло гладко, поки клієнт побачив третій реліз; він не був задоволений деякими функціоналами, і їх було введено власником Product shift (наш аналітик).

Нам сказали чекати, поки команда дизайнерів закінчить макет всіх сторінок, а клієнт перевірив кожну та затвердив продовження роботи. Команда Scrum є, але спринтів немає - ми закінчили роботу майже як класичний метод водоспаду.

Це гарна ідея призначити члена команди команди або майстра Scrum власником продукту? Чи потрібно нам стежити за сутичками за відсутності участі клієнта / власника продукту?

Лише кілька тижнів тому Майк Кон писав про поєднання ролі майстра scrum та власників продукту у своєму блозі. Я не думаю, що я можу це зробити краще, ніж він, але моє коротке резюме його допису таке:

• це погана ідея
• SM та PO виконують дуже різні види завдань ("завдання зірки" та "завдання опікуна", за словами Кона)
• особа, що поєднує дві ролі, навряд чи зможе добре підходити до всіх завдань, що беруть участь в обох ролях
• команда може постраждати від комбінованих SM / PO, нехтуючи завданнями, в яких вони не найкращі.

Я думаю, що немає нічого поганого в тому, щоб взяти когось із членів команди scrum та перенести його до власника продукту. Але ви повинні усвідомити, що це як акція чи внутрішня передача; це створює дірку в команді, і отвір потрібно заповнити. Можливо, команда може «самореорганізуватися», щоб заповнити яму; можливо, для зайняття вакантної посади потрібно найняти нового працівника.

Ваш процес мені здається прекрасним. Ви не описували це докладно, але принаймні, ролі дотримуються (це важливо).

Однак, маючи декілька деталей, які я маю, я бачу певну проблему на рівні власника продукту.

Він / вона повинен забезпечити належне повідомлення замовника про прогрес. Схоже, він робить "водоспад" зовні з замовником і "розбирається" всередині вас.

Результат : водоспад виграє, оскільки клієнт є королем. Навіть якщо в цьому випадку замовник має свою відповідальність ...

Ваша нинішня команда (включаючи Scrum Master) повинна зосередитись на забезпеченні спринту в спринті. Однак власник продукту (аналітик) повинен переконатися, що те, що є у його відстані, відображає те, що хоче клієнт. Вона / він також повинна забезпечити хороше спілкування та участь замовника.

Можливе рішення : надішліть власника продукту (аналітика) на курс власника продукту Scrum або змусьте його прочитати (і зрозуміти) цю книгу: Agile Management Product with Scrum .

Scrum найкраще працює з реальним клієнтом на місці. У роботі із клієнтами, які не звикли до ітеративного дизайну продуктів, є кілька справжніх проблем.

• Синдром чистого аркуша
• Синдром переляканого клієнта

Етапи проектування з чистого аркуша, як правило, дуже швидко виходять в небо, і, як правило, заглиблюються в декілька побічних питань і недостатньо глибини основних функціональних можливостей. Вам справді потрібен солом’яний чоловік, щоб клієнт відібрав для успішних дизайнерських зустрічей. Зосереджуючись лише на одному аспекті, ви допомагаєте своєму клієнту навчитися ітераційному дизайну.

Налякані клієнти (як у вас було зі своїм досвідом) не розуміють, що спритні проекти передбачають певну (контрольовану) кількість переробки як частину процесу. Що їм важко зрозуміти, це те, що в міру розвитку продукту буде менше моментів "О Боже мій". Що ще важливіше, частина більшості клієнтів важко переживає те, що моменти "О мій Боже" не вимагають фіксації грошових навантажень через короткий час між циклами перегляду / планування.

Керувати очікуваннями клієнтів дуже складно. Це прекрасний баланс освіти клієнтів, розміщення та навіть навчитися говорити "ні". Клієнт не завжди може приходити щотижня або щотижня. Іноді вони можуть приходити лише раз на місяць. Гаразд. Поки ви покажете їм, що ви зробили, щоб вирішити їхні проблеми в попередньому місяці, а потім зосередитесь на роботі цього місяця, це пройде довгий шлях до того, щоб проект пройшов більш гладко. Суть полягає в тому, що у відсутності замовника у вас є хтось, хто може дати розумні рекомендації щодо деяких питань. Це потрібно, щоб хтось був знайомий з цілями, які намагається досягти клієнт.

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

Дякуємо за ваш пост Я усвідомлюю, що це старе, але я думаю, що ти зробив чудову справу і ось мій $ 02:

Проблема 1: призначення аналітика аналітиком у вашому випадку серйозно коротко замикає рамки scrum. Чому? Оскільки лише організація з розробки цінних паперів може приймати оціночні оцінки, оцінки рентабельності інвестицій, визначення пріоритетності та рішучий вибір, що випливає з бізнесу, а не від технології, навіть не від ознайомлення з продуктом. Я впевнений, що ваш сер. аналітик зробив фантастичну роботу, наслідуючи PO, але в кінцевому підсумку довелося здогадуватися про потреби, цінності та вибір, які виходитимуть з вашого PO. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . Якщо ваш аналітик не отримав POA від клієнта (навряд чи), вони не зможуть прийняти або відхилити що-небудь при огляді спринту.

Чи може такий підхід спрацювати? Так, але для того, щоб ваш клієнт був поза межами, потрібно було б повністю перекласти обов'язки. Начальнику вашого клієнта потрібно було б погодитись на сурогат, і щоб жодне обґрунтоване прийняте рішення не було відмінено. Звучить вірогідно? Більш ймовірно, що ви отримаєте тимчасову поштову пошту від організації свого клієнта (що, звичайно, не обійшлося без її недоліків!), Але якщо ваш сер. Аналітик працював з тимчасовим спеціалістом, будь-які неправильні рішення надходитимуть від бізнесу, таким чином зберігаючи ролі своєї команди в чистоті.

Проблема 2: "клієнт не встигає переглянути". Велика проблема (і одна, з якою я стикався і нещодавно). Для прийняття товару повинен бути присутній спеціаліст. Ніхто більше не може «підписати чек». Відсутність ПО означає, що невдоволення трапляється пізніше, можливо, більше переробляється та втрачається довіра. Більш принципово я відчуваю, що клієнт не активно займається вашим проектом: немає часу на щоденний стенд, немає часу для відповіді на питання тощо.

Завдання 3: "Нам сказали чекати, поки команда дизайнерів закінчить макет". А зараз геть від скандалу повністю. Люди, які роблять макет, повинні бути частиною вашої перехресної функції. Я не можу сказати, чи це викликано відсутністю розуміння керівництвом scrum або шокової реакцією на ваш третій реліз.

Запитання: Де був ваш майстер scrum у всьому цьому? СМ звичайно визнає небезпеку рольового конфлікту та відсутності участі ВП, як перешкоди / небезпеки, які слід подолати.