Masz pomysł na własne narzędzie?

Kolejny artykuł z serii o aplikacjach dedykowanych. Dzisiaj odpowiedmy sobie na pytanie MVP czy od razu pełna aplikacja – od czego zacząć? Odpowiedź jest krótka: niezależnie od tego co planujesz zrobić – MVP wygrywa zawsze (prawie). Dlaczego? Szybciej dostajesz produkt, z którego możesz od razu korzystać i dopracowywać go w trakcie implementacji.

Dlaczego nie zaczynać od pełnej aplikacji?

W pierwszym akapicie trochę skłamałem. To nie prawda, że MVP zawsze wygrywa. Są małe dedykowane aplikacje, do których MVP nie da się zrobić. Taka sama sytuacja jest gdy mamy bardzo dokładnie rozpisane założenia, których nie da się zmienić. Jednak w większości przypadków wystartowanie najpierw z MVP, a następnie z pełną aplikacją ma sens.

Załóżmy, że mamy do zrobienia dedykowany CRM z budowanym sklepem – nasz ulubiony przykład chyba każdego artykułu. Tym razem założmy, że czas jego zrobienia to 12 miesięcy, bo ma jakieś skomplikowane raporty.

Długo czekasz na pierwsze efekty

Gdy robimy od razu pełną aplikację dedykowaną to sytuacja wygląda tak, że ta aplikacja nie będzie oddana do użytku wcześniej niż w połowie czasu tworzenia, bo trzeba dokładnie przygotować architekturę, skonfigurować środowisko. Podczas tworzenia aplikacji programista robi od początku do końca całe moduły w tym 15 raportów, z których 10 jest używanych kwartalnie lub raz do roku.

Założenia mogą okazać się błędne

W wypadku dużych i skomplikowanych projektów czekanie na oddany projekt to przepis na sporą ilość poprawek. Oddawanie aplikacji dedykowanej kawałkami daje większą elastyczność i szybszą możliwosć reakcji. Czasem się zdaża, że na papierze wszystko wygląda idealnie, ale w praktyce jest tak, że: „no tutaj mamy pole od wariantów w produkcie, ale zawsze wpisujemy to w uwagach do zamówienia, bo lepiej widać”. Przez co handlowcy dostali aplikację z opcjami, z których nie korzystają, a jak wiemy – im prostsza aplikacja tym lepiej dla wszystkich.

Trudności w reagowaniu na zmiany

Trudności w reagowaniu na zmiany są powiązane z błędnymi założeniami. Jednak jeśli projekt jest prowadzony w metodologi waterfall – czyli takiej, że jedno musi być skończone, aby zacząć drugie to rodzi się problem z reagowaniem na zmiany. Jeśli rozmawiamy o małym projekcie to taki problem nie istnieje. Jednak trzymajmy się tego naszego rocznego projektu CRM. W takim wypadku jeśli taki CRM jest połączony przez API z innymi aplikacjami, to może okaza się na koniec pracy, że pierwszy etap wymaga całkowitego przebudowania, bo zmieniło się API.

Ryzyko budowania zbędnych funkcjonalności

O tym wspomniałem już przy okazji tego, że założenia mogą okazać się błędne. Jeśli dostaniemy bardzo duży moduł – dajmy raportów. Tych raportów niech będzie z 20. Finalnie wyjdzie, że dla nas interesujące raporty to: dzienna sprzedaż oraz ilość otwartych ofert na handlowca – czyli dwie sztuki, które na 100% weszły by w MVP, bo to są dwa podstawowe raporty.

W takim wypadku wychodzi, że mamy 18 szuk zbędnych raportów. Trzeba pamiętać raporty nie są najszybszym tematem do wdrożenia z tego powodu, że operują na bardzo dużej ilości danych i trzeba przy nich bardziej uważać na wydajność podczas ich tworzenia.

Informacja zwrotna pojawia się za późno

