Jak stworzyć aplikację dla firmy — sześć etapów i co w każdym robi zamawiający

„Jak stworzyć aplikację” wpisują dwie różne osoby. Pierwsza chce zrobić ją sama — często za darmo, w kreatorze, w weekend. Druga ma firmę, proces, który przestał się mieścić w arkuszu, i zamierza zlecić budowę wykonawcy. Obie dostają w wyszukiwarce te same wyniki, a potrzebują zupełnie innych odpowiedzi.

Jeśli jesteście w pierwszej grupie, uczciwa odpowiedź jest krótka. Proste narzędzie wewnętrzne — formularz, lista zgłoszeń, prosty panel — zbudujecie dziś na platformie low-code lub no-code bez pisania kodu. Działa to dobrze, dopóki mieścicie się w regułach platformy: jej bazie danych, jej ekranach i jej cenniku za użytkownika. Gdzie ta granica przebiega, opisujemy w tekście low code i no code — co to jest i kiedy wystarczy.

Reszta tego tekstu jest dla drugiej grupy. Pokazuje, jak przebiega projekt aplikacji z wykonawcą, i jedną rzecz, której zwykle nikt nie mówi wprost: aplikacji się nie „robi”, tylko rozstrzyga ją w kolejności — najpierw co ma się wydarzyć, potem jak to ma wyglądać, dopiero na końcu kod. Każdy etap sprawia, że zmiana decyzji z poprzedniego kosztuje więcej. Zamawiający decyduje w trzech momentach: przy briefie, przy prototypie i przy odbiorze. Tam warto być obecnym, a nie przy każdym spotkaniu.

Zanim zadzwonicie: brief na jednej stronie

Najczęstsze zacięcie na starcie to przekonanie, że przed rozmową z wykonawcą trzeba przygotować dokumentację — specyfikację funkcjonalną na kilkadziesiąt stron, makiety, wybór technologii. Nie trzeba. Wystarczy pięć rubryk. Poniżej przykładowy brief aplikacji do obsługi zgłoszeń serwisowych, w całości:

Tyle. Ten brief mieści się na jednej stronie i wystarcza, żeby dostać sensowną wycenę — bo mówi, co ma się wydarzyć, a nie jak to zbudować. Rozstrzyganie architektury przed rozmową z wykonawcą to zwykle rozstrzyganie jej dwa razy.

User stories — jak zapisać funkcje, żeby wykonawca je zrozumiał

Rubrykę „funkcje” najłatwiej wypełnić w formie, której używa większość zespołów programistycznych: user story, czyli jedno zdanie z trzema częściami — kto, co chce zrobić i po co. „Jako klient chcę zgłosić usterkę ze zdjęciem, żeby serwisant wiedział, z czym przyjechać.” „Jako kierownik chcę widzieć zgłoszenia bez przypisanego serwisanta, żeby nic nie czekało dłużej niż dzień.”

Ta forma ma dwie zalety, które docenicie przy wycenie. Po pierwsze, zmusza do nazwania użytkownika — a różne role oznaczają różne ekrany i uprawnienia, czyli różny koszt. Po drugie, część „po co” pozwala wykonawcy zaproponować prostsze rozwiązanie tego samego problemu. Trzy do pięciu takich zdań na każdą rolę wystarczą na pierwszą rozmowę.

Jeśli chcecie sprawdzić, czy jesteście gotowi do tej rozmowy, poniższa lista zbiera wszystko, o co wykonawca i tak zapyta.

Czego nie potrzebujecie przed startem

Nie potrzebujecie gotowego projektu graficznego — wystarczy logo i kolory, jeśli je macie, a jeśli nie, pierwsza wersja może powstać bez nich. Nie potrzebujecie wiedzy o technologiach: wybór języka, bazy danych i hostingu to zadanie wykonawcy, a Waszym jest sprawdzić, czy umie go uzasadnić. Nie potrzebujecie też szczegółowej specyfikacji — powstaje w pierwszym etapie projektu, razem z wykonawcą. Więcej o tym, co dobry brief zawiera, a czego nie, piszemy w tekście o briefie strony internetowej — przy aplikacji zasady są te same.

Etap 1 — analiza i warsztat

