Пріоритезація вимог - Gabreal Safm
Пріоритезація вимог – це дуже важливий і водночас досить складний та неясний етап у підготовці до створення продукту. Цей запис покликаний ще раз звернути увагу менеджерів по продукту на цей процес і дати їжу для роздумів.
Дуже часто пріоритезацію вимог не приділяється належна увага, і процес вибору реалізованих можливостей продукту стає спонтанним. А це загрожує всілякими неприємностями: починаючи від зриву термінів і випуску продукту кишить багами, і до провалу всього проекту через відсутність в продукті можливостей, без яких люди не будуть його використовувати/купувати.
У процесі створення продукту ви напевно зіткнетеся з нестачею ресурсів (людей або часу) або грошей. І тоді, вам доведеться виключити якісь можливості з першої версії. Краще, якщо це буде зроблено осмислено, а ще краще, якщо ви відразу підготуєте адекватний список вимог, що відповідає можливостям вашої організації та бюджету проекту.
Нижче я наводжу переклади двох статей, які не те щоб описують 100% рецепти для правильної пріоритезації вимог або розкривають якісь страшні таємниці, але, скажімо так, дають їжу для роздумів. Я думаю, вони будуть корисні будь-якому Менеджеру по продукту.
Істотні та несуттєві вимоги
Однією з найскладніших речей при створенні простого продукту є визначення того, які можливості варто реалізовувати, а які ні. Ми для цього використовували поділ вимог на Істотні та Неістотні. Несуттєві виносили за межі версії 1.0.
Чудовий спосіб відсіяти несуттєві вимоги - це простий фільтр. Якщо вимога починається зі слів «булоби непогано якщо…» або «було б круто якщо…», це зазвичай несуттєве вимога.
Під час розробки Campfire у нас було багато непоганих і крутих вимог. Відмінний спосіб обробити їх - це негайно відкласти їх до версії 1.1. Це означає, що ми розглянемо їх після запуску продукту.
Підсумок : Коли ви створюєте програмний продукт, завжди звертайте увагу на несуттєві вимоги. Переконайтеся, що вони не увійшли до версії 1.0. Вони уповільнюють випуск продукту, вони відволікають вашу увагу, вони вимагають ресурсів, які необхідні для створення якісного ядра продукту, і вони збільшують ймовірність появи помилок.
Стаття 2. Блог Майкла Шріватсана, 1 травня 2006 р.
Пріоритезація вимог – який спосіб найкращий?
Він описує процес пріоритезації вимог, через який пройшла його команда, коли розробляла відомий продукт Campfire, випущений нещодавно. По суті, він вводить поділ вимог на «Істотні» (те, що має бути) і «Неістотні» (непогано/круто було б).
Це підводить нас до питання, як найкраще розставляти пріоритети для вимог? І чи взагалі існує «найкращий» шлях? Як насправді ви вирішуєте, які вимоги віднести до «Суттєвих», а які ні?
Як це робиться у більшості компаній?
Менеджери з продуктів та Менеджери з маркетингу продукту постійно виконують роботу з пріоритезації вимог. Для дорогого B2B-програмного забезпечення, будь-яка вимога, висунута великим користувачем, отримує статус Істотного, в той час як ті, що висуваються ким-небудь зсередини, набувають статусу Неістотного. У невеликих компаніях, вимоги висунуті власником(ами) можуть зрештою стати суттєвими.
Який шлях найкраще?
Теоретично, капітал повинен розподілятися відповідно до максимальної окупності інвестицій (ROI). Окупність інвестицій може бути визначена різними шляхами – але зазвичай вона визначається у фінансових термінах, таких як NPV (net present value – Чистий дисконтований дохід).
При такому підході вимоги потрібно прирітезувати відповідно до фінансової віддачі, яку вони принесуть. Сильно спрощуючи (з метою цієї статті це допустимо), ми можемо сказати, що вимоги повинні пріоритезуватися відповідно до доходів, які вони можуть приносити. Я кажу «доходи» замість «прибуток» (ще точніше «чиста виручка») просто тому, що їх легше оцінити.
Ваші клієнти доплачуватимуть максимальні гроші за ті можливості, які забезпечать їм найбільший ефект у досягненні їх власних цілей.
Як тільки ми зможемо оцінити додаткові доходи для нас і користь для клієнтів, які принесе кожна реалізована можливість (кожна вимога), ми зможемо скласти список відповідно до цих пріоритетів. Звучить просто, так? Ні!
Деякі проблеми
Найперша проблема –Яким чином оцінювати доходи від кожної реалізованої можливості (кожної вимоги)?
Зазвичай за оцінку видаються припущення менеджера з товару чи маркетингу товару. Найчастіше вони використовують для цього які-небудь звіти або дослідження сторонніх організацій, аналіз даних по клієнтам, і ворожіння на кавовій гущі. Іноді відгуки клієнтів теж використовуються, але вони можуть бути дуже громіздкими і неясними. Оцінка майбутніх доходів – це дуже неточна наука!
Іншапоширена проблема - цеСтратегічні потреби. Що якщо вимога може принести високий дохід, але не відповідає «Стратегії компанії/продукту»? Ці потреби зазвичай визначається ким-небудь з начальства і це звичайний спосіб, за допомогою якого воно вносить свій внесок у розстановку пріоритетів.
Ще одна поширена проблема - цеТехнічно можливості. Що якщо вимога може принести високий дохід, але у компанії немає необхідного досвіду (експертизи) для його реалізації? Ці можливості визначаються зазвичай керівником розробки/виробництва. Це найпоширеніший спосіб, за допомогою якого керівники команди розробників сприяють розстановці пріоритетів.
Прикінцеве слово?
З усього вищесказаного випливає, що пріоритезація вимог - це дуже неточна діяльність. Доводиться враховувати безліч факторів, наприклад, у великих компаніях доводиться враховувати, крім усього іншого, ще й корпоративну політику!
Є два основні фактори, які потрібно враховувати: 1) Дохід для компанії, і 2) Користь для клієнтів, але є й інші менш явні фактори, які також потрібно брати до уваги.
Отже, ще раз: Пріоритезація вимог - це складний і моторний, але абсолютно необхідний процес при створенні нового продукту. Приділіть цьому увагу, підійдіть до питання творчо і в майбутньому це збереже вас від багатьох проблем.