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

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

У клиента нет времени на просмотр первых двух выпусков. Все шло гладко, пока клиент не увидел третий выпуск; он не был удовлетворен некоторыми функциями, и они были введены владельцем продукта make shift (нашим аналитиком).

Нам сказали подождать, пока команда дизайнеров закончит макет всех страниц, и клиент проверит каждую из них и одобрит продолжение работы. Скрам-команда есть, но спринтов нет - мы закончили работу почти как классический водопад.

Является ли хорошей идеей назначить члена команды Scrum или мастера владельцем продукта? Нужно ли нам следить за схватками в отсутствие участия клиента / владельца продукта?

Всего несколько недель назад Майк Кон написал в своем блоге о совмещении ролей мастера и владельца продукта. Я не думаю, что могу сказать это лучше, чем он, но мое краткое резюме его поста таково:

• это плохая идея
• SM и PO выполняют очень разные виды задач («звездные задачи» и «задачи опекуна», по словам Кона)
• человек, совмещающий две роли, вряд ли подойдет для всех задач, связанных с обеими ролями
• объединение SM / PO может повредить команде, пренебрегая задачами, в которых они не самые лучшие.

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

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

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

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

Результат : выигрывает водопад, так как клиент - король. Даже если в этом случае клиент несет свою ответственность ...

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

Возможное решение : отправьте своего владельца продукта (аналитика) на курс для владельца продукта Scrum или попросите его прочитать (и понять) эту книгу: Agile Product Management со Scrum .

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

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

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

Испуганные клиенты (как вы имели с вашим опытом) не понимают, что гибкие проекты предполагают определенный (контролируемый) объем переделок как часть процесса. Что им трудно понять, так это то, что по мере развития продукта будет меньше моментов «Боже мой». Что еще более важно, с большинством клиентов приходится сталкиваться с трудностями в том, что моменты «Боже мой» не требуют больших затрат денег из-за короткого промежутка времени между циклами обзора / планирования.

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

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

Спасибо за ваш пост. Я понимаю, что он старый, но я думаю, что вы подняли отличный случай, и вот мои $ .02:

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

Может ли этот подход работать? Да, но должен быть полный переход обязанностей, пока вашего клиента нет. Начальник вашего клиента должен будет согласиться на замену, и что никакие разумные решения не будут отменены. Звучит скорее всего? Более вероятно, что вы получите временное ПО от организации вашего клиента (что, конечно, не без недостатков!), Но если ваш sr. Аналитик работал с временным ПО, любые неправильные решения будут исходить из бизнеса, таким образом поддерживая чистоту ваших командных ролей.

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

Задача 3: «нам сказали подождать, пока команда дизайнеров не закончит макет». А сейчас полностью разошлись. Люди, делающие макет, должны быть частью вашей межфункциональной команды. Я не могу сказать, вызвано ли это отсутствием понимания со стороны руководства или шоковой реакцией на ваш третий релиз.

Вопрос: Где был ваш мастер схватки? SM обычно признает опасность конфликта ролей и отсутствия участия в ПО, что является препятствиями / опасностями, которые необходимо устранить.