Prawdziwy harmonogram tworzenia aplikacji: od pomysłu do startu

Jeśli zapytają Państwo dziesięć agencji, ile trwa stworzenie aplikacji, otrzymają Państwo dziesięć pewnych siebie odpowiedzi i żadna z nich nie będzie prawdziwa. Uczciwa odpowiedź brzmi: nikt nie powie tego dokładnie pierwszego dnia — ale każdy, kto naprawdę wdrożył oprogramowanie, potrafi nakreślić jego kształt: jakie etapy istnieją, które po cichu pożerają kalendarz i gdzie własne decyzje przyspieszają wszystko albo zatrzymują w miejscu. Oto ten kształt, opisany wprost.

Widziałem wielu właścicieli małych firm wchodzących w projekt aplikacji z oczekiwaniem schludnego, liniowego marszu od szkicu do App Store. Zamiast tego dostają coś, co przypomina serię płaskowyżów i nagłych skoków. Tygodnie, w których wygląda, jakby nic się nie działo, a potem dzień, w którym wszystko nagle zaskakuje. Nic z tego nie jest oznaką, że coś jest nie tak. Po prostu tak powstaje oprogramowanie — a gdy potrafią Państwo nazwać etapy, cały proces przestaje przypominać czarną skrzynkę, w którą się płaci, licząc na najlepsze.

Ustalmy więc realistyczne oczekiwania. Dla skupionej pierwszej wersji aplikacji biznesowej — nie rozrastającej się platformy, lecz pierwszej wersji, która jedno zadanie wykonuje dobrze — zwykle mówimy o przedziale od trzech do pięciu miesięcy od poważnego startu do prawdziwego uruchomienia. To, w którym miejscu tego przedziału Państwo wylądują, mniej zależy od technologii, a bardziej od tego, jak jasno Państwo myślą, jak szybko podejmują decyzje i ile próbują upchnąć przed startem. Przejdźmy przez to po kolei.

Dlaczego szacunek, który Państwo dostali, jest zapewne błędny

Liczba sześciu tygodni nie jest dokładnie kłamstwem — to czas potrzebny na zbudowanie tej części, którą każdy potrafi sobie wyobrazić. Ekrany. Przyciski. To, co można zademonstrować. Co ta liczba po cichu pomija, to wszystko wokół widocznej aplikacji: decyzje, dane, integracje z narzędziami, których już Państwo używają, testowanie, weryfikacja w sklepie z aplikacjami i nieunikniona runda „a właściwie, czy to może też robić to?”

Przydatny sposób myślenia o tym: kodowanie rzadko bywa wąskim gardłem. Wąskim gardłem jest jasność. Każda godzina, w której deweloper czeka na decyzję — który operator płatności, co dzieje się, gdy rezerwacja zostaje anulowana, kto co może widzieć — to godzina, o którą przesuwa się harmonogram. Projekty, które kończą się szybko, to nie te z najlepszymi inżynierami. To te, w których właściciel odpowiada na pytania w dzień, a nie w dwa tygodnie.

Czytając więc poniższe etapy, proszę zwracać uwagę na momenty, w których piłka jest po Państwa stronie. To punkty, w których projekt albo utrzymuje rozpęd, albo po cichu staje na trzy tygodnie, bo e-mail pozostał bez odpowiedzi. Harmonogram to wspólna odpowiedzialność, a połowę po stronie klienta ludzie najczęściej niedoceniają.

Etap 1: Odkrywanie i określanie zakresu (1–3 tygodnie)

Zanim ktokolwiek zaprojektuje choć jeden ekran, jest etap, który nie wygląda na postęp, ale przesądza o wszystkim: ustalenie, co właściwie Państwo budują i, co ważniejsze, czego nie. Tu mglisty pomysł („aplikacja dla moich klientów”) staje się konkretną, możliwą do ukończenia listą funkcji dla wersji pierwszej.

Dobrze przeprowadzone odkrywanie to głównie rozmowa i trudne pytania. Kto z tego korzysta i na jakim urządzeniu? Co jest tą jedną rzeczą, którą aplikacja musi robić znakomicie? Co może poczekać do wersji drugiej? Dobry partner będzie tu Państwu zgłaszał zastrzeżenia, i tego właśnie należy chcieć — każda funkcja wycięta teraz to tygodnie, które Państwo odzyskują. Efektem jest zwykle krótki spisany zakres i wstępny szkic układu, coś, co można wziąć do ręki i powiedzieć tak, to jest to.

Etap 2: Projekt i prototyp (2–4 tygodnie)

