Ile trwa stworzenie MVP? Realne terminy według typu produktu

Złożoność najlepiej przewiduje termin MVP. Przy wycenie projektów używamy trzech poziomów.

Te same poziomy wyznaczają budżet. Nasze zestawienie tego, ile kosztuje SaaS MVP, podaje przedział cen dla każdego z nich.

Typy produktów dość przewidywalnie trafiają na te poziomy. Tabela pokazuje, gdzie zwykle lądują popularne MVP; twój produkt może przesunąć się o poziom w górę albo w dół w zależności od szczegółów.

Mini App w Telegramie zwykle mieści się na poziomie prostym albo średnim. Otwiera się wewnątrz Telegramu, więc nie trzeba jej publikować w sklepie, a konto użytkownika pochodzi z samego Telegramu.

Każde MVP przechodzi przez te same etapy, choć zachodzą one na siebie bardziej, niż sugeruje prosta lista.

• Wycena. Twój brief zamienia się w ofertę z zakresem, terminem i ceną. W Sakura większość ofert wychodzi w ciągu 2–3 dni roboczych od kompletnego briefu.
• Projektowanie. Najpierw ścieżki użytkownika, potem ekrany z systemu komponentów wielokrotnego użytku, potem klikalny prototyp.
• Programowanie. Frontend, backend i integracje, a co tydzień działająca wersja, którą możesz przeklikać.
• Testy. Każda ścieżka w uzgodnionych przeglądarkach i na urządzeniach, do tego wydajność i podstawowa dostępność.
• Premiera. Wdrożenie, analityka, publikacja w sklepie, jeśli jest aplikacja mobilna, i pierwsze poprawki po przyjściu prawdziwych użytkowników.

Projektowanie i programowanie celowo zachodzą na siebie. Gdy pierwsze ścieżki są zatwierdzone, programowanie zaczyna się od nich, a pozostałe są jeszcze projektowane.

Projektowanie zwykle zaczyna się wcześniej i kończy przed programowaniem, ale oba etapy nie powinny iść ściśle jeden po drugim. Gdy projektant oddaje gotowy plik i znika, w trakcie programowania często okazuje się, że niektóre ekrany są drogie w realizacji, a tygodnie idą na poprawki.

Rozwiązanie polega na projektowaniu w tych samych komponentach, które zbudują programiści. Wtedy zatwierdzony ekran jest już prawie gotowy, a pytania rozstrzyga się, póki to tanie.

Na przykład AutoIntel, narzędzie B2B dla niemieckiego rynku używanych aut, zaczęło się od projektu produktu i interaktywnego prototypu na przykładowych ogłoszeniach. Klient przeprowadził swój zespół przez prototyp i ustalił, które pola i filtry są ważne, zanim wyceniono zbieranie danych. Taka kolejność utrzymuje najdroższą część budowy przy tym, czego interfejs naprawdę potrzebuje.

Planujesz datę premiery? Wyślij nam krótki brief, a powiemy, na który poziom trafia twój produkt i jaki termin jest realny.

Niektóre funkcje wyglądają w briefie na drobne, a w realizacji dokładają tygodnie. Uważaj na te:

• Integracje. Płatności, usługi logowania, CRM i zewnętrzne API: każda wymaga konfiguracji, obsługi błędów i testów.
• Role i uprawnienia. Każda kolejna rola mnoży stany, które musi obsłużyć każdy ekran.
• Natywna aplikacja mobilna. To drugi frontend i weryfikacja w sklepie. Apple w ramach App Review sprawdza co najmniej 50% zgłoszeń w mniej niż 24 godziny i 90% w mniej niż 48 godzin, ale odrzucenie uruchamia zegar od nowa.
• Kilka języków. Każdy tekst, komunikat o błędzie i podpowiedź muszą istnieć w każdym języku, a układ musi zmieścić najdłuższą wersję.
• Spóźnione treści. Teksty, ceny, dokumenty prawne i prawdziwe dane, które przychodzą w ostatnim tygodniu, blokują testy.
• Wolne decyzje. Pytanie, które tydzień czeka na odpowiedź, opóźnia wszystko, co powstaje na jego podstawie.

Termin MVP skraca się, robiąc mniej, a nie gorzej. Najwięcej czasu oszczędzają te decyzje:

