Цінність vs. Складність (Value vs. Complexity)
Що таке модель "Цінність vs. Складність"?
Цінність проти складності - це система визначення пріоритетів, яка дозволяє продуктовій команді оцінити кожну ініціативу відповідно до того, яку цінність вона принесе, і наскільки складною або важкою буде її реалізація. Ініціативи потім наносяться на квадрант і відповідно розставляються за пріоритетністю.
Цінність vs. Складність - це одна з багатьох моделей визначення пріоритетів, які менеджери продуктів можуть використовувати для визначення пріоритетності ініціатив у дорожній карті продукту. Це популярний метод серед продуктових команд, які шукають об'єктивний спосіб розподілити час і обмежені ресурси розробки на ініціативи, виходячи з їх сприйнятої або потенційної користі.
Продукт-менеджери часто використовують структуру співвідношення цінності та складності (та її варіації) для стандартизації набору параметрів прийняття рішень. Ці параметри (зазвичай, як випливає з назви, цінність і складність) можуть застосовуватися до всіх функцій, удосконалень продукту, виправлень та інших ініціатив, що конкурують за місце на дорожній карті продукту. Ця об'єктивна методика визначення пріоритетів дозволяє командам розробників застосовувати стратегічні та кількісні міркування для прийняття рішень про те, які ініціативи є пріоритетними, а які відкласти на потім.
Методологія проста. Продуктова команда будує графік або матрицю пріоритетів з осями "Цінність для бізнесу" і "Складність/зусилля". Потім графік розбивається на квадранти наступним чином: висока цінність, низька складність; висока цінність, висока складність; низька цінність, низька складність; і низька цінність, висока складність. Потім команда оцінює кожну ініціативу та наносить її на графік, забезпечуючи візуальне представлення очікуваної цінності кожної ініціативи та необхідних зусиль.
Як працює пріоритизація цінності та складності?
Система співвідношення цінності та складності побудована на матриці пріоритетів, подібній до тієї, що показана тут.
Модель працює наступним чином: Для кожної ініціативи, що розглядається, продуктова команда зробить дві окремі оцінки:
- Яку цінність, на її думку, принесе ініціатива.
- Скільки зусиль буде потрібно для її реалізації.
Метою такого визначення пріоритетів є виявлення тих ініціатив, які обіцяють принести найбільшу користь за найменших зусиль.
Ініціативи, які забезпечують найбільшу цінність і вимагають найменших зусиль, будуть представляти собою найбільш пріоритетні пункти, які слід додати до вашої дорожньої карти продукту. Ініціативи, які знаходяться на іншому кінці спектру - обіцяють відносно низьку цінність для бізнесу і високий ступінь складності в реалізації - ймовірно, повинні бути відкладені в довгу шухляду.
Тепер давайте більш детально розглянемо, як цей процес може виглядати на практиці.
Визначення пріоритетності функцій за моделлю "цінність vs. складність
1/ Визначте показник цінності для ваших функцій
У моделі "цінність проти складності" слід враховувати принаймні два типи цінності.
Цінність, яку ініціатива принесе вашим користувачам або вашому ринку в цілому. Цей тип цінності може включати, наприклад, ступінь, до якого ваша ініціатива зменшить біль користувачів або підвищить їхню ефективність, а також те, наскільки терміново ваш ринок вимагає цього.
Оцінка прямої бізнес-цінності ініціативи для вашої компанії. Ця цінність може бути відображена з точки зору залучення нових клієнтів, утримання існуючих клієнтів, здатності продавати послуги клієнтам, а також очікуваного нового доходу, який принесе ініціатива.
Оцінюючи бізнес-цінність ініціативи, ви, можливо, захочете розглянути декілька факторів. Чи підвищить вона впізнаваність бренду вашої компанії на ринку? Чи впливає ініціатива на достатню кількість клієнтів, щоб зробити її вартою зусиль? (Деякі ініціативи можуть вплинути лише на невелику частину Вашої клієнтської бази та потенційних клієнтів, а отже, мати відносно низьку бізнес-цінність).
Після того, як ви отримали оцінку для кожної з підкатегорій цінності, ви можете об'єднати їх в єдину числову оцінку. Цей числовий показник має відображати загальну оціночну бізнес-цінність ініціативи.
Ви можете вирішити, що одна з цих підкатегорій має більшу вагу, ніж інша. Наприклад, ви можете вирішити, що загальний внесок, який реалізація ініціативи може зробити для вашого бізнесу, заслуговує на більшу вагу, ніж її потенційний вплив на досвід користувачів. Це нормально, якщо ви послідовно застосовуєте свою формулу до всіх ініціатив, які ви оцінюєте.
2/ Визначте оцінку "складності" для кожної ініціативи
Що саме означає складність в системі пріоритетів цінності та складності?
Багато продуктових команд використовують один з умовних позначень - це просто оцінити загальну вартість ініціативи для бізнесу і дозволити цій вартості слугувати показником складності або зусиль, необхідних для її реалізації.
У деяких випадках цієї єдиної метрики може бути достатньо. Але ви також можете піти набагато глибше. Ви можете розділити свою оцінку складності/зусиль на кілька підкатегорій, таких як:
- Операційні витрати
- Години розробника
- Час за розкладом (дні, тижні, місяці)
- Навчання клієнтів, зусилля з міграції та робота з потенційними питаннями або скаргами
- Ризик (включаючи можливість того, що ваша нова ініціатива буде незабаром витіснена новими технологіями або процесами)
- Внутрішні навички розробки (якщо тільки один або два розробники мають знання для реалізації ініціативи, це означатиме відволікання цих розробників від інших проектів, а також те, що прогрес ініціативи може бути затриманий, якщо ці особи захворіють, підуть у відпустку і т.д.)
3/ Нанесіть ініціативи на матрицю та визначте пріоритети
Після того, як ви нанесли кожну ініціативу з вашого списку на матрицю пріоритетів, ви можете вирішити, які з них розмістити у вашій дорожній карті і в якому порядку пріоритетності. Нижче наведено огляд того, що ви знайдете в кожному квадранті.
Висока цінність для бізнесу, низька складність впровадження (верхній лівий кут)
В ідеалі, це будуть ваші головні пріоритети, оскільки вони отримали високі оцінки за цінність і в той же час низькі оцінки за очікувані зусилля. Ви захочете визначити пріоритетність цих функцій або ініціатив над іншими.
Варто зазначити, однак, що ймовірність того, що ви дійсно розмістите запропоновані ініціативи вашої команди в цьому квадранті, є низькою, оскільки, якщо вони настільки важливі і відносно прості у впровадженні, ви, ймовірно, вже завершили їх реалізацію. Насправді, в обговоренні Mind the Product щодо визначення пріоритетів цінності та складності, вони описують це як квадрант "Чому ви робите це зараз?".
Висока цінність для бізнесу, висока складність впровадження (вгорі праворуч)
Ці ініціативи, безумовно, заслуговують на пріоритетність, ймовірно, поступаючись лише вашим ініціативам з високою цінністю та низькою складністю (якщо вони у вас є).
Але ініціативи, які підпадають під цю категорію, можливо, доведеться відкласти через зусилля, необхідні для їх реалізації.
Низька бізнес-цінність, низька складність реалізації (внизу зліва)
Ця категорія може являти собою список ініціатив вашої команди. Вони мають низьку бізнес-цінність, але можуть представляти собою корисні функції, виправлення або інші елементи, які варто додати до вашого продукту, особливо тому, що вони також не вимагають багато роботи або зусиль від вашої команди розробників.
Можливо, ви захочете відкласти ці елементи на періоди, коли ваша команда розробників переходить від одного проекту до іншого або має короткі цикли простою. Вони представляють можливість отримати невеликі перемоги, не витрачаючи багато зусиль або ресурсів.
Низька вартість бізнесу, висока складність впровадження (внизу праворуч)
Якщо у вас немає законної причини для того, щоб викроїти час для роботи над ініціативою, яка не має великої бізнес-цінності, а також обіцяє бути складною в реалізації, вам, ймовірно, слід повністю викреслити ці пункти зі свого списку.
Насправді, одна з найкращих причин використовувати модель визначення пріоритетів за критерієм "цінність - складність" - це допомогти вашій команді виявити ці малоцінні ініціативи, що вимагають великих зусиль, щоб не витрачати на них важливий час і ресурси на розробку.
Коли слід використовувати модель Цінність vs. Складність (Value vs. Complexity)?
Менеджери продуктів можуть використовувати багато фреймворків для визначення пріоритетності функцій, тож коли вашій команді слід використовувати підхід "Цінність vs. Складність"? Оскільки він пропонує об'єктивний, кількісно вимірюваний метод зважування потенційної вигоди кожної ініціативи та зусиль, яких вона вимагатиме, ця модель може бути корисною в будь-якому сценарії визначення пріоритетів. Але ось кілька прикладів того, де модель "Цінність проти Складності" може бути особливо корисною:
1/ Коли ви розробляєте новий продукт.
Продуктові команди зі зрілими продуктами, швидше за все, не виявлять багато можливостей, що не висять на волосині, в матриці пріоритетів "цінність проти складності" - ті ініціативи "висока цінність, низькі зусилля" у верхньому лівому квадранті. Якщо продукт є достатньо успішним, зрілим і все ще перебуває на ринку, то, швидше за все, команда вже впровадила елементи, які забезпечили високу цінність і не вимагали багато зусиль для створення.
Але з новим продуктом ця структура може допомогти команді виявити ці високоефективні ініціативи. Тому, безумовно, варто спробувати, коли ви перебуваєте на ранніх стратегічних етапах розробки нового продукту.
2/ Якщо у вас дуже короткі часові рамки або дуже обмежені ресурси для розробки.
У випадках, коли вашій команді вкрай не вистачає ресурсів, ви можете обмежитися лише проектами низької складності або з низьким рівнем трудомісткості. Іншими словами, навіть якщо ініціатива має високий пріоритет, вона може бути просто нездійсненною з огляду на ваші часові або кадрові обмеження.
У таких випадках корисно мати уявлення про те, що ви можете зробити з наявними у вас ресурсами.
3/ Коли ви хочете застосувати більш об'єктивну лінзу до ініціатив, до яких ваша команда ставиться дуже позитивно (або дуже негативно).
Команди часто виявляють цікаву інформацію про запропоновані ініціативи у своєму списку, коли вони піддають ці ініціативи вправі визначення пріоритетів за критерієм "цінність проти складності".
Тільки після того, як вони нанесуть їх на матрицю пріоритетів, наприклад, вони зрозуміють, що, можливо, причина, через яку багато хто в організації виступав проти ініціативи, полягає не в тому, що вона не принесе реальної цінності для бізнесу - вона, безумовно, принесе, - а в тому, що вона представляє собою багато складної роботи.
Аналогічно, коли команда розробників завершить цю вправу з визначення пріоритетів і застосує свою формулу бізнес-цінності до даної ініціативи, вона може виявити, що ентузіазм команди розробників щодо цієї ініціативи ґрунтувався не на її потенційній цінності для компанії, яка є відносно низькою, а на тому, що вони були захоплені технологією або процесом розробки, над яким ця ініціатива дозволила б їм попрацювати.
Матриця пріоритетів цінності та складності змушує вашу команду створити візуальне уявлення про те, що стоїть за кожною запропонованою ініціативою - хороша вона чи погана.
Висновок
Модель "Цінність vs. Складність" може бути корисною стратегією для продуктових команд, які намагаються перетворити довгий список запропонованих функцій, удосконалень та інших елементів в стратегічно обґрунтований список пріоритетів.
Інші методи визначення пріоритетів продукту (Prioritization Frameworks):
- Kano
- MoSCoW method
- Цінність vs. Складність (Value vs. Complexity)
- RICE scoring model
- Групування спорідненості (Affinity Grouping)
- Opportunity scoring
- WSJF
- Buy-a-feature і схожий The 100 Point Method
- Story mapping
- ICE Scoring
- Зважена оцінка (Weighted Scoring)
- PriX
- Value vs. effort
- The product tree
- Cost of delay
Що ще треба допрацювати в ст