Есть ли у кого-нибудь опыт управления продуктом снизу вверх? По сути, заставить свои команды определиться с функциями и направлением продукта?
В большинстве моих предыдущих команд менеджеры по продукту и заинтересованные лица принимали решение о функциях и темах, а затем я заставлял свои команды писать пользовательские истории и задачи для выполнения этой дорожной карты.
Однако с моей нынешней командой нам повезло, что мы получили больше контроля. У нас все еще есть ограничения, но нам, по сути, разрешено управлять продуктом снизу вверх. Организация определила направление на год высокого уровня, но мы должны решить, какие функции необходимы.
Есть ли у кого-нибудь хорошие методы заставить скрам-команды сделать это?
Моя первоначальная идея заключалась в том, чтобы просто создать групповую воронку, в которой все люди могли бы отправлять идеи, собранные на вики или что-то в этом роде, и обозначать сложность и влияние своих представлений. Тем не менее, идея немного странная, и я хочу, чтобы функционал был готов через месяц или два, так что, возможно, потребуется мастер-класс.
Вы можете подумать об использовании такой техники, как картирование историй .
Также стоит поговорить с командой о том, как они определяют ценность. Имея более четкое представление об этом, вы сможете лучше расставить приоритеты в невыполненной работе.
Я думаю, что Scrum делает именно то, что вы хотите. Команда в целом добавляет элементы в бэклог (уточнение бэклога), а Владелец продукта — это человек в команде, который устанавливает приоритеты.
Если у вас еще нет четкого права собственности на продукт, вам необходимо решить, как будут осуществляться отчетность и контроль и, что наиболее важно, как будет измеряться ценность бизнеса. Наличие этих годовых целей — это начало, но вряд ли этого будет достаточно из-за присущего таким долгосрочным целям риска. Чтобы добиться успеха, команда должна будет добиваться результатов с каждой итерацией, получать отзывы заинтересованных сторон, а затем адаптировать свой подход на основе этих отзывов. Роль PO состоит в том, чтобы сделать это возможным и таким образом оптимизировать ценность работы, которую выполняет команда.
Как упоминалось в других ответах, вы можете выполнить упражнение по картированию историй, но сначала вы можете рассмотреть возможность согласования всех заинтересованных сторон с системой определения приоритетов и целями / темами / эпиками высокого уровня (для продукта, который вы создаете).
Основная проблема подхода «снизу вверх» заключается в расхождении идей разных людей, которые могут или не могут быть согласованы с поставленными целями/проблемами. Если участники знают ключевые проблемы, которые им необходимо решить, а также общее представление о том, как их задачи будут расставлены по приоритетам по сравнению с другими идеями, невыполненная работа будет более четкой с самого начала.
По-настоящему интересный способ — провести Дизайн-спринт . Далее следуют карты влияния и истории пользователей .
В зависимости от вашего продукта, выйдите из чертового здания и позвольте разработчикам поговорить с реальными пользователями. Возможно, вы изучите программу Shiftup , которая поможет вам поддерживать непрерывные инновации.
Объедините команду с пользователями и ключевыми заинтересованными сторонами, начните и поддерживайте диалог и обратную связь и откройте для себя возможности ВМЕСТЕ !
Я также могу порекомендовать метод User Story Mapping. С его помощью вы можете направить свою команду в одном направлении, и все члены команды смогут планировать проект. Если в процесс планирования вовлечены все, степень ответственности намного выше.
Я часто вижу, как команды используют подходы «сверху вниз» и «снизу вверх» одновременно. Но, опять же, может быть, я использую термин «снизу вверх» немного по-другому.
«Истории пользователей» для меня — сверху вниз: «В этом здании будет великолепная каменная арка над главным входом».
Но кто-то в то же время работает снизу вверх, выясняя, как на самом деле реализовать эти вещи в более широком контексте целого. «Чтобы сделать это, на 41-й день нам понадобится временная опорная конструкция, способная выдержать 2300 фунтов. Она должна быть спроектирована именно так. Поэтому к 36-му дню фундамент должен быть готов. место и протестированы, чтобы убедиться, что они выдержат вес».
Команды разделяются, чтобы одновременно смотреть на оба конца и быть уверенными, что они встретятся посередине.