Jak przygotować specyfikację aplikacji, zanim zamówisz ją w software house

Wysyłasz to samo zapytanie do trzech wykonawców i dostajesz wyceny różniące się kilkukrotnie. Nikt nie chce Cię oszukać. Każdy po prostu inaczej zrozumiał, co ma zbudować. Dobra specyfikacja aplikacji dla software house nie musi być stustronicowym dokumentem technicznym. Ma opisać problem, użytkowników i oczekiwany efekt na tyle jasno, żeby wykonawcy wyceniali to samo, a Ty mógł potem sprawdzić, czy dostałeś to, co zamówiłeś. Poniżej osiem kroków przygotowania takiego dokumentu.

Krok 1. Opisz problem, nie rozwiązanie

Zacznij od tego, co dziś nie działa i ile to kosztuje. Zdanie „Handlowcy w terenie nie widzą stanów magazynowych i obiecują klientom towar, którego nie ma” mówi wykonawcy więcej niż „potrzebujemy aplikacji mobilnej z modułem stanów”. Z opisu problemu wykonawca może wyprowadzić rozwiązanie, o którym nie pomyślałeś, czasem prostsze i tańsze.

Dopisz cel biznesowy w mierzalnej formie, np. krótszy czas obsługi, mniej pomyłek albo więcej klientów obsłużonych przez ten sam zespół. Na tej podstawie ocenisz później projekt, tak jak opisujemy w tekście o wskaźnikach sukcesu automatyzacji.

Krok 2. Wypisz użytkowników i ich zadania

Kto będzie korzystał z aplikacji? Dla każdej grupy określ, co chce zrobić i jak często. Na przykład:

• handlowiec kilka razy dziennie sprawdza stan towaru i cenę dla klienta, a raz dziennie wysyła zamówienie,
• kierownik sprzedaży raz w tygodniu przegląda zamówienia zespołu i realizację planu,
• magazynier dostaje zamówienia do kompletacji, ale z aplikacji mobilnej nie korzysta.

Z takiej listy od razu widać, gdzie jest główny ciężar pracy i które funkcje są potrzebne, a które „byłoby miło mieć”.

Krok 3. Opisz scenariusze krok po kroku

Wymagania najlepiej zapisać jako scenariusze użycia: „Handlowiec otwiera kartę klienta, widzi jego ceny i ostatnie zamówienia, dodaje pozycje, aplikacja pokazuje dostępność, handlowiec wysyła zamówienie, które trafia do ERP jako dokument do akceptacji”. Każdy scenariusz prowadzi od początku do końca i obejmuje wyjątki: brak internetu, brak towaru, klienta z przekroczonym limitem kredytowym.

Ekranów nie musisz rysować. Jeśli jednak masz szkic na kartce albo zrzut ekranu z aplikacji, która Ci się podoba, dołącz go. Oszczędza to wiele godzin rozmów.

Krok 4. Wskaż systemy, z którymi aplikacja ma współpracować

Integracje najczęściej rozsadzają wyceny. Wypisz wszystkie systemy, z którymi aplikacja ma wymieniać dane: ERP, sklep internetowy, system kurierski, poczta, Microsoft 365. Przy każdym zaznacz, jakie dane mają płynąć, w którą stronę i jak często. Podaj nazwę i wersję systemu oraz to, czy ma API. Jeśli te pojęcia są dla Ciebie nowe, przeczytaj podstawy integracji przez API dla managera.

Krok 5. Określ wymagania pozafunkcjonalne

Nie opisują one funkcji, ale mocno wpływają na koszt i architekturę. Ustal:

• liczbę użytkowników dziś i za kilka lat,
• urządzenia: przeglądarka, telefony z Androidem lub iOS, tablety, kolektory danych,
• czy aplikacja ma działać bez internetu i w jakim zakresie,
• zasady bezpieczeństwa i ochrony danych osobowych: logowanie, uprawnienia, miejsce przechowywania danych, wymagania RODO,
• hosting: chmura, Twój serwer albo bez znaczenia,
• dostępność, czyli w jakich godzinach system musi działać i jak szybko trzeba usunąć awarię.