Pierwszy etap projektu to rozmowa o Waszej firmie, nie o funkcjach. Wykonawca chce zrozumieć, jak dziś wygląda praca, kto będzie korzystał z aplikacji, gdzie giną informacje i które czynności są ręczne i powtarzalne. Najczęściej odbywa się to w formie warsztatu — jednego lub kilku spotkań, na których układa się procesy, role użytkowników i mapę funkcji.

Z dobrze przeprowadzonej analizy wychodzą konkretne rzeczy, które możecie sprawdzić:

• opis funkcji — rozwinięte user stories z briefu, z kryteriami, po których poznacie, że funkcja działa;
• lista ról użytkowników i tego, co każda rola może zobaczyć i zmienić;
• zarys głównego ekranu i najważniejszych ścieżek;
• zakres pierwszej wersji — co wchodzi na start, a co świadomie odkładamy. Jak ten zakres wyciąć, opisujemy w tekście o MVP;
• estymacja czasu i kosztu tego zakresu.

To jest pierwszy z trzech momentów, w których decydujecie Wy. Jeśli coś w opisie funkcji się nie zgadza z tym, jak pracuje Wasza firma, to jest ostatnia chwila, kiedy poprawka kosztuje rozmowę, a nie przeprojektowanie.

Etap 2 — projekt aplikacji: makieta i prototyp

Wielu zamawiających słyszy „projektowanie” i myśli o kolorach. Projekt aplikacji zaczyna się jednak od logiki: jakie są ekrany, co na nich jest i jak użytkownik przechodzi z jednego do drugiego. Wygląd przychodzi na końcu.

W tym etapie padają trzy słowa, które warto rozróżniać, bo za każdym stoi inny koszt:

• makieta (wireframe) to szkielet ekranu — prostokąty zamiast zdjęć, bez kolorów. Służy do ustalenia, co i gdzie się znajduje;
• prototyp aplikacji to klikalna wersja makiet: możecie przejść przez najważniejsze ścieżki, zanim powstanie linijka kodu;
• projekt graficzny (UI) to ostateczny wygląd — kolory, typografia, przyciski — nałożony na sprawdzoną strukturę.

Szerzej o tych trzech pojęciach piszemy w tekście o wireframe'ach, makietach i prototypach, a o różnicy między UX i UI — w tekście UX i UI.

Prototyp to drugi moment, w którym decydujecie Wy, i najtańszy w całym projekcie na zmianę zdania. Pokażcie go osobom, które będą z aplikacji korzystać — nie tylko zarządowi. Szukajcie w nim trzech rzeczy, bo to one najczęściej psują aplikacje, które technicznie działają poprawnie:

• formularze proszące o za dużo na raz. Każde pole, którego nie potrzebujecie na starcie, to powód, żeby ktoś nie dokończył. Resztę danych można zebrać później;
• komunikaty błędów, które nic nie mówią. „Coś poszło nie tak” nie pomaga; „wpisz adres e-mail w formacie nazwa@firma.pl” — tak;
• nawigacja zbudowana według struktury firmy, a nie zadań użytkownika. Jeśli najczęściej używana funkcja jest schowana w trzecim menu, znajdzie ją tylko ten, kto ją projektował.

Co odbieracie po etapie projektu

Projekt aplikacji internetowej to nie jeden plik z obrazkami. Po tym etapie powinniście dostać trzy rzeczy, które możecie sprawdzić: mapę ekranów, czyli listę wszystkich widoków i przejść między nimi; klikalny prototyp najważniejszych ścieżek; oraz zestaw komponentów — przycisków, pól, tabel i komunikatów — z których zbudowane są wszystkie ekrany. Ten ostatni punkt brzmi technicznie, ale ma prosty skutek: kiedy za pół roku dojdzie nowa funkcja, zostanie złożona z gotowych elementów, zamiast być projektowana od zera. Jeśli po etapie projektu dostajecie wyłącznie kilka ładnych ekranów głównych, zapytajcie o resztę, zanim zacznie się programowanie.

Etap 3 — programowanie w sprintach

Po zatwierdzeniu projektu zaczyna się programowanie, i tu jest pierwszy mit do zbicia: że przez kilka miesięcy „coś się dzieje”, a gotowy produkt zobaczycie dopiero na końcu. W dobrze prowadzonym projekcie pracuje się w sprintach — odcinkach po jeden do dwóch tygodni — i po każdym z nich widać działający fragment aplikacji.

