Zalety podejścia MVP. Poznaj żargon, którym mówią firmy IT

Sławomir Wnuk

Zupełnie mnie nie zdziwi, jeżeli skrót MVP kojarzy Ci się przede wszystkim ze światem sportu. Do niedawna sam łączyłem go tylko i wyłącznie z turniejami, na koniec których wybiera się Most Valuable Player.

W finale Ligi Mistrzów, podczas którego siatkarze Grupy Azoty ZAKSA Kędzierzyn-Koźle pokonali Itas Trentino 3:0, taki tytuł otrzymał Kamil Semeniuk.

Natomiast MVP w nomenklaturze IT oznacza coś zupełnie innego…

Przekonaj się, czym jest i jakie korzyści oferuje podejście Minimum Viable Product.

Co to jest Minimum Viable Product?

MVP, czyli Minimum Viable Product to wersja systemu IT z wystarczającą liczbą funkcji, aby można z niej aktywnie korzystać.

MVP musi spełniać podstawowe założenia funkcjonalnej aplikacji i być „używalny”. Powinien też rozwiązywać podstawowy problem, z którym boryka się Twoja organizacja, czyli beneficjent oprogramowania.

Główną zaletą tego podejścia jest możliwość przetestowania rozwiązania przy znacznie niższej początkowej inwestycji.

Poprawnie skonstruowany Minimum Viable Product objaśnia następująca ilustracja:

Kiedy Twoim celem jest skuteczny przewóz towarów, nie zrealizujesz go przy użyciu jednego koła czy roweru. Użyteczne MVP to dopiero wózek silnikowy z opcją załadunku.

Z czasem, gdy potwierdzisz rentowność biznesu i pozyskasz nowe środki, będzie Cię stać na zakup furgonetki.

To samo podejście da się zastosować także w przypadku oprogramowania.

Czy wiesz, że…

MVP nawiązuje do zasady Pareto, która mówi, że 80% potrzeb użytkowników zaspokaja 20% funkcjonalności systemu.

Zamiast czekać na gotowy produkt, możesz zacząć czerpać korzyści z aplikacji w budowie. I sterować jej rozwojem na podstawie bieżącego feedbacku.

Jak się toczą projekty typu MVP?

Bardzo podobnie do tego, co proponuje metodyka Scrum, projekty MVP realizuje się w Sprintach, co 2 tygodnie wydając kolejny przyrost funkcjonalności.

Najczęściej rozlicza się je też w modelu Time & Material – wyłącznie za czas i zasoby wykorzystane przez zespół projektowy.

Realizacja MVP nie powinna być przytłaczającym kosztem. Co do zasady chodzi o opłacalną inwestycję, która szybko napędza zwrot z inwestycji (ROI).

Oczekiwania vs obowiązki w projektach MVP

Software development

KLIENTFIRMA WDROŻENIOWA/SOFTWARE HOUSE
Opowiedz o potrzebach Twojego biznesuPodczas dewelopmentu korzysta z User Stories
Zaopiniuj przedstawiony projektDostarcza mock-upy systemu
Oczekuj wyników co 2 tygodniePracuje w Sprintach
Przetestuj i zatwierdź nową funkcjonalnośćKorzysta z Twojego feedbacku i naprawia błędy (jeśli to konieczne)

Współpraca w Sprintach

KLIENTFIRMA WDROŻENIOWA/SOFTWARE HOUSE
Zgłaszaj feedbackDostosowuje system do tego, co jest Ci potrzebne
Wykorzystuj gotowe elementy systemuNie przestaje pracować nad kolejnymi funkcjami
Zgłaszaj nowe wymagania na bieżącoSłucha i wyciąga wnioski na przyszłość
Adaptuj się do zmian na rynkuTworzy oprogramowanie odporne na zmiany
Zyskaj narzędzie, które odpowiada na aktualne potrzebyJest gotowy reagować zgodnie ze zmienionymi okolicznościami

User adoption

KLIENTFIRMA WDROŻENIOWA/SOFTWARE HOUSE
Zacznij korzystać z systemu „w budowie”Konfiguruje i rozbudowuje system według potrzeb
Wypróbuj zamówione funkcje w akcjiSzkoli użytkowników z obsługi
Rozpoznaj potencjał nowego narzędziaWspiera generowanie pomysłów na funkcjonalność
Uzyskaj wsparcie techniczneOdpowiada na pytania i świadczy usługi konsultingowe

Jak dobrać elementy składowe MVP?

MVP jest zwykle wynikiem macierzy priorytetów Eisenhowera.

Kiedy wiesz, co jest pilne i ważne, wiesz też, od czego zacząć swój projekt.

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 pilne jak te pierwsze. 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.

Umów konsultację z ekspertem wdrożeniowym eVolpe

Wybierz dogodny dla siebie termin.

Sławomir Wnuk
Scroll to Top