Krok 6. Ustal priorytety

Podziel wymagania na niezbędne do startu, ważne w kolejnym etapie i opcjonalne. Wykonawca wyceni wtedy pierwszą wersję osobno, a Ty szybciej dostaniesz coś, co działa. Pierwsza wersja z samymi niezbędnymi funkcjami sprawdzi założenia na prawdziwych użytkownikach, zanim wydasz budżet na resztę.

Krok 7. Dopisz warunki formalne

W specyfikacji możesz od razu zasygnalizować oczekiwania co do umowy: prawa autorskie do kodu, dostęp do repozytorium, dokumentacja, okres gwarancji, sposób odbioru, model rozliczenia (stała cena za etap albo czas i materiały). Co zapisać w umowie na okres po uruchomieniu, piszemy w artykule o utrzymaniu i rozwoju oprogramowania po wdrożeniu.

Krok 8. Dołącz prawdziwe przykłady

Przykładowe dokumenty i dane zapobiegają większej liczbie nieporozumień niż jakikolwiek opis. Jeśli aplikacja ma generować protokół, dołącz obecny wzór. Jeśli ma importować zamówienia, dołącz kilka prawdziwych plików, także tych nietypowych. Jeśli ma liczyć wynagrodzenie prowizyjne, dołącz arkusz, w którym liczysz je dziś, razem z opisem zasad.

Przed wysłaniem usuń dane osobowe i poufne albo zastąp je fikcyjnymi. Struktura dokumentu i przypadki brzegowe mają większe znaczenie niż konkretne nazwiska i kwoty.

Test przed wysłaniem do wykonawców

• Daj dokument osobie, która będzie z aplikacji korzystać na co dzień. Czy rozpoznaje w nim swoją pracę?
• Poproś kogoś spoza projektu, żeby własnymi słowami opowiedział, co ma powstać. Jeśli jego wersja się różni, dokument jest niejasny.
• Sprawdź, czy każde wymaganie da się zweryfikować przy odbiorze. „Szybki” nie da się sprawdzić, „wynik wyszukiwania w ciągu kilku sekund” już tak.
• Upewnij się, że przy każdej integracji jest wskazany system i kierunek przepływu danych.

Przykładowy spis treści specyfikacji

1. Kontekst firmy i opis problemu
2. Cel biznesowy i sposób pomiaru
3. Użytkownicy i ich zadania
4. Scenariusze użycia, w tym wyjątki
5. Integracje z innymi systemami
6. Wymagania pozafunkcjonalne
7. Priorytety i podział na etapy
8. Warunki formalne i oczekiwany harmonogram
9. Załączniki: szkice, przykładowe dokumenty, raporty

Czego nie pisać w specyfikacji

Nie narzucaj technologii bez powodu, takiego jak utrzymanie aplikacji przez własny zespół IT. Nie kopiuj wymagań z internetu „na zapas”, bo każde dodatkowe zdanie podnosi wycenę. Unikaj ogólników w rodzaju „system ma być intuicyjny i szybki”. Lepiej napisać, że zamówienie ma się dać złożyć w kilku krokach na telefonie.

Nie zakładaj też, że wykonawca zna Twoją branżę. Skróty i nazwy wewnętrzne, oczywiste dla Twoich pracowników, objaśnij w krótkim słowniczku.

Po specyfikacji przychodzi warsztat z wykonawcą

Nawet najlepszy dokument nie zastąpi warsztatu, na którym razem z wykonawcą przejdziecie przez scenariusze. Dobry software house zada pytania, których nie przewidziałeś, i zaproponuje uproszczenia. Wycena bez żadnych pytań to sygnał ostrzegawczy.

W FX2 projekty aplikacji i automatyzacji na zamówienie zaczynamy właśnie od takiej rozmowy i pomagamy uporządkować wymagania, nawet gdy masz tylko ogólny pomysł. Masz już pierwszy opis, choćby roboczy? Wyślij go nam i umówmy się na jego omówienie.