Proces dochodzenia do wersji MVP
Kiedy MVP może się nie sprawdzić?
MVP jak… układanie z klocków
Weryfikacja produktu przygotowanego w modelu MVP
Cieszymy się?
Diabeł tkwi w… analizie wymiernych danych
Proces dochodzenia do wersji MVP
Proces ten przebiega analogicznie do prac nad pełną wersją produktu. Etap tworzenia poszczególnych komponentów, testy czy wdrożenie praktycznie nie różnią się w obu tych podejściach. Dla nas, takim momentem szczególnej uwagi, jest etap przygotowywania specyfikacji. Właściwie wskazane, kluczowe elementy opracowywanego produktu są priorytetowe dla powodzenia procesu. Na wszystkich kolejnych etapach prace mogą pójść dzięki temu sprawnie, a klient niebawem zacznie korzystać ze „startowej” wersji oczekiwanego oprogramowania.
Kiedy MVP może się nie sprawdzić?
Z pewnością oprogramowanie dla administracji publicznej nie powstaje w takim modelu. Trudno też zakładać, że taki model sprawdzi się w oprogramowaniu medycznym. Generalnie, nie bierze się pod uwagę modelu MVP w projektach, które od startu wymagają potężnego zakresu funkcjonalności, współpracujących ze sobą w określonych scenariuszach. Wszędzie tam stosuje się raczej takie metodologie jak np. waterfall, gdzie wszystkie etapy muszą następować po sobie w określonej logice, a towarzyszyć temu procesowi musi restrykcyjnie tworzona dokumentacja. W środowisku osób zarządzających projektami utarło się takie humorystyczne porównanie, mówiące, że nie da się metodą MVP wybudować podwodnego tunelu. To sytuacja, która nie przewiduje uczenia się na ewentualnych niedoskonałościach wstępnego produktu.
MVP jak… układanie z klocków
Możemy wyobrazić sobie również firmę z branży magazynowo – logistycznej. Firma ta decyduje się na wdrożenie rozwiązania obejmującego wszystkie sfery działalności. Teoretycznie moglibyśmy rozważać model MVP. W pierwszej kolejności byłby wtedy uruchomiony moduł magazynowy, potem sprzedaż, potem dostawy do klientów. Mielibyśmy jednak do czynienia z bardzo niekorzystnym dla klienta stanem przejściowym. Użytkownicy musieliby niejako funkcjonować w dwóch środowiskach IT. W wyjątkowych sytuacjach takie podejście może mieć sens. Co do zasady jednak przeniesienie w jednym momencie całej firmy (wszystkich oprogramowywanych procesów) do nowego systemu jest efektywniejsze niż próba składania tej nowej rzeczywistości z kolejnych klocków.
MVP to rozwiązanie stworzone z myślą o wdrażaniu nowych pomysłów, kiedy nawet pomysłodawca nie jest jeszcze pewien co do ostatecznego kształtu swojego pomysłu. Właśnie dlatego metodę tę tak bardzo upodobały sobie wszelkiego rodzaju start-up’y.
O tym, czym w teorii i praktyce jest MVP przeczytasz tutaj >>>
Weryfikacja produktu przygotowanego w modelu MVP
Kiedy aplikacja staje się dostępna dla użytkowników najważniejszy jest proces zbierania i analizowania informacji płynących z feedbacku, jaki otrzymuje właściciel oprogramowania. Niezależnie od tego, czy to użytkownik wewnętrzny (najczęściej pracownicy firmy), czy to użytkownik, który pobrał aplikację z Internetu następuje etap weryfikacji. Musimy wspólnie z klientem odpowiedzieć sobie na pytanie, czy wskazana na początku funkcjonalność w ogóle spełnia przyjęte założenia biznesowe.
Cieszymy się?
Jeśli pierwsze wnioski są pozytywne to oczywiście w sposób naturalny przechodzimy do tworzenia planu rozwoju produktu. Jeśli jednak pierwsze analizy nie są satysfakcjonujące, zadaniem dostawcy oprogramowania jest ustalenie, co jest przyczyną. Problem może leżeć w wewnętrznych analizach zleceniodawcy.
Klient musi mieć świadomość, że jego rola w tym procesie jest nie do przecenienia. Agencja realizująca zlecenie, nigdy nie odnajdzie się w rzeczywistości biznesowej klienta tak dobrze, jak on sam. Jeśli podejrzewamy, że źródło problemu tkwi w przyjętych przez klienta założeniach możliwości zidentyfikowania tego źródła przez agencję, zawsze będą ograniczone. Nie znaczy to oczywiście, że nie włączymy się w proces analizy i zdefiniowania przyczyny – przez cały okres współpracy staramy się jak zrozumieć realia biznesowe, dla których tworzymy oprogramowanie. Wszystko po to, by klient miał zawsze pewność, że agencja na tyle poznała procesy podlegające informatyzacji, by w porę wychwycić i zareagować np. na zapętlenia funkcjonalne wynikające z błędnych założeń.
Jednym z naszych priorytetów jest zbudowanie takiego modelu współpracy, w którym trzymamy piecze nad tym, aby wizje nie rozwinęły się nadmiernie, co mogłoby skomplikować niepotrzebnie ekosystem powstającej aplikacji, jednocześnie nie dając żadnej wymiernej, biznesowej korzyści.
Diabeł tkwi w… analizie wymiernych danych
Z naszego punktu widzenia optymalna, bo najbardziej wymierna, jest weryfikacja na podstawie danych. Jeśli faktycznie dostrzegamy duży problem w funkcjonowaniu aplikacji, a klient nie dostrzega źródła problemu w przyjętych założeniach wdrażamy mechanizmy, które analizują zachowania użytkowników oprogramowania. Możemy również stworzyć grupę testową, której zachowania będziemy – w oparciu o przyjęte dla nich scenariusze – obserwować i analizować.
