Pomysł na aplikację często zaczyna się od zdania: „przydałoby się miejsce, w którym można zrobić wszystko”. To naturalny początek rozmowy, ale słaby początek budowy. Nie wiadomo jeszcze, kto ma z tego korzystać, w jakim momencie, co dokładnie ma się zmienić i po czym poznamy, że rozwiązanie działa.

Nie trzeba znać języka technicznego, żeby przygotować użyteczny opis aplikacji. Trzeba za to umieć opisać rzeczywistość przed zmianą i po zmianie.

Budując NIENARAZ OS, nauczyłem się, że najlepszy brief nie jest katalogiem funkcji. Jest mapą jednego problemu i granicą, która chroni produkt przed rozrastaniem się we wszystkie strony.

Specyfikacja nie jest instrukcją dla programisty

Na wczesnym etapie nie musisz decydować o bazie danych, języku programowania ani architekturze. To są odpowiedzi techniczne. Najpierw potrzebujesz odpowiedzi produktowych.

Specyfikacja powinna pozwolić drugiej osobie — programiście, projektantowi albo AI — zrozumieć:

  • kto ma problem,
  • kiedy problem się pojawia,
  • jak jest rozwiązywany dzisiaj,
  • jaki najmniejszy rezultat ma dać aplikacja,
  • co znajduje się poza pierwszą wersją,
  • po czym sprawdzimy, że funkcja działa.

    • Jeżeli te elementy są jasne, technologia może zostać dobrana do problemu. Jeżeli nie są jasne, technologia zaczyna prowadzić projekt zamiast go wspierać.

    Krok 1: opisz konkretną osobę w konkretnej sytuacji

    „Aplikacja dla firm” to za mało. Firma nie klika w przyciski. Robi to konkretna osoba, która ma cel, ograniczenia i określony poziom dostępu.

    Lepszy opis brzmi: „właściciel małej firmy po spotkaniu z klientem chce zapisać decyzję, zanim zgubi się ona w komunikatorze”. Od razu wiadomo, kto działa, kiedy i z jakiego powodu.

    Nie potrzebujesz rozbudowanej persony. Na początek wystarczą trzy zdania:

    1. Kim jest użytkownik? 2. Co próbuje zrobić? 3. Co przeszkadza mu dzisiaj?

    Krok 2: opisz stan obecny bez upiększania

    Zapisz, jak człowiek radzi sobie z problemem teraz. Może wysyła sobie wiadomość, używać arkusza, dzwonić do pracownika albo przechowywać wszystko w głowie.

    Ten prowizoryczny proces jest cennym źródłem wiedzy. Pokazuje kolejność działań, dane potrzebne użytkownikowi i momenty, w których coś się gubi. Aplikacja nie powinna kopiować chaosu jeden do jednego, ale musi rozumieć, dlaczego obecny sposób w ogóle powstał.

    Krok 3: wybierz jeden pełny obieg

    Najczęstszy błąd to opisanie dziesięciu modułów, zanim zadziała pierwsza ważna czynność. Zamiast tego wybierz jeden obieg od początku do końca.

    Przykład:

    1. Użytkownik nagrywa krótką notatkę. 2. System pokazuje jej treść do sprawdzenia. 3. Użytkownik wybiera, czy to zadanie, decyzja czy zwykła notatka. 4. Element trafia do właściwego miejsca. 5. Użytkownik widzi potwierdzenie zapisu.

    To jest pełny obieg. „Ekran głosówek”, „moduł zadań” i „panel decyzji” są tylko fragmentami interfejsu.

    Krok 4: nazwij dane i granice dostępu

    Nawet prosta funkcja korzysta z danych. Zapisz, jakie informacje wchodzą do systemu, gdzie powinny trafić i kto może je zobaczyć.

    Zapytaj:

  • czy dane są publiczne, firmowe czy prywatne,
  • czy zawierają informacje o klientach lub innych osobach,
  • kto może je edytować i usuwać,
  • co powinno się wydarzyć, gdy zapis się nie powiedzie.

    • Nie jest to techniczny dodatek na koniec. Granice danych wpływają na cały projekt od pierwszego dnia.

    Krok 5: zapisz kryteria akceptacji

    Kryterium akceptacji to zdanie, które można sprawdzić. „Aplikacja ma być intuicyjna” nie jest kryterium. „Po zapisaniu notatki użytkownik widzi ją na liście właściwego projektu” — jest.

    Dobre kryteria opisują zachowanie, a nie wygląd:

  • użytkownik może wykonać czynność,
  • system pokazuje oczekiwany rezultat,
  • błąd ma czytelny komunikat,
  • osoba bez uprawnień nie widzi danych,
  • obieg działa również na telefonie.

    • To właśnie kryteria pozwalają później sprawdzić pracę AI, zamiast przyjmować komunikat „gotowe” na wiarę.

    Krok 6: stwórz listę „nie teraz”

    Dobry zakres mówi nie tylko, co powstaje. Mówi też, czego świadomie nie budujemy w tej wersji.

    Lista „nie teraz” chroni przed dopisywaniem kolejnych pomysłów w trakcie pracy. Nie oznacza, że są złe. Oznacza, że najpierw chcemy zdobyć dowód dla jednego obiegu.

    Przykładowo: bez aplikacji mobilnej w sklepie, bez automatycznych powiadomień, bez importu wszystkich historycznych danych, bez pięciu ról użytkownika. Każdy z tych elementów może wrócić, gdy podstawowy proces okaże się użyteczny.

    Prosty szablon opisu aplikacji

    Skopiuj i uzupełnij:

    Użytkownik: Kto korzysta z rozwiązania?

    Sytuacja: Kiedy pojawia się problem?

    Dzisiaj: Jak użytkownik radzi sobie bez aplikacji?

    Pierwszy rezultat: Co jedna wersja ma poprawić?

    Obieg: Jakie kroki prowadzą od wejścia do rezultatu?

    Dane i dostęp: Jakie informacje są używane i kto może je zobaczyć?

    Kryteria akceptacji: Po czym sprawdzimy, że działa?

    Nie teraz: Czego świadomie nie budujemy?

    Taki dokument nie musi mieć trzydziestu stron. Dla pierwszej funkcji często wystarczy jedna. Jego wartość nie wynika z długości, tylko z tego, czy ogranicza pole do interpretacji i pozwala zweryfikować rezultat.

    Nieprogramista nie musi opisywać, jak napisać kod. Powinien możliwie jasno opisać, dlaczego ten kod ma powstać, komu ma pomóc i jaki dowód zakończy pracę.