Teraz aplikacja staje się czymś, co można zobaczyć i kliknąć, zanim choć linijka prawdziwego kodu zwiąże Państwa z czymkolwiek. Projektanci zamieniają szkic układu w prawdziwe ekrany — kolory, przepływ, faktyczne odczucie korzystania — zwykle jako interaktywny prototyp, przez który można klikać na własnym telefonie.

Ten etap jest na wagę złota z jednego powodu: zmiana projektu jest tania, zmiana zbudowanego oprogramowania jest droga. Przesunięcie przycisku w prototypie zajmuje pięć minut. Przesunięcie go po tym, jak funkcja została zakodowana, przetestowana i podpięta do Państwa danych, może zająć dzień. To więc moment, by być wymagającym, pokazać to kilku prawdziwym klientom lub pracownikom i wyłapać problemy w stylu „o, tego nikt nie zrozumie”, póki ich naprawa jest jeszcze bezbolesna.

Najczęstszym powodem przeciągania się tego etapu nie jest projektant — to niezdecydowanie po Państwa stronie. Niekończące się rundy drobnych poprawek albo trzy osoby z prawem weta, które nigdy się nie zgadzają. Proszę wcześnie ustalić, kto akceptuje, dawać informację zwrotną partiami, a nie po kropelce, a ten etap pozostanie zwarty.

Etap 3: Budowa (6–12 tygodni)

To część, którą wszyscy sobie wyobrażają, myśląc „tworzenie aplikacji”, i najdłuższy pojedynczy odcinek — ale rzadko najmniej przewidywalny, jeśli dwa pierwsze etapy zrobiono porządnie. Deweloperzy budują aplikację kawałkami, zwykle w krótkich cyklach, w których co tydzień lub dwa widzą Państwo działające fragmenty, zamiast znikać na trzy miesiące i wracać z gotowym produktem.

Ten rytm ma znaczenie. Chcą Państwo reagować na prawdziwe, działające oprogramowanie wcześnie, a nie na raport ze statusu. Gdy w czwartym tygodniu mogą Państwo faktycznie skorzystać z przepływu rezerwacji, zauważą rzeczy, których żadna specyfikacja nie była w stanie uchwycić — a naprawienie ich w czwartym tygodniu jest znacznie tańsze niż w dziesiątym. Dobry proces budowy czyni aplikację stale widoczną dla Państwa, nie dopiero na końcu.

Co po cichu wydłuża budowę

Dwie rzeczy rozciągają budowę bardziej niż cokolwiek innego. Pierwsza to integracje — każdy zewnętrzny system, z którym aplikacja musi się komunikować (operator płatności, istniejące narzędzie do rezerwacji, oprogramowanie księgowe, usługa dostawy), dokłada pracy, a każdy może przynieść własne niespodzianki. Druga to rozrost zakresu: stała kropla drobnych dodatków, z których każdy wydaje się malutki, ale razem przesuwają start o miesiąc. Oba da się opanować, ale tylko jeśli widać je nadchodzące.

• Każda zewnętrzna integracja dokłada dni, czasem tygodni — proszę uwzględnić je wprost w budżecie, nie zakładać, że są darmowe.
• „Tylko jedna mała funkcja więcej” to zdecydowanie najczęstsza przyczyna niedotrzymania daty startu.
• Prawdziwe dane są bardziej zagmatwane niż testowe; proszę zaplanować czas na przypadki brzegowe, które arkusz po cichu tolerował.
• Konta użytkowników, płatności i powiadomienia są zwodniczo głębokie — zawsze kosztują więcej, niż się wydaje.
• Akceptacje i treści, które są Państwo winni zespołowi (loga, teksty, treść prawna), potrafią zatrzymać budowę równie pewnie jak błąd.

Etap 4: Testowanie i poprawki (2–4 tygodnie)

Oto etap, o którego istnieniu ludzie zapominają, a potem mają mu za złe, gdy się pojawia. Gdy aplikacja jest już zbudowana, trzeba ją wystawić na próbę — na różnych telefonach, przy słabym internecie, przez osoby, które jej nie budowały i zrobią rzeczy, których nikt nie przewidział. Testowanie nie jest formalnością. To różnica między aplikacją, której klienci ufają, a taką, którą odinstalowują po pierwszej awarii.

Proszę spodziewać się, że wypłynie tu lista błędów i niedoróbek. To nie znak, że budowa poszła źle; to cały sens tego etapu. Niektóre to szybkie poprawki, niektóre ujawniają decyzję, którą trzeba przemyśleć na nowo. Zespoły, które radzą sobie z tym dobrze, traktują to jako normalną, zaplanowaną część pracy — nie sytuację awaryjną i nie coś do pominięcia, bo zbliża się start. Pominięcie testów nie oszczędza czasu. Przenosi tylko błędy z Państwa telefonu testowego na telefony klientów, gdzie ich naprawa kosztuje dziesięć razy więcej.

