Переваги підходу MVP — я розшифровую жаргон компанії програмного забезпечення, на якому ти говориш

Sławomir Wnuk

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

В останньому фіналі Ліги чемпіонів, під час якого волейболісти Grupa Azoty ZAKSA Kędzierzyn-Koźle перемогли Itas Trentino з рахунком 3:0, цього титулу удостоївся Каміль Семенюк.

Але я не хотів писати про таланти волейбола.

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

Про що мова?

Дозволь пояснити.

Що таке мінімально життєздатний продукт?

Це версія системи з достатньою кількістю можливостей для активного використання.

MVP має відповідати основним припущенням і бути «придатним для використання». Це також має вирішити основну проблему, з якою стикається організація – бенефіціар програмного забезпечення.

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

MVP також є відображенням принципу Парето, згідно з яким 80% потреб користувачів задовольняються 20% функціональності системи.

Правильно сконструйований мінімально життєздатний продукт проілюстровано на наступному малюнку.

Використовуючи графічну метафору, коли твоя мета — побудувати фургон, ти не пробуєш втілити цю ідею на одному колесі чи перероблюючи велосипед. Зовсім інша справа базовий мотовізок.

І коли отримаєш перші думки про те, як це використовувати – на їх основі ти якісно і адекватно доопрацюєш свій проект. Таким чином, кінцевий продукт на 100% відповідатиме потребам користувачів.

Як просуваються проекти MVP?

Дуже схожі на типовий Scrum, проекти MVP реалізуються в Sprints, кожні 2 тижні витрачаючи ще одне збільшення функціональності. Найчастіше вони встановлюються за моделлю Time & Material – лише за час і ресурси, які використовує команда проекту.

У будь-якому випадку, мінімально життєздатний продукт не повинен бути для тебе непосильною ціною. Як правило, це прибуткова інвестиція, яка швидко забезпечує окупність інвестицій.

І якщо тобі цікаво, чого очікувати від підходу MVP, ось короткий розподіл очікувань і обов’язків.

Розробка програмного забезпечення

ТИТВІЙ ПРОГРАМНИЙ ДІМ
Розкажи нам про потреби твого бізнесуВикористовує накопичені знання під час розвитку
Вислови свою думку щодо представленого проектуНадає макети системи
Очікуй на результати найближчим часомПрактично одразу починає працювати
Протестуй та затверджуй нову функціональністьВикористовує твої відгуки та виправляє помилки (за потреби)

Взаємодія в спринтах

ТИТВІЙ ПРОГРАМНИЙ ДІМ
Повідомити про відгукВін адаптує систему до того, що тобі потрібно
Використовуй «закріплені» компоненти системиВін продовжує працювати над новими функціями
Регулярно повідомляй про нові вимогиСлухає і робить висновки на майбутнє
Витрачай гроші з розумомСтворюй програмне забезпечення, стійке до змін
Отримай інструмент, який відповідає твоїм поточним потребамВін готовий реагувати відповідно до обставин, що змінилися

User adoption

ТИТВІЙ ПРОГРАМНИЙ ДІМ
Почни користуватися системою «в розробці»Налаштовує систему за потреби
Випробуй замовлені функції в діїНавчає користувачів поводженню
Визнай потенціал нового інструментуВін підтримує генерацію ідей щодо функціональності
Отримай підтримку HyperCareВідповідає на технічні питання

Як вибрати компоненти MVP?

MVP зазвичай є результатом матриці пріоритетів Ейзенхауера. Коли ти знаєш, що є терміновим і важливим, ти також знаєш, з чого почати свій проект.

Składowymi rozwiązania MVP powinny być funkcje, bez których nie możesz żyć i które są dość łatwe do osiągnięcia. Następne w kolejności są nadal ważne, ale nie tak palące. Warto zaplanować ich zamówienie na później. Funkcje „pilne i nieważne” są opcjonalne i prawdopodobnie powinny zostać pominięte. Zadań niepilnych i nieważnych w ogóle nie realizujmy. 😊

Inny sposób na priorytetyzację zagadnień do zrealizowania w projekcie MVP (i nie tylko), który Ci polecam to formuła RICE.

Weź pod uwagę:

  • Ilu użytkownikom ułatwisz życie? (Reach)
  • Jak bardzo je ułatwisz? (Impact)
  • Jak bardzo jesteś  przekonany/-a o zasadności danej funkcji? (Confidence)
  • Ile czasu i zasobów potrzebujesz na implementację? (Efforts)

Albo lepiej – zastanówmy się nad tym już wspólnie.

Mam na pokładzie analityków, którzy pomogą Ci opracować Backlog zagadnień do zrealizowania.

Zacznijmy od indywidualnej konsultacji. Poniżej zostawiam kalendarz do rezerwacji terminów.

Do usłyszenia!

Зареєструйся на консультацію з експертами по впровадженню eVolpe

Sławomir Wnuk
Прокрутити вгору