Bez żargonu programowanie składa się z trzech warstw. Frontend to to, co widzi użytkownik: ekrany i interakcje z prototypu. Backend to logika i dane: kto może co zrobić, gdzie zapisują się zgłoszenia, co dzieje się po kliknięciu. Integracje łączą aplikację z systemami, których już używacie — i każda z nich to osobna pozycja w harmonogramie, o czym niżej.

Działające fragmenty ogląda się w środowisku testowym (staging), czyli kopii aplikacji, która nie dotyka prawdziwych danych. Poproście wykonawcę o dostęp do niego od pierwszego sprintu. To jedyny sposób, żeby wychwycić nieporozumienie po dwóch tygodniach, a nie po dwóch miesiącach.

Na koniec każdego sprintu zespół pokazuje, co zbudował. To krótkie spotkanie jest dla Was ważniejsze niż cotygodniowe raporty, bo pokazuje działający kod, a nie opis postępów. Przyjdźcie na nie z jednym pytaniem: czy to, co widzimy, zgadza się z user stories z pierwszego etapu. Jeśli nie — to jest moment, kiedy poprawka kosztuje jeden sprint. Zmiany zakresu zgłaszajcie właśnie tam, a nie w mailu w środku sprintu: dobrze prowadzony zespół dopisze je do listy zadań na kolejny odcinek i powie, co w zamian przesunie.

Etap 4 — testy akceptacyjne (UAT)

Testy funkcjonalne — czy każda funkcja działa zgodnie z opisem — to praca wykonawcy. Testy akceptacyjne, w skrócie UAT (od user acceptance testing), to praca zamawiającego. Słownik ISTQB, standard terminologii testerskiej, definiuje je jako „poziom testów zorientowany na ustalenie, czy zaakceptować system” (ISTQB Glossary). Pytanie nie brzmi więc „czy są błędy”, tylko „czy to jest to, co zamówiliśmy”.

UAT to trzeci moment, w którym decydujecie Wy, i jedyny, którego nie da się oddelegować wykonawcy. Kilka zasad, które go ułatwiają:

• kryteria odbioru spiszcie wcześniej — najlepiej już przy user stories w etapie analizy. „Klient widzi status zgłoszenia w ciągu minuty od jego zmiany” da się sprawdzić; „ma działać sprawnie” — nie;
• testują ci, którzy będą używać. Nie trzeba wielu osób — trzy, cztery z każdej roli wystarczą, jeśli przejdą przez prawdziwe scenariusze swojej pracy;
• testujcie na urządzeniach, na których aplikacja będzie działać, w warunkach, w których będzie działać — w terenie, na magazynie, na słabym zasięgu;
• rozdzielcie błędy od życzeń. Rzecz niezgodna z opisem to błąd do poprawienia w ramach projektu; nowy pomysł to pozycja na drugą wersję.

Etap 5 — wdrożenie

Wdrożenie to przeniesienie aplikacji ze środowiska testowego na produkcyjne, czyli to, na którym pracują prawdziwi użytkownicy na prawdziwych danych. Technicznie obejmuje konfigurację serwera, domeny i certyfikatu, kopii zapasowych i monitoringu — to zadanie wykonawcy. Trzy rzeczy wymagają jednak Waszej decyzji:

• plan wycofania. Zapytajcie, co się stanie, jeśli po uruchomieniu coś pójdzie źle, i jak szybko da się wrócić do poprzedniego stanu. Dobra odpowiedź jest konkretna;
• dokumenty prawne. Jeśli aplikacja przetwarza dane osobowe, polityka prywatności i regulamin muszą być gotowe w dniu startu;
• komunikat do użytkowników. Aplikacja, o której nikt nie wie, nie będzie używana. Krótka informacja — dlaczego powstała, co zmienia i od kiedy — oraz osoba, do której można się zgłosić w pierwszych dniach, to często więcej niż jakakolwiek funkcja.

Jeśli aplikacja ma trafić do App Store lub Google Play, dochodzi jeszcze publikacja w sklepach — z kontami deweloperskimi, testami i przeglądem każdej wersji. To osobny temat, opisany w tekście o tworzeniu aplikacji mobilnych.

Etap 6 — rozwój i utrzymanie

