To, o co czytelnicy dopytują najczęściej po lekturze.
Czy da się zbudować aplikację szybciej za większe pieniądze?
Częściowo i tylko do pewnej granicy. Można kupić gotowe elementy zamiast pisać je od zera i skrócić projekt o tygodnie. Nie da się natomiast skrócić czasu weryfikacji w sklepach ani czasu potrzebnego na decyzje po Twojej stronie.
Praktyczna granica przy jednoosobowym wykonawcy to około 20–30% skrócenia. Poniżej tego jakość zaczyna spadać w sposób, który wraca później jako poprawki.
Ile mojego czasu zajmie taki projekt?
Około 1–2 godzin tygodniowo: przegląd nowej wersji, odpowiedzi na pytania o proces i decyzje o priorytetach. Najwięcej na starcie, przy ustalaniu zakresu, potem coraz mniej.
Jeśli nie masz tych dwóch godzin, projekt się wydłuży — nie z powodu tempa pracy, tylko dlatego, że będzie czekał na Twoje decyzje.
Kiedy mogę zacząć realnie z tego korzystać?
Zwykle znacznie wcześniej niż w dniu formalnego odbioru. Pierwszy przepływ, na przykład same rezerwacje albo same zlecenia, bywa gotowy do pracy po 3–4 tygodniach i można go wdrożyć w firmie, podczas gdy reszta powstaje.
Taki układ polecam najczęściej: zespół uczy się narzędzia stopniowo, a Ty widzisz zwrot z inwestycji, zanim projekt się skończy.
„Kilka tygodni" to odpowiedź, po której nie da się nic zaplanować. Poniżej realny harmonogram: co dzieje się w którym tygodniu, ile trwa weryfikacja w sklepach i w których trzech miejscach projekty najczęściej stają.
Terminy w skrócie
Zakres
Pierwsza klikalna wersja
Gotowe do użytku
MVP (jeden przepływ)
3–5 dni
3–6 tygodni
Aplikacja z płatnościami
1 tydzień
2–3 miesiące
System B2B z integracjami
1–2 tygodnie
2–4 miesiące
Rozwiązanie pod klucz
2 tygodnie
3–5 miesięcy
Do aplikacji mobilnych dochodzi weryfikacja w sklepach. Google zwykle mieści się w trzech dniach, Apple w tygodniu. Pierwsza publikacja bywa dłuższa niż kolejne, bo sklepy sprawdzają wtedy całe konto, nie tylko aplikację.
Harmonogram tydzień po tygodniu
Tydzień 0: rozmowa i zakres
Nie zaczynam od projektowania ekranów, tylko od procesu. Pytam, kto co robi, w jakiej kolejności, gdzie dane są przepisywane ręcznie i co się psuje najczęściej. Efektem jest lista funkcji podzielona na „bez tego nie zadziała" i „to może poczekać".
Ten podział jest najważniejszą decyzją całego projektu. Wszystko, co wpadnie do pierwszej grupy niesłusznie, przesuwa termin i podnosi cenę.
Tydzień 1: pierwsza klikalna wersja
Po kilku dniach dostajesz coś, co da się otworzyć i kliknąć. Nie jest to makieta w Figmie, tylko działający szkielet z prawdziwymi ekranami. Zwykle to moment, w którym pada połowa wcześniejszych ustaleń — i dobrze, bo zmiana tutaj jest darmowa.
Tygodnie 2–4: rdzeń
Powstaje główny przepływ: rezerwacja, zlecenie albo protokół. Testujesz go na własnych danych, nie na przykładowych. Co tydzień dostajesz wersję do sprawdzenia.
Tygodnie 4–8: integracje i płatności
Tu harmonogram zaczyna zależeć od rzeczy poza moim wpływem: cudzych API, terminów weryfikacji u operatora płatności i dostępu do systemów, które już masz. Zakładam zapas, bo bez niego każdy taki projekt spóźnia się o dwa tygodnie.
Ostatnie 1–2 tygodnie: dane, testy, publikacja
Migracja danych z arkuszy, testy na urządzeniach, materiały do sklepów i wysyłka do weryfikacji. Równolegle szkolenie zespołu — zwykle godzina, bo jeśli trzeba więcej, coś jest źle zaprojektowane.
Trzy miejsca, w których projekty stają
Brak decyzji po stronie firmy. Najczęstszy powód opóźnień i jedyny, którego wykonawca nie rozwiąże. Jeśli na pytanie „co ma się stać, gdy klient odwoła wizytę na godzinę przed" nikt nie umie odpowiedzieć, praca staje. Ustal jedną osobę decyzyjną po swojej stronie, zanim projekt ruszy.
Dostęp do systemów. Klucz API do programu księgowego potrafi być wąskim gardłem na dwa tygodnie, bo trzeba przejść przez dostawcę i jego procedury. Zamawiaj dostępy w tygodniu zerowym, nie wtedy, gdy będą potrzebne.
Dane w złym stanie. „Mamy wszystko w Excelu" oznacza czasem trzy pliki z różnymi nazwami kolumn i duplikatami. Uporządkowanie zajmuje kilka dni, których nikt nie planował. Warto na starcie pokazać wykonawcy prawdziwy plik, nie opis pliku.
Co realnie przyspiesza projekt
Jedna osoba decyzyjna. Nie komitet. Komitet uzgadnia stanowisko dłużej, niż trwa zbudowanie funkcji.
Zgoda na etapy. Wdrożenie jednego przepływu i rozbudowa później jest szybsze i tańsze niż start z pełnym zakresem.
Prawdziwe dane od pierwszego dnia. Testowanie na przykładowych danych zawsze kończy się niespodzianką przy migracji.
Wcześnie zamówione dostępy. Konta w sklepach, klucze API, dane operatora płatności.