• Tnij całe ścieżki, a nie dopracowanie. Przesuń poboczne ścieżki do późniejszego wydania, zamiast budować każdą do połowy.
• Startuj najpierw w wersji webowej. Responsywna aplikacja webowa dociera do użytkowników na telefonie i komputerze i omija weryfikację w sklepach.
• Korzystaj ze sprawdzonych usług. Hostowana strona płatności, istniejące usługi logowania i wysyłki e-maili są szybsze i bezpieczniejsze niż własne wersje.
• Decyduj szybko. Wyznacz jedną osobę, która zatwierdza projekty i odpowiada na pytania w ciągu dnia.
• Testuj wcześnie na kilku użytkownikach. Z badań Jakoba Nielsena wynika, że testy z 5 użytkownikami ujawniają większość problemów z użytecznością, więc kilka małych rund jest lepszych niż jedna duża.

CarPixly, studio zdjęć z AI dla ogłoszeń samochodowych, wydało wersję na Androida jako APK na własnej stronie pobierania, gdy wersja na iOS była jeszcze w drodze. Start tam, gdzie się da, i dodawanie platform później to często najszybsza droga do prawdziwych użytkowników.

Pierwsze tygodnie idą szybciej, gdy kilka rzeczy jest gotowych przed startem prac. Żadna z nich nie wymaga wiedzy technicznej:

• Krótka lista kluczowych ścieżek. Od jednego do trzech zadań, które użytkownicy muszą móc wykonać na starcie, opisanych prostymi słowami.
• Jedna osoba decyzyjna. Ktoś, kto zatwierdza projekty i odpowiada na pytania w ciągu dnia.
• Dostęp do istniejących kont. Domena, hosting, analityka, operator płatności i wszystkie API, z których już korzystasz.
• Prawdziwe treści albo data ich dostarczenia. Teksty, ceny, strony prawne i przykładowe dane, które pokaże produkt.
• Twoje ograniczenie związane z premierą. Wydarzenie, spotkanie z inwestorami albo sezon, przez które data jest ważna.

Z tym w ręku wycena trwa dni zamiast tygodni, a projektowanie może zacząć się od prawdziwych treści zamiast wypełniaczy.

Terminy rzadko przesuwają się dlatego, że programiści wolno piszą. Przesuwają się przez decyzje podjęte albo niepodjęte wokół budowy:

• Zakres rośnie w trakcie projektu bez spisanej procedury zmian.
• Rundy uwag trwają tydzień zamiast dnia.
• Nikt nie zapisał, co znaczy „gotowe”, więc ostatnie tygodnie zamieniają się w spór.
• Integracje zaplanowano jedną linijką w zakresie zamiast z prawdziwymi przypadkami brzegowymi.

Stały zakres z procedurą zmian trzyma większość z tego pod kontrolą. Wyjaśniamy to w tekście stała cena czy stawka godzinowa.

Premiera uruchamia drugi zegar, a nie zatrzymuje pierwszego. Pierwsze tygodnie po wydaniu są zwykle najbardziej pracowite w całym projekcie.

Prawdziwi użytkownicy znajdują błędy, których nie wychwyciły testy, proszą o drobne zmiany i korzystają z produktu tak, jak nikt nie planował. Zaplanuj zaraz po premierze krótki okres poprawek i szybkich ulepszeń, zanim pojawią się nowe funkcje.

Potem praca przechodzi w stały rytm: miesięczny plan ulepszeń oparty na tym, co pokazuje prawdziwe użytkowanie. Każdy projekt Sakura obejmuje określony okres gwarancyjny na poprawki błędów, a dalsza praca może iść w ramach planu miesięcznego albo przejść do twojego zespołu.

Tak krótko, jak się da, o ile wciąż testuje twoje główne założenie. Sens MVP, według słów Lean Startup, to „zacząć się uczyć tak szybko, jak to możliwe”.

Jeśli twój plan wyraźnie wykracza poza poziom złożony, zastanów się, czego chcesz się dowiedzieć i czy mniejszy produkt nie nauczyłby cię tego samego. Często jedna ścieżka uruchomiona wcześniej odpowiada na najważniejsze pytanie.

Kiedy zechcesz zaplanować swoje MVP, opowiedz nam o produkcie. Dostaniesz ofertę z zakresem, terminem i stałą ceną, a co tydzień wersję, na której zobaczysz, jak produkt powstaje.