Jak napisać prostą i zrozumiałą specyfikację?

Instytucje kultury i organizacje pozarządowe coraz odważniej wkraczają w cyfrowy świat i tworzą własne narzędzia: serwisy, gry, aplikacje, strony www. Po fazie koncepcyjnej a przed fazą produkcji narzędzia potrzebne jest opisanie założeń technologicznych i funkcjonalnych narzędzia, składających się na specyfikację, która posłuży do wyceny i stworzenia planu projektu. Specyfikacja często kojarzy się z niezwykle obszernym dokumentem, który raz na zawsze rozwiązuje wszelkie wątpliwości nim jeszcze narzędzie wejdzie w fazę realizacji.
Pokutują następujące przekonania:

• Dobra specyfikacja musi mieć co najmniej kilkadziesiąt stron.
• Najlepiej, żeby specyfikację napisał nasz informatyk, on zna się na tym najlepiej.
• Na początku musimy wybrać technologię i napisać szczegółową specyfikację, aby podwykonawca zrobił dokładnie to, czego od niego oczekujemy.

Czy na pewno?

W dobie szybkiego rozwoju nowych technologii, gdy co kilka tygodni lub miesięcy pojawiają się nowe rozwiązania i języki programowania, poleganie na tego typu specyfikacji może okazać się zgubne – ryzykujemy, że produkt, który otrzymamy będzie przestarzały w momencie wdrożenia. Jest to problem spotykany w rozwiązaniach przygotowywanych latami przez administrację publiczną, gdzie – również z powodu obowiązujących ustaw i regulacji – ogromną wagę przywiązuje się do stworzenia obszernej i bardzo szczegółowej specyfikacji, która pozwala na spisanie równie szczegółowej, jednak pozornie tylko bezpiecznej dla zleceniodawcy umowy.

Nasze podejście – agile

W Pracowni Otwierania Kultury do opracowania specyfikacji postanowiliśmy podejść zgodnie z filozofią agile (przyświecającą nam w całym projekcie). Agile opiera się na iteracjach, podczas których wytwarzana i testowana jest niewielka część oprogramowania. Umożliwia to szybką reakcję na zmiany i niepowodzenia oraz modyfikację założeń, nawet na późniejszych etapach.

Podczas rozmów z podwykonawcami, którzy mogliby wykonać dla nas nagrodzone w konkursie narzędzia, bardzo zależało nam na tym, aby wszystkie strony: czyli my, twórcy Pracowni Otwierania Kultury, osoby, które brały udział w opracowywaniu koncepcji narzędzia z ramienia instytucji oraz zespół developerski rozumiały założenia technologiczne i funkcjonalne aplikacji tak samo. Aby wymagania były jednakowo zrozumiałe dla ‘humanistów’ i ‘ścisłowców’, dla klienta i podwykonawcy i by możliwe było dokonanie wyceny, a następnie opracowanie planu projektu: harmonogramu, listy i kolejności prac do wykonania. Specyfikacja miała być również maksymalnie krótka i doprecyzowana.

Prosto i zrozumiale, czyli zalety zwinnego podejścia

Do opracowania założeń funkcjonalnych aplikacji webowej lub mobilnej w zrozumiały sposób przydadzą się historyjki użytkownika (user stories), które opisują z punktu widzenia użytkownika, jaka funkcja aplikacji jest potrzebna i dlaczego. Można je podzielić na te dotyczące dwóch głównych aktorów systemu: użytkownika i administratora (który będzie odpowiadał za aktualizację treści w aplikacji).

Przykładowa historyjka użytkownika

Mam możliwość utworzenia kolażu (grafiki łączącej tła, atrybuty oraz zdjęcia), żeby podzielić się nim na portalu społecznościowym.

Przykładowa historyjka dla administratora

Mogę dodawać tła do galerii teł, usuwać je, dezaktywować lub przesuwać między poziomami do odblokowania, aby odświeżać i zmieniać zawartość aplikacji zgodnie ze strategią instytucji.

Historyjki użytkownika powinny mieć określoną formę, by łatwiej było skupić się na treści, np:

Jako <kto?> (rola, np. użytkownik lub admniistrator)
mogę/chcę <co?> (funkcja, lub problem do rozwiązania)
aby <dlaczego?> (jaki jest cel lub korzyść z wprowadzenia tej właśnie funkcji)
+ opcjonalnie dodatkowe szczegóły.

Podanie celu, czyli odpowiedź na pytanie dlaczego? pozwala zweryfikować, czy dana funkcjonalność jest faktycznie potrzebny i czy buduje wartość dla użytkownika. Dzięki temu możemy szybko odrzucić te, które nic nie wnoszą. Pozwala też lepiej wyobrazić sobie działanie programu i sposoby na jego wytworzenie członkom zespołu developerskiego

Więcej wskazówek na temat tego jak pisać user stories znajdziesz w poniższym filmie. Możesz też wykorzystać do tego nasze karty pracy User Stories

Kto powinien napisać specyfikację

Założenia technologiczne i funkcjonalne w postaci historyjek użytkownika, powinny opracować osoby, które stworzyły koncepcję narzędzia, mają jasną wizję jego działania i wartości, jaką niesie dla użytkownika. Szczególnie ważne wydaje się to w obszarze kultury i edukacji, gdzie na powodzenie narzędzia ma duży wpływ znajomość swojej grupy docelowej, której mogą nie posiadać firmy zajmujące się na co dzień wytwarzaniem oprogramowania dla biznesu.

O czym jeszcze pamiętać

Dla dopełnienia obrazu planowanego przez nas narzędzia warto do historyjek użytkownika dodać kilkuzdaniowy opis naszego narzędzia, użytkowników, oraz wartość dodaną jaką ma dla nich zaprojektowane przez nas narzędzie. Ważne są też założenia technologiczne – kilka zdań o tym, czym ma być nasze narzędzie, np. aplikacją mobilną na platformę iOS działającą offline lub aplikacją webową działającą w najpopularniejszych przeglądarkach.

Podsumowanie

Model agile zakłada współpracę między podwykonawcą a klientem, rodzaj partnerstwa w drodze do celu, który wymaga zaangażowania w proces powstawania aplikacji ze strony klienta i podwykonawcy. Zyskują na tym obie strony – klient może poznać nowe obowiązujące technologie, a zespół developerski – lepiej zrozumieć potrzeby klienta. To wzajemne zrozumienie ma odzwierciedlenie w skrojonym na miarę, prostym i zrozumiałym dla użytkownika narzędziu.
Aby takie narzędzie powstało, ważne jest dobre jego zaplanowanie, którego podstawą jest jasna i zrozumiała dla wszystkich stron specyfikacja. Zgodnie z tym podejściem rozwijamy nasze projekty w Pracowni Otwierania Kultury.