10 rzeczy, o które musisz zadbać przy robieniu MVP

Pracujecie nad projektem software’owym i zastanawiacie się, jak wprowadzić go na rynek? Jedną ze strategii może być MVP (Minimum Viable Product). Przeczytajcie, jak wykorzystać tę technikę, by na końcu powstał poważny produkt. Sprawdźcie, na co zwrócić szczególną uwagę i co naprawdę działa. Dowiedzcie się, jak robimy to u nas w VMgen.

Czym jest MVP

Minimum Viable Product (MVP) to technika polegająca na wprowadzeniu na rynek nowego produktu z podstawowymi funkcjonalnościami, zebraniu feedbacku od użytkowników i na jego podstawie przygotowanie ostatecznej wersji zgodnej, zgodnej z potrzebami klientów. Idealnymi przykładami wprowadzenia tej metody w życie są m.in. Dropbox, Groupon czy Zappos.

Aby ten mechanizm zadziałał, powinniśmy spełnić 3 podstawowe warunki:

• bazowa wersja produktu musi być atrakcyjna dla klientów na tyle, by chcieli ją kupić,
• użytkownicy muszą mieć możliwość podzielenia się swoją opinią o produkcie i propozycjami zmian/poprawek — musimy zadbać, by ta funkcja była dobrze wyeksponowana i intuicyjna w “obsłudze”,
• przygotujmy klientom “marchewkę”, by chcieli się dzielić swoimi oczekiwaniami i pomogli nam w pracach nad finalną wersją. Jako przykład polecamy Google, który załatwił temat bezpłatną aktualizacją do ostatecznej wersji.

Skoro teorię mamy za sobą, przejdźmy do praktyki, czyli jak naprawdę to wygląda przy wdrażaniu większych projektów. 

MVP w praktyce

W teorii MVP powinno powstać tak szybko, jak to tylko możliwe. Na tym etapie przetestowanie produktu w akcji jest o wiele ważniejsze niż jego jakość, dlatego wiele osób postuluje, by po wypuszczeniu pierwszej wersji lepiej zrozumieć potrzeby klientów i praktycznie od zera napisać kolejną wersję. Natomiast w praktyce się to nie dzieje. 

Wszystko oczywiście zależy od projektu, jego założeń początkowych oraz praktycznych rozwiązań oczekiwanych przez klientów docelowych, jednak wszystko wskazuje na to, że kod MVP przetrwa o wiele dłużej, niż się to na początku zakłada. Zwykle MVP staje się rdzeniem, wokół którego powstają kolejne funkcje. To czasochłonny proces, dlatego należy dobrze planować swoją pracę. Niektóre fragmenty kodu z założenia będą wielokrotnie zmieniane, dlatego nie warto dopieszczać tych fragmentów kodu, by np. był przyjazny dla oka.

Jak wdrażamy produkty MVP?

Postanowiliśmy zebrać wiedzę i ją dla Was uporządkować. Poniżej zebraliśmy najważniejsze z naszego punktu widzenia obszary, na których skupiamy się, tworząc projekty oparte o MVP.

Architektura

Dla większości aplikacji na starcie wystarczający będzie monolit, bo taka architektura zapewnia najszybszą pracę na początek. Ważne jest jednak, aby przemyśleć, jak wydzielić poszczególne komponenty aplikacji, by później łatwiej było z nich stworzyć samodzielny serwis, jeżeli zajdzie taka potrzeba. Od początku myślimy tak o aplikacjach, dzięki czemu jesteśmy otwarci na wszelkie zmiany. Tu podejściem, które dobrze nam się sprawdza, jest architektura heksagonalna.

Jakość kodu

MVP bardzo łatwo może stać się rdzeniem później rozwijanego produktu, ważna jest dla nas jakość kodu. Stosowanie dobrych praktyk, takich jak SOLID, zwróci się z nawiązką, szczególnie że ułatwia późniejsze implementowanie zmian.

Testy

Automatyczne testy oszczędzają mnóstwo czasu programistom. Szybka weryfikacja czy aplikacja działa, czy też nie, jest bardzo pomocna w czasie developmentu. Sztuką jest tu napisanie odpowiednich testów. Na etapie MVP nie ma sensu dążyć do 100% pokrycia, bo wiele elementów mocno się zmieni. Muszą być jednak na tyle solidne, by potwierdzić, że aplikacja zachowuje się prawidłowo.

Automatyzacja procesów (CI/CD)

Jeśli macie taką możliwość, zautomatyzujcie działania, które pozwolą oszczędzić czas. Ponownie trzeba do tematu podejść zdroworozsądkowo w oparciu o doświadczenie teamu. Docelowo unikajcie sytuacji, gdy wdrożenie automatyzacji zajmie więcej czasu, niż napisanie kodu “odręcznie”. Mimo wszystko stworzenie pipeline’u, który uruchomi testy, zbuduje projekt i wyśle go na serwer testowy, jest tu bardzo rozsądne.

Dobór narzędzi/technologii do projektu

Wybierajcie te rozwiązania, które są sprawdzone i działają. Oczywiście nie oznacza to pracy na przestarzałych wersjach, tylko używaniu tych, których jesteście pewni. Jak w każdym aspekcie, należy oszacować potencjalne ryzyko i zasadność używania danego rozwiązania. W wielu naszych projektach nie widzieliśmy np. sensu korzystania z Kubernetesa, ponieważ sam w sobie również wymaga zarządzania. Wymagał wręcz większego zaangażowania, niż przyniósłby potencjalnych korzyści. Podobnie byłoby z resztą z używaniem całkiem obcych dla nas języków czy frameworków.

