Ile trwa zbudowanie aplikacji. Harmonogram tydzień po tygodniu, z miejscami, gdzie projekty stają

„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

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ą

1. 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.
2. 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.
3. 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.

Jeśli chcesz zobaczyć, jak ten harmonogram wygląda przy konkretnym zakresie, opisałem to na stronach aplikacji mobilnych i oprogramowania na zamówienie.

Krótko

• Pierwsza klikalna wersja po dniach, gotowy produkt po tygodniach lub miesiącach.
• MVP 3–6 tygodni, aplikacja z płatnościami 2–3 miesiące, system B2B 2–4 miesiące.
• Weryfikacja w sklepach: Google do 3 dni, Apple do tygodnia.
• Projekty stają przez brak decyzji, brak dostępów i nieuporządkowane dane.
• Jedna osoba decyzyjna po stronie firmy skraca projekt bardziej niż większy budżet.