Пріоритизація задач в беклозі продукту. Проста і ефективна техніка

Гадаю ви чули вислів: якщо все однаково важливе - все однаково неважливе. Нажаль, не знаю, хто це сказав, але ця людина геній. 

Якщо все однаково важливе - все однаково неважливе.

Ваші ресурси обмежені. Ви, як менеджер, маєте намір використати їх максимально ефективно. Що таке "ефектвино"? Мабуть - більше меншими засобами, вірно? :) Це і є концепція ефективної приротизації. 

На цьому можна було б зупинитись, але провсяк випадок поговоримо більше детально. 

Техніки приоритизації

Якщо загуглити "методи пріоритизації", то знайдете цілу купу різноманітних технік. Найбільш відомі - це MoSCoW, RICE, KANO та Value VS Effort. І знаєте, що в них спільного? Вони всі так чи інакше спираються на суб'єктивні фактори. 

Щоб було більш зрозуміло. Що таке "Must have" в концепті MoSCoW? А "Impact" та "Confidence" у RICE? А "User satisfaction" в KANO? 

Це суб'єктивні оцінки чогось, що неможна поміряти заздалегіть. І при цьому всьому вище зазначені моделі пріритизації доволі складні, бо змушують нас оперувати великою кількістю невідомих. Стає логічне питання: невже в нас стільки вільного часу, щоб витрачати його на угадайку?

Вище я вказав посилання на всі моделі пріоритизації окрім Value VS Efort. Помітили? Якщо маєете натхнення, ознайомтесь з ними більш детально. Тут я викладаю моє бачення пріоритизації, з яким ви можете не погоджуватись і це ОК. 

Єдине прохання - не треба ускладнювати прості речі. KISS :)

Далі мова піде лише про Value VS Efort.

Value VS Efort

Чому саме ця техніка? Бо потрібно враховувати єдине суб'єктивне значення. 

Щоб визначити пріоритет елементу беклогу, нам потрібно оцінити скільки людино-годин знадобиться для його реалізації (теж суб'єктивно, але більш менш точно за наявності досвідчених естиматорів) та яке прогнозоване зростання тієї чи іншої метрики ми очікуємо, як наслідок.

Тож в нас є чотири квадранти. Найвищий пріоритет, як бачимо, матимуть ті штуки, що потенційно дадуть найбільший ефект на одиницю витраченого ресурсу. Тобто найбільш привабливим з точки зору бізнесу для нас є перший квадрант.

Не дуже складно, правда? Ну, це як подивитись :) Якщо з естимацією часу розробки все більш менш зрозуміло (якщо ж ви, звісно, надасте розробникам достатньо інформації для оцінки), то з прогнозованим ефектом дещо складніше. Тут нам потрібні різні точки зору, які зроблять оцінку більш об'єктивною.

Все, що ми покладемо в четвертий квадрант - то шляпа повна. 

А що ж будемо робити зі штуками з третього? Вони потребують небагато ресурсів але ж мають невелику цінність. 

Скажу так - це питання бажання, та натхнення. Якщо вважаєте, що імплементація цих штук зробить продукт кращим і зараз є трошки вільного ресурсу для їх імплементації - треба робити.   

Як бонус, ось вам відео від Siemens, яке пояснює, як використовувати техніку Value VS Effort. Замість квадрантів вони використовують сегменти, але суть від того не змінюється.

Сподіваюсь, було цікаво та корисно. Бажаю успіхів!