Rozplanowanie projektu

Jak doskonale wiemy, plany mogą być genialne, ale nie wypalą bez dokładnego rozpisania działań w czasie. W projektach MVP nie jest inaczej, dlatego musimy oszacować nasze moce przerobowe, dostępne zasoby, ubrać to w ramy czasowe i zostawić margines na nieprzewidziane sytuacje. Od pierwszego dnia wprowadzamy narzędzia, które pomogą nam spisać backlog, rozplanować sprinty i zapanować nad ramami czasowymi. W planowaniu powinniście kierować się doświadczeniem zespołu, zdrowym rozsądkiem i dopasowaniem zarówno do zespołu projektowego, jak i biznesu.

Dobrze rozpisana dokumentacja

Rozpisanie procesów pozwoli dołączyć nowym członkom teamu do pracy niezależnie od etapu rozwoju projektu. My unikamy pisania elaboratów w stylu krok 1. to x, krok 2. xy itd. Warto natomiast stworzyć kilka diagramów opisujących architekturę. Do całej reszty najlepiej sprawdzi się dokumentacja w formie kodu, wyłączająca z komunikacji czynnik ludzki. Dzięki temu unikamy drobnych nieporozumień w interpretacji i każdy może zrozumieć założenia projektu. Polecamy też np. kolekcje w Postmanie, które dla nas są źródłem prawdy ułatwiającej development.

Solidnie zrobione podstawowe funkcje

Praktycznie każda aplikacja ma pewne funkcje, które są takie same jak wszędzie i użytkownik spodziewa się, że będą działać bez zarzutu. Tu przykładem może być rejestracja i logowanie, które muszą pójść gładko. Inny przykład to proces kupowania i płacenia — tu wszystko musi się przeliczyć dobrze, w przeciwnym razie możemy bardzo zniechęcić użytkownika do aplikacji.

Doświadczenie zespołu

To chyba najważniejszy czynnik, który dotyczy zarówno PM-a, jak i developerów. Zespół musi umieć się ze sobą komunikować, a także wspólnie wybierać priorytety działań istotnych dla danego projektu. Warto, by PM miał zaplecze techniczne (niekoniecznie developerskie), by rozumiał jakie rozwiązania proponuje zespół i jednocześnie potrafił oszacować, czy przedstawione argumenty to ściema.

Deweloperzy również powinni potrafić określić, które fragmenty kodu są najbardziej krytyczne, a które będą się często zmieniać. To pozwoli wybrać odpowiednie kryteria dla podejścia, jakości kodu czy testów określonych części systemu. Pozwoli też na uniknięcie zbędnych automatyzacji i niepotrzebnego over-engineeringu.

Określenie ważnych aspektów istotnych z punktu widzenia klienta

W modelu MVP pierwsza wersja produktu trafia do sprzedaży, dlatego klient musi być z niego zadowolony. Dbamy, by miał intuicyjny i przejrzysty interfejs, minimum te funkcje, które były w zapowiedziach oraz cenę nie wyższą, niż założyliśmy wcześniej. W skrócie — musi otrzymać minimum to, za co zapłacił i nie miał poczucia nabicia w butelkę. Wręcz zależy nam, by miał poczucie inwestowania w przyszłościowy produkt, dzięki czemu chętniej podzieli się swoimi wrażeniami.

Potencjalne ryzyka i jak się ich ustrzec

Mówiliśmy o koncentracji na jakości i dowiezieniu rozwiązania, które jest gotowe na wdrożenie na produkcji. Niestety często ludzie techniczni omijają w tym wszystkim krytyczną część, czyli “dowiezienie”. Zamiast tego skupiają się na mniej istotnych szczegółach:

• Mylna interpretacja słowa “jakość kodu”. Może przełożyć się na marnotrawstwo czasu na nieistotne testy lub dopieszczanie szczegółów kodu, które nie mają wpływu na działanie całego produktu (“over-engineering”). 
• Eksperymentowanie z nowymi technologiami lub takimi, które nie są istotne dla produktu, ale wymagają dużych nakładów, jeżeli chodzi o utrzymanie. O tym wspominaliśmy przy okazji technologii. 
• Doszukiwanie się wzorców projektowych, często w miejscach, gdzie nie występują — ponownie kosztem cennego czasu i energii. W przypadku MVP często warto napisać kod najprościej, jak się da, ale za to solidnie.

Świetnym lekarstwem na tego rodzaju przypadłości jest doświadczenie zespołu. Doświadczenie pomaga odróżnić to, co jest potrzebne, od tego, co by było fajne. Niezależnie od doświadczenia, każda osoba zaangażowana w MVP potrzebuje osadzenia w rzeczywistości, którą nakreśla na początku projektu PM.

Dlaczego powstał ten artykuł?

Chcieliśmy podzielić się z Wami naszymi rozwiązaniami, które mogą pomóc Wam w prowadzeniu projektów IT, w tym w modelu MVP. Nasza platforma Cloud Computing umożliwia wdrażanie wydajnych maszyn wirtualnych, zmniejszając koszty globalnej infrastruktury brzegowej dla Waszych projektów IT. Więcej o nas znajdziesz na naszej stronie https://vmgen.pl/. Nasza aplikacja internetowa (VMgen) powstała w modelu MVP.

Daj znać w komentarzu, czy podobały Ci się nasze wskazówki. Czekamy na Twoją opinię ?