Uruchomienie nie kończy projektu. Po pierwszych tygodniach pojawiają się potrzeby, których nikt nie przewidział, zmieniają się systemy, z którymi aplikacja jest zintegrowana, a przeglądarki i telefony dostają nowe wersje. Aplikacja wymaga stałej opieki — poprawek, aktualizacji i monitoringu — i to jest koszt stały, nie jednorazowy.

Nie podajemy tu procentu wartości projektu, który „trzeba przeznaczyć na utrzymanie”, bo krążące liczby nie mają źródła pierwotnego. Z czego składa się rachunek po uruchomieniu i co da się w nim wycenić z góry, rozpisujemy w tekście ile kosztuje stworzenie aplikacji.

Ile trwa stworzenie aplikacji

Na to pytanie nie ma jednej odpowiedzi rynkowej, więc pokażemy naszą. Poniżej reguły, według których nasz kreator briefu szacuje czas projektu. To są założenia planistyczne naszych projektów, nie pomiar rynku — ale pokazują proporcje, które w rozmowach o terminach umykają najczęściej.

Czas bazowy to 12 do 24 tygodni dla portalu lub platformy webowej i 16 do 32 tygodnie dla aplikacji typu SaaS. Rozpiętość nie wynika z niepewności, tylko z zakresu: ta sama etykieta obejmuje panel dla dwudziestu pracowników i produkt dla tysięcy klientów.

Ważniejszy od sumy jest podział. Programowanie to w naszych założeniach 40% czasu projektu — mniej niż połowa. UX i projekt graficzny razem to 35%, testy kolejne 15%. Kto planuje harmonogram tak, jakby aplikacja była głównie kodem, zwykle oszczędza na etapach, które decydują o tym, czy ktoś będzie jej używał.

Przełożone na tygodnie wygląda to tak. W portalu, który zajmuje 16 tygodni, na UX przypada nieco ponad 3 tygodnie, na projekt graficzny — 2,4, na programowanie — 6,4, na treści i wdrożenie — po niecałym tygodniu, a na testy — 2,4 tygodnia. Jeśli harmonogram od wykonawcy przewiduje na testy kilka dni na końcu projektu, to nie jest oszczędność, tylko przesunięcie tych tygodni na czas po uruchomieniu, kiedy błędy znajdują użytkownicy.

Do czasu bazowego dochodzą elementy, które go wydłużają. W naszych regułach strefa klienta z logowaniem to dodatkowe 2 do 4 tygodni, integracja z CRM — 1 do 3, integracja z ERP — 2 do 5, API dla aplikacji mobilnej — 3 do 6. Każdą z tych pozycji warto zobaczyć osobno w harmonogramie, który dostaniecie od wykonawcy. Jeśli chcecie przeliczyć swój zakres, kalkulator kosztu aplikacji webowej pokazuje różnicę między pierwszą wersją a pełnym produktem, a raport kosztów aplikacji webowych — mediany rynkowe, do których warto wynik przyłożyć.

Jak wybrać software house

Portfolio pokazuje, co wykonawca zbudował. Nie pokazuje, jak będzie wyglądała współpraca z Wami przez kilka miesięcy — a to ona decyduje, czy projekt dowiezie to, co zamówiliście. Pięć pytań, które sprawdzają proces, a nie prezentację:

1. Kto po Waszej stronie prowadzi projekt i jak często zobaczymy działający fragment? Dobra odpowiedź to konkretna osoba i rytm sprintów, nie „będziemy w kontakcie”.
2. Czy od początku dostaniemy dostęp do środowiska testowego? Jeśli nie, pierwszy raz zobaczycie aplikację przy odbiorze.
3. Jak spisujecie kryteria odbioru? Wykonawca, który pyta o nie w etapie analizy, myśli o UAT od pierwszego dnia.
4. Kto jest właścicielem kodu, repozytorium i kont? Hosting, domena, konta w sklepach z aplikacjami — to wszystko powinno być Wasze albo przekazywane Wam na piśmie.
5. Co dzieje się po wdrożeniu? Kto naprawia błędy, w jakim czasie i na jakich warunkach — to warto mieć w umowie, zanim będzie potrzebne.

Pełną listę kontrolną do porównania kilku wykonawców znajdziecie w checkliście wyboru agencji.