Jak napisać specyfikację aplikacji mobilnej, żeby nie przepłacić

Większość przekroczeń budżetu w programowaniu wynika nie ze „złych programistów”, lecz z tego, że zamawiający i studio inaczej zrozumieli zadanie. Specyfikacja techniczna to jedyne narzędzie, które chroni przed tym obie strony. Opowiadamy, jak napisać specyfikację, która da dokładną wycenę i nie zamieni się w stustronicowy tom.

Po co specyfikacja, skoro „i tak wszystko jasne”

Zdanie „zróbcie jak Uber, tylko dla salonów fryzjerskich” wydaje się wyczerpujące, dopóki nie zacznie się liczyć: ile ról, jaka logika rezerwacji, co przy anulowaniu, jak przyjmować płatności, czy potrzebny czat. Każde z tych pytań to dni pracy. Bez specyfikacji studio albo wliczy ryzyko w cenę (przepłacisz), albo wyceni optymistycznie (przepłacisz później, na poprawkach).

Dobra specyfikacja spełnia trzy zadania: ustala zakres, stanowi podstawę wyceny i staje się kryterium odbioru — „gotowe” znaczy „zgodne ze specyfikacją”.

Struktura specyfikacji aplikacji mobilnej

1. Cele i kontekst

Dwa–trzy akapity: jaki biznes, jaki problem rozwiązuje aplikacja, kim są użytkownicy, jak zmierzysz sukces. Na przykład: „Aplikacja dla sieci 12 salonów kosmetycznych. Cel — przenieść 60 % rezerwacji z telefonu do online w pół roku i zmniejszyć liczbę nieobecności dzięki przypomnieniom”.

To nie formalność. Rozumiejąc cel, zespół proponuje rozwiązania, o których nie pomyślałeś, i odradza funkcje, które celowi nie służą.

2. Role użytkowników

Wymień wszystkich, którzy będą korzystać z aplikacji, i co każdy może robić. Klient, fryzjer, administrator salonu, właściciel sieci — cztery role, cztery zestawy ekranów i uprawnień. To właśnie liczba ról najczęściej podwaja budżet, więc lepiej zobaczyć to przed startem.

3. Scenariusze użytkownika

Najważniejsza część. Opisz, jak każda rola realizuje swoje zadania, krok po kroku:

Klient otwiera aplikację → wybiera salon na mapie lub z listy → wybiera usługę → widzi wolnych fryzjerów i terminy → potwierdza rezerwację → dostaje push 2 godziny przed wizytą → po wizycie może ocenić fryzjera.

Nie zapominaj o „nieszczęśliwych” ścieżkach: co się dzieje przy anulowaniu na godzinę przed wizytą, gdy fryzjer zachoruje, gdy płatność nie przejdzie. To one kryją połowę złożoności.

4. Lista ekranów i funkcji

Na podstawie scenariuszy zestaw listę ekranów z krótkim opisem elementów na każdym. Nie trzeba rysować — wystarczy tekst: „Ekran rezerwacji: kalendarz na 30 dni, sloty po 30 minut, zajęte sloty szare, przycisk »Zarezerwuj« aktywny dopiero po wyborze godziny”.

Warto podzielić funkcje na trzy grupy: niezbędne na start, pożądane i „kiedyś”. To pozwoli studiu zaproponować wariant MVP w ramach budżetu.

5. Integracje

Wymień wszystkie systemy zewnętrzne: bramka płatnicza (która dokładnie), CRM, dostawca SMS, mapy, logowanie przez social media, księgowość, analityka. Przy każdym — czy jest dostęp do API i dokumentacja. Integracja z systemem bez porządnego API może kosztować więcej niż połowa aplikacji.

6. Panel administracyjny

Często się o nim zapomina, a to osobny produkt. Kto i co będzie konfigurować: usługi i ceny, grafiki pracowników, treści, kampanie push, raporty. Im dokładniej — tym precyzyjniejsza wycena.

7. Wymagania niefunkcjonalne

• Platformy: iOS i Android? Od jakiej minimalnej wersji?
• Języki: jeden czy kilka.
• Obciążenie: ilu użytkowników spodziewasz się w pierwszym roku.
• Tryb offline: potrzebny czy nie.
• Bezpieczeństwo i dane: czy przechowywane są dane osobowe, medyczne lub płatnicze; wymagania RODO i prawa lokalnego.
• Design: czy jest księga marki, referencje aplikacji, które się podobają.

8. Ograniczenia i oczekiwania

Widełki budżetu, pożądany termin startu, kto po stronie zamawiającego podejmuje decyzje i jak szybko. Podanie budżetu nie oznacza „przepłacenia”: pozwala studiu od razu zaproponować zakres, który się w nim mieści, zamiast wyceniać „wszystko naraz”.

Typowe błędy

1. Specyfikacja w jednym zdaniu. „Potrzebujemy aplikacji do dostawy jedzenia” to nie specyfikacja, lecz temat rozmowy.
2. Specyfikacja na 150 stron przed pierwszą konsultacją. Połowa zdezaktualizuje się po rozmowie z zespołem. Lepiej 5–10 stron według powyższej struktury, a szczegóły — razem z analitykiem.
3. Opisywanie rozwiązań zamiast zadań. „Zrobić przycisk niebieski i po lewej” zamiast „użytkownik ma trafić do koszyka jednym dotknięciem”. Pozwól zespołowi decydować jak; Twoja strefa to co i po co.
4. Zapomniane „nudne” części: autoryzacja, odzyskiwanie hasła, powiadomienia, obsługa błędów, panel administracyjny. To do 30 % pracy.
5. Brak priorytetów. Gdy wszystko jest „obowiązkowe”, budżet rośnie, a start się odsuwa.

Co zrobić, gdy nie ma czasu pisać specyfikacji

To normalne: specyfikacja to praca analityka, nie zamawiającego. Wystarczy przygotować punkty 1, 2 i 8 z powyższej struktury oraz listę referencji. Resztę — scenariusze, ekrany, integracje — robimy razem na etapie analizy: to pierwszy krok każdego projektu w naszym studiu, a jego wynik staje się podstawą wyceny i umowy.

Chcesz, żebyśmy pomogli sformułować zadanie? Zostaw zgłoszenie — na bezpłatnej konsultacji przeanalizujemy pomysł i powiemy, co trzeba doprecyzować przed startem.