The Story Writer (неправильно понятая позиция владельца продукта)


Вы владелец продукта?

Вам также может понравиться:
Растет как владелец продукта: пять уровней зрелости владельца продукта

Владелец продукта The Story Writer

Вы встречали их: слегка изогнутая спина, прикованные глаза к экрану, минимизированный размер шрифта и 14-шаговый шаблон в Jira. История, проверьте. Проверка критериев приемки. Примеры, проверьте. Лог-файлы, хмм еще нужно выполнить этот запрос. Макеты, проверьте. Тестовые сценарии, проверка. Связывая все ранее известные проблемы с этой, в процессе, сравните ее с определением готовности на следующей неделе. Обсуждения с командой разработчиков и заинтересованными сторонами приводят к обновленному шаблону или простому утверждению: «Детали в билете».

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

Это часто на языке, который вы можете обнаружить писателя. Многие разговоры касаются деталей в разделе «Журнал незавершенного производства». Команды отступают, когда работа не соответствует определению готовности, что больше похоже на контракт, чем на удобный контрольный список. Когда приращение не дает эффекта, который мы пытаемся достичь, это рассматривается как проблема в описании; шипы, дизайны и «исследовательские истории» являются обычным явлением.

Со многими Владельцами Продукта и Менеджерами Продукта, которых мы обучали и тренировали в их повседневной практике, мы наблюдали следующие образцы в Владельцах Продукта, которые мы бы классифицировали как Авторы историй:

  • Рассказчик как правило, имеет очень хорошо организованный бэклог продукта. Элементы журнала невыполненных работ (как правило, пользовательские истории) в верхней части очень малы, действительно понятны, определены, разработаны, детализированы, оценены и уточнены, чтобы быть на 100% прозрачными. Авторы историй уделяют большое внимание детализации работы, следя за тем, чтобы у команды разработчиков не возникало дополнительных вопросов, поскольку все детали указаны в заявках.
  • Рассказчик имеет острый взгляд на детали, и они любят "копаться" во всех мелочах. Авторы историй отлично подходят для описания пользовательских историй. Они склонны писать пользовательские истории, критерии приемлемости и функциональные описания в течение всего дня.
  • Другие связанные поведения с Рассказчик Тип Владельца продукта: работа в качестве бизнес-аналитика, работа в качестве технического писателя, унаследованная система копирования документов, писец и сборщик заметок.

Такое поведение обусловлено многими причинами, но больше всего мы видим культуру Scrum-In-Name-Only или SINO. Где люди проходят сквозь движения Scrum, не переживая мышления позади него. Товарищи Scrum-тренеры Барри и Кристиан даже разработали детектор для этого.

Коренная причина лежит в тейлористическом мышлении, где кажется более эффективным отделить мышление от делания. Поэтому команде нравятся подробные истории, поэтому их нельзя обвинять в создании неправильной вещи, а владелец продукта максимизирует результаты команды, поскольку они не тратят время на обдумывание альтернативных решений. Так что, без отходов!

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

Не все (владелец продукта) Авторы рассказов одинаковы, и не все результаты / эффекты могут быть видны в вашем контексте. Тем не менее, то, что мы обычно наблюдаем, когда владельцы продукта ведут себя как Авторы рассказов является:

  • Слишком много внимания уделяется деталям, как правило, не ограничиваясь «что» и «почему», но также включая критерии приемки, возможно, проекты / эскизы, функциональную и / или техническую документацию и т. Д. Это слишком много деталей, чтобы Владелец продукта мог записать ,
  • Как правило, авторы рассказов не имеют видения и стратегии и / или не активно делятся видением и стратегией с командой Scrum и ее заинтересованными сторонами.
  • Сосредоточьтесь на деталях, эффектах и ​​краткосрочных результатах.
  • Не фокусируется на долгосрочных результатах (TCO, ROI, P & L и т. Д.).
  • Scrum Team замедляет.
  • Команда Scrum остается зависимой от Владельца продукта, что в конечном итоге замедлит работу команды.
  • Команда Scrum не изучает и не получает больше знаний о бизнесе, области, клиенте и продукте. Это мешает им принимать лучшие, более быстрые и обоснованные решения и тем самым повышает самоорганизацию.
  • Будучи почтовым голубем, лидерство между Командой Скрам и заинтересованными сторонами преобразует первоначальную обратную связь и сообщение от заинтересованных сторон, которые доставляются в Команду Скрам по-разному. Наиболее ценный отзыв для команды разработчиков – это отзывы, которые они получают от заинтересованных сторон напрямую. Не будь фильтром между ними.
  • Команда разработчиков не учатся самоорганизовывать свою работу, они не будут брать на себя ответственность (над планированием, результатами, качеством и т. д.), а контроль всего будет стоить вам гораздо больше работы и времени (что вы не можете потратить на это) более важные вещи).

Дальнейшее чтение

Нужен ли нам действительно владелец продукта?

Зачем вам нужен только один владелец продукта

Роль владельца продукта в разработке программного обеспечения