Według mnie jest kilka powodów. Od takich bardziej psychologicznych po techniczno-organizacyjne. Zajmiemy się najpierw aspektem psychologicznym. Załóżmy, że tworzymymy aplikacje przez 12 miesięcy. Mamy dokładnie rozpisane wszystkie funkcjonalności naszej aplikacji dedykowanej i programiści to wdrażają. Pierwszy miesiąc dostajesz idealnie przygotowaną architekturę aplikacji, ale nie jesteś w stanie nic wyklikać. Następny miesiąc dostajesz pełną obsługę użytkowników – no ok możesz się zalogować, zarejestrować i koniec. Aplikacja nadal jest bezużyteczna. W kolejnym miesiącu dostajesz dopiero jakiś moduł przykładowo produktów. Jednak na samej bazie produktowej też nie popracujesz. Mijają trzy miesiące – pracy wykonane dużo, ale niekoniecznie jest ona praktyczna. Frustracja i niecierpliwość trochę rośnie, chociaż jeszcze dużo czasu do końca.

Mija już ten rok pracy. Dostajesz w końcu gotową aplikację (oczywiście, pomijamy błędy młodości), ale wyszło, że ogólnie super, ale niektóre procesy rozeszły się i w aplikacji jest inaczej przygotowane niż faktycznie pracujecie. Trzeba poprawiać. Czas się wydłuża. Chociaż czasu nie ma co brać pod uwagę, w tym wypadku.

Dlaczego warto zacząć od MVP aplikacji dedykowanej?

Analogicznie do poprzednich akapitów. Skoro wtedy długo czekaliśmy na pierwsze efekty, to tutaj mamy je od razu. Dostajemy aplikację z minimalną działającą wersją.

Szybciej dostajesz działający produkt

Tutaj nie chodzi o to, że dostaniesz taką samą aplikację szybciej niż z pominięciem MVP. Ostatecznie czas wykonania aplikacji dedykowanej z stworzeniem najpierw jej MVP trwa dłużej. Jednak trzeba mieć na uwadze, że rozwój takiej aplikacji wygląda całkiem inaczej. Ty jako klienta dostajesz taką podstawę założeń jakie potzrebujesz i od razu zaczynasz pracować na tej aplikacji. Nie spełnia ona wszystkich wymagań, ale już działa i łatwia pracę.

Możesz zweryfikować założenia

Kolejną zaletą oprócz szybszego dostarczenia aplikacji dedykowanej jest możliwość zweryfikowania założeń w praktyce. Jak w wypadku pełnej aplikacji trzeba wszystkie założenia bardzo dokładnie spisać i przeanalizować, tworzyć dokładne ścieżki użytkownika, tak w w tym wypadku można trochę odpuścić.

Tworzymy najpierw zarys aplikacji. Korzystasz z niej, a następnie mówisz co się sprawdziło, a co nie. My dostosowujemy etap prac pod Twoje zgłoszenia i przerabiamy/poprawiamy lub naprawiamy to co uznałeś, że nieskuteczne. Finalnie dostajesz aplikację dedykowaną, która spełnia wszystkie Twoje założenia.

Łatwiej ustalić piorytety

W wypadku ustaleń piorytetów fajnie jest wrócić do tematu raportów. Jak wspominałem przy akapicie o ryzyku budowania zbędnych funkcjonalności o dwóch raportach to możemy ten przykład rozbudować o kolejny raport – kwartalny. Dajmy, że dajesz premie kwartalne za odpowiednie doprowadzenie wyników przez handlowców.

Zbliża się właśnie takie podsumowanie kwartalne – w związku z czym przy zwinnym podejściu do programowania można nadać wyższy piorytet właśnie temu raportowi. Aplikacja nadal się rozwija dostarczając odpowiednie „klocki” względem aktualnych potrzeb.

Rozwijasz aplikację na podstawie danych

Wracając do przykładu wariantu i uwag przy zamówieniu. Jeśli użytkownicy pracują na aplikacji to od samego początku zbieramy dane. Dane, które możemy wykorzystać do dalszej pracy. W jaki sposób? Tworząc ścieżki użytkownika własnie na podstawie tego co ten użytkownik faktycznie mówi.

Jeśli taki handlowiec zgłosi nam, że brakuje przycisku „wygeneruj ofertę” przy danym kontekcie, który automatycznie przepisze kilka danych to jest bardzo wartościową informacją, którą należy wykorzystać. W wypadku oddawania aplikacji całymi modułami/etapami taki handlowiec dostałby ten przycisk dopiero na samym końcu gdy wszystkie inne zaplanowane prace zostałyby wykonane.

Zalety MVP w porównaniu do pełnej aplikacji