Приоритет функций

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

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

Ответы (2)

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

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

Штраф — это более субъективный критерий, и вы, вероятно, будете испытывать тревогу заинтересованных сторон, если функция не будет реализована. Другими словами, ценность функции возрастает, если группа заинтересованных сторон расстроена ее отсутствием, несмотря на то, что она не представляет объективной ценности для организации.

Объединение этих двух факторов создает общую оценку ценности .

Риск — это, в частности, неопределенность, которую вы должны принять и смягчить при предоставлении функции.

Стоимость — это прямая стоимость проекта при реализации функции.

Убедитесь, что все ваши функции декомпозированы с одинаковым уровнем специфичности, чтобы обеспечить точность оценки.

Звучит интересно. Как вы присвоили эти значения? Вы просто присваивали номера или были варианты на выбор? Если у вас есть более подробная информация, это было бы очень полезно!
Пришлите мне свой адрес электронной почты на адрес d_espina в сети точек Verizon.
Инструмент отправлен. Дайте мне знать, если это работает для вас.
Выглядит действительно хорошо. Похоже на инструмент, предложенный Майком Коном ( mountaingoatsoftware.com/tools/relative-weighting ), но с добавленным риском, который может быть полезен. Я пытался сделать это один раз, прежде чем собирать информацию от других заинтересованных сторон, но у меня возникли проблемы с объяснением Штрафа. Я думаю, что ваше объяснение (группа заинтересованных сторон расстроена его отсутствием, несмотря на то, что оно не представляет объективной ценности для организации) может помочь сделать его более ясным. Может быть, немного понятнее... Они расстроены, что ее нет, но не готовы за нее доплачивать?
Держите стоимость отдельно от штрафа. Думайте об этом как о группе пользователей, которым нужна эта функция независимо от того, платят они за нее или нет. У меня тоже были / есть проблемы с попыткой облегчить эту часть. Попробуйте зафиксировать оценку без явного извлечения критерия. Вам придется поиграть со своим подходом.

Мне было поручено то же самое. В итоге мы использовали матрицу с двумя осями. Одна ось — это частота появления (т. е. функция xyz будет использоваться каждым пользователем каждый раз, когда они используют приложение, а функция abc будет использоваться некоторыми пользователями иногда и т. д. и т. д.). Другой осью был уровень выгоды для пользователя/выгоды для компании/ROI (т.е. функция xyz повышает удовлетворенность клиентов, а функция abc увеличивает доход компании).

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

Вы будете удивлены тем, как мало дел попадает в рейтинг «Высокий», если вы оцениваете их объективно по сравнению со всеми остальными.

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

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