Etap 5: Start i oczekiwanie na sklep z aplikacjami (1–2 tygodnie plus weryfikacja)

Start to mniej pojedynczy moment, a bardziej staranne wdrożenie. Przy aplikacji webowej w pełni kontrolują Państwo termin — przełączają przełącznik, gdy są gotowi. Jeśli trafia do App Store firmy Apple lub Google Play, część harmonogramu przekazują Państwo im: ich proces weryfikacji może trwać od dnia do ponad tygodnia, a czasem odeślą aplikację z czymś do poprawienia. Warto wiedzieć to z wyprzedzeniem, by nie zaskoczyło daty startu obiecanej klientom.

Mądry sposób na start to nie wielkie odsłonięcie przed całą bazą klientów. To najpierw ciche wydanie dla małej grupy — garstki przychylnych klientów lub własnego personelu — by wyłapać problemy z prawdziwego świata, zanim zobaczą je wszyscy. Potem otwierają Państwo drzwi szerzej. Start, który wydaje się nudno bezbarwny, to start, który poszedł dobrze.

1. 1
   Cichy start dla małej grupy

   Proszę najpierw udostępnić garstce przychylnych użytkowników lub pracowników. Prawdziwe użycie znajduje to, co umknęło testom, przy całkowicie obniżonej stawce.
2. 2
   Proszę zgłosić wcześnie, jeśli idą Państwo do sklepów z aplikacjami

   Apple i Google kontrolują zegar weryfikacji, nie Państwo. Proszę zgłosić z zapasem, by powolna weryfikacja lub odrzucenie nie wysadziło obiecanej daty.
3. 3
   Proszę bacznie obserwować pierwszy tydzień

   Proszę mieć kogoś pod ręką, by szybko reagować. Pierwszy tydzień ujawnia przypadki brzegowe z prawdziwego świata, których nie pokaże żadne środowisko testowe.
4. 4
   Proszę zaplanować pracę na dzień po starcie, zanim wystartują

   Aplikacja nigdy nie jest 'skończona' w chwili startu. Proszę z wyprzedzeniem ustalić, kto zajmie się nieuniknionymi drobnymi poprawkami i pierwszą rundą informacji zwrotnej.

Składając cały harmonogram w całość

Ułożone jeden za drugim, te etapy dają realistyczny obraz. Żaden z nich nie jest egzotyczny; ludzie potykają się o to, że zapominają, iż te mniej efektowne — odkrywanie, testowanie, oczekiwanie na sklep — to realny czas w kalendarzu, a nie błędy zaokrąglenia. Oto z grubsza, jak skupiona pierwsza wersja zwykle rozkłada się na miesiące.

Proszę to zsumować, a zobaczą Państwo, dlaczego od trzech do pięciu miesięcy to uczciwy przedział dla prawdziwej pierwszej wersji i dlaczego ci, którzy obiecują sześć tygodni, po cichu na nowo definiują, co znaczy „aplikacja”. To nie pesymizm — to różnica między datą, którą faktycznie Państwo dotrzymają, a taką, za którą będą się tłumaczyć przez cały projekt.

Jak naprawdę to przyspieszyć (i jak nie)

Można działać szybciej, ale prawdziwe dźwignie to nie te, po które ludzie sięgają. Rzucenie większej liczby deweloperów na na wpół zdefiniowany projekt zwykle go spowalnia, a nie przyspiesza. Uczciwe przyspieszacze są mało efektowne: proszę zdecydować, co pominąć, szybko odpowiadać na pytania i oprzeć się pokusie dokładania rzeczy w trakcie budowy.

Najważniejsza z nich to bezwzględny zakres. Im mniejsza i jaśniejsza pierwsza wersja, tym wcześniej wystartuje — a uruchomiona aplikacja, która zarabia na siebie, nauczy Państwa w dwa tygodnie więcej niż kolejne dwa miesiące planowania. Zawsze można dodać. Nie da się odzyskać miesięcy spędzonych na budowie funkcji, których jak się okazało nikt nie chciał.

Jest pokrewna prawda warta powiedzenia na głos: nie wszystko w ogóle musi być aplikacją na zamówienie. Czasem prawdziwym problemem jest odcinek pracy ręcznej, którym mogłaby po cichu zająć się automatyzacja, bez żadnej aplikacji. Dobry partner powie Państwu, kiedy tak jest, zamiast sprzedawać większą budowę — bo najtańsza aplikacja to ta, której nie trzeba było robić.

Często zadawane pytania