Использование Scrum в небольших проектах, в которых владелец не хочет участвовать

9

В последнее время я много читаю и изучаю Scrum, и мне это очень нравится. Однако у меня в голове есть несколько вероятных сценариев, решение которых я не знаю. Итак, допустим, я мог бы организовать гибкую команду (например) из четырех веб-разработчиков (один из них - дизайнер UI / UX). Эта команда будет работать на принципах схватки.

Первоначально мы, вероятно, работали бы над проектами, такими как целевые страницы для малого бизнеса простых людей, такими как аренда квартир, продажа куки-файлов ... Такие клиенты просто не могут быть назначены на роль Владельца продукта (IMHO), потому что они обычно ожидают нанять компанию дайте им общую цель проекта с некоторыми деталями, а затем ожидайте, что работа будет выполнена (включая принятие большого количества решений) с как можно меньшим их участием (по их мнению, у них есть более важные дела). Скажем, я хотел бы заниматься себя в мастер-разработчик / Scrum роли (я знаю, что даже это спорно, будучи членом команды и хватка мастер сразу), так что я просто не должен брать на себя роль владельца продукта как хорошо.

Что касается моих вопросов: если я владелец бизнеса моей компании, нужно ли мне просто быть владельцем продукта (включают ли эти роли друг друга)? Могу ли я нанять продавца, который может иметь роль владельца продукта? Было бы лучше, если бы это был опытный разработчик, а не продавец? Это даже умный ход? Наконец, есть ли другой гибкий подход, который мог бы лучше соответствовать моей позиции?


РЕДАКТИРОВАТЬ: Спасибо всем за хороший вклад. Я добавил несколько комментариев, любая дополнительная информация будет принята с благодарностью.

Андрей Мохар
источник
1
Сколько спринтов вам понадобится для создания целевой страницы?
JeffO
Джефф, я понимаю вашу точку зрения, но уже слишком часто случалось так, что некоторые простые целевые страницы оказывались просто такими, с другой стороны, некоторые из них начали расти. Если вы не готовы, вы будете обречены без предварительного планирования. По крайней мере, это мой опыт.
Андрей Мохар

Ответы:

15

Я думаю, что ваша ситуация на самом деле очень распространена, многие клиенты не должны быть вовлечены в уровень самоотдачи, в котором нуждается роль РО.

Это очень обычный подход «PO proxy», это кто-то из вашей компании, который общается с клиентом и переводит требования клиента в истории пользователей для команды scrum. Конечно, вам нужно, постепенно, больше вовлекать вашего реального клиента в ваш процесс, но это не всегда возможно и во многом зависит от вашего типа клиентов, «PO proxy» может быть разумным решением в большинстве сценариев ,

Для этой должности лучше всего подойдет, вероятно, не разработчик и, вероятно, не специалист по продажам, лучше всего подойдет специалист в области бизнеса вашего клиента (в то же время он может быть разработчиком или специалистом по продажам, но его основным навыком является быть экспертом в области).

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

AlfredoCasado
источник
8

По моему опыту, если вы скажете клиенту, что он «владелец продукта», они будут возмущены дополнительной ответственностью. Но если вы говорите, что будете показывать им свой прогресс каждые пару недель, чтобы они могли руководить командой, они с этим справятся. По большей части это то, что делает владелец продукта в любом случае.

tzerb
источник
По большей части это так, хотя я уже работал с некоторыми клиентами, которые вообще не хотели участвовать. Так что иногда это может работать не так, как ожидалось.
Андрей Мохар
3

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

По моему опыту, владелец бизнеса и владелец продукта редко играют одну и ту же роль. Чтобы проверить навыки, требуемые от Владельца продукта, а также их обязанности, посмотрите не что иное, как Scrum Guide .

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

Дерек Дэвидсон PST CST
источник
Я согласен в некоторой степени, но если у меня только небольшая команда, выбор владельца продукта становится очень ограниченным.
Андрей Мохар
0

Я был в подобных ситуациях, и мы никогда не передавали ответственность владельца продукта клиенту. Как вы сказали, клиент не захочет брать на себя эту ответственность. Это требует больших усилий с их стороны, и это не считается лучшей практикой.

У вас должен быть владелец продукта, который является частью вашей команды и обеспечивает, чтобы команда выполняла то, о чем просит клиент. И что более важно, действует в интересах вашей команды. У нее должно быть достаточно опыта, чтобы понять клиента и оценить приоритеты и важность функций, запрашиваемых у клиента.

Иоаннис Цикас
источник
Могу я спросить, почему голосование против?
Иоаннис Цикас
Как я ответил Дереку, довольно сложно иметь небольшую команду и иметь опыт во всех областях, с которыми мы можем столкнуться. Кроме того, я, возможно, неправильно понял роль Владельца продукта, но разве она не должна работать в интересах клиента (AFAIK, Scrum Master работает в пользу команды, и поэтому они хорошо дополняют друг друга, верно?) Кстати, я не был тем, кто тебя голосовал.
Андрей Мохар
Когда я сказал от вашей команды, я имел в виду от вашей компании / организации. Хотя менеджер по продукту является голосом клиента и представляет заинтересованные стороны, он / она по-прежнему выступает в пользу вашей организации / команды. Важно иметь кого-то, кто фильтрует запросы и поглощает давление клиента.
Иоаннис Цикас