Specyfikacja oprogramowania, gdy ekspert nie ma czasu

Specyfikacji oprogramowania nie musi pisać ekspert, który zna proces. Spisuje ją ktoś inny na podstawie krótkiej rozmowy z nim, ekspert czyta szkic i mówi tak albo nie. Do pierwszej wersji wystarczy jedna strona, a najważniejsze zdanie mówi, po czym poznać, że jest gotowe.

Poniżej: dlaczego specyfikacja często nigdy nie powstaje, co musi zawierać, metoda w pięciu krokach i kiedy ją zamrozić. Artykuł jest dla właścicieli i kierowników działów, których najlepsza osoba od procesu nie ma czasu pisać.

Dlaczego specyfikacja nigdy nie powstaje?

Prawie każda firma ma kogoś, kto dokładnie wie, jak powinien działać proces. Wie, który klient chce fakturę inaczej i czego w arkuszu nie wolno nadpisać. Cały dzień ten proces wykonuje.

I właśnie dlatego nie ma czasu go opisać. Dostawca czeka na specyfikację. Ekspert czeka na wolne popołudnie. Ono nie przychodzi, a proces dalej idzie ręcznie.

Z AI programowanie przyspieszyło. To czekanie nie. Wąskim gardłem często nie jest dziś programowanie, tylko to, że nikt nie potrafi dokładnie powiedzieć, co trzeba zbudować. Fred Brooks napisał to już w 1987 roku:

Rozwiązaniem nie jest wysłanie ekspertowi szablonu specyfikacji. Nie wypełni go z tego samego powodu, z którego nie napisał dokumentu. Rozwiązaniem jest zdjąć z niego pisanie.

Rozmowa zamiast dokumentu

Ekspert potrafi mówić o swojej pracy bez przygotowania. Wystarczy pozwolić mu pokazać, jak to robi, i zadawać pytania. Z rozmowy szkic spisuje ktoś inny, a ekspert tylko go czyta. Na to czas znajdzie.

Najlepiej działa rozmowa nad prawdziwą pracą. Ekspert otwiera maila, arkusz albo program i pokazuje ostatni przypadek. Przy okazji mówi rzeczy, których nigdy nie wpisałby do dokumentu, bo są dla niego oczywiste.

Jeszcze lepszy od dokumentu jest prototyp. Gdy ekspert przeklika pierwszą wersję, w kilka minut powie, co się nie zgadza. Na papierze trwałoby to tydzień uwag.

Co musi zawierać specyfikacja?

Specyfikacja pierwszej wersji mieści się na jednej stronie. Każda część to odpowiedź na jedno pytanie, które zadają Państwo ekspertowi w rozmowie:

Wiersz „czego nie ma w pierwszej wersji” jest tak samo ważny jak pozostałe. Bez niego pierwsza wersja rośnie, aż staje się całym systemem. A ostatni wiersz decyduje, czy specyfikację w ogóle da się spełnić.

Jak napisać specyfikację krok po kroku?

Cała metoda zajmuje ekspertowi kilka godzin rozłożonych na tydzień, a nie tydzień pisania:

Różnicę robi drugi krok. Kto spisuje, musi umieć zadawać pytania i nie może niczego dopowiadać sam. Gdzie brakuje odpowiedzi, zapisuje pytanie, a nie domysł.

Kiedy zamrozić specyfikację?

Specyfikacja, która zmienia się codziennie, to nie elastyczność. To specyfikacja pisana w trakcie budowy. Z ludźmi dało się to jakoś przeżyć, bo programista zauważał zmianę i pytał. Agent AI nie zapyta. Zbuduje to, co ma przed sobą, nawet jeśli wczoraj obowiązywało coś innego.

Potem można zmieniać, ile trzeba. Tylko że to widać, a każdy, kto nad tym pracuje, wie, co obowiązuje.

Jak to wygląda w praktyce?

Dobra specyfikacja bywa krótsza, niż ludzie się spodziewają. Przy przetwarzaniu faktur w księgowości chodziło o jeden krok: faktura przychodzi mailem jako PDF i ktoś ręcznie ją przepisuje. Cel dało się powiedzieć prosto: faktura jest zapisana bez ręcznego przepisywania.

Tak zawężoną specyfikację da się szybko zbudować i sprawdzić na prawdziwych danych. Który krok wybrać najpierw, opisujemy w artykule Jakie procesy w firmie automatyzować najpierw?. Jeśli proces żyje dziś w arkuszu, pomoże też Kiedy Excel przestaje wystarczać firmie?

Czy specyfikacja jest gotowa?

Proszę zaznaczyć, co już wiedzą Państwo o procesie, który ma przejąć system:

Kiedy to nie wystarczy

• Nikt nie robi procesu dwa razy tak samo. Jeśli każdy rozwiązuje każdy przypadek inaczej, najpierw trzeba uzgodnić sposób działania. Oprogramowanie nie ujednolici tego, czego ludzie nie ujednolicili.
• Chodzi o cały system naraz. Jedna strona wystarczy do pierwszej wersji jednego procesu, a nie do zastąpienia całego systemu firmowego. Większy projekt proszę podzielić na mniejsze kroki.
• Decyduje ktoś, kogo nie było przy rozmowie. Jeśli specyfikację zatwierdza zarząd, który procesu nie wykonuje, warto zaprosić go przynajmniej na przeklikanie prototypu.

Chcą Państwo specyfikacji bez pisania?

Przy demo Państwa procesu omawiamy zadanie krok po kroku z osobą, która je wykonuje. Od Państwa godzina jej czasu i jedno spotkanie, na którym wspólnie przeklikamy prototyp. W ciągu 10 dni roboczych widzą Państwo, jak system wykonywałby Państwa ręczną pracę.

Jeśli budują Państwo nowy produkt, a nie proces wewnętrzny, proszę zacząć od briefu pierwszej wersji na 1 stronie. Jeśli wolą Państwo najpierw porozmawiać, proszę zarezerwować 15-minutową rozmowę wstępną.

Kto jest u Państwa tą osobą, na której specyfikację wszyscy czekają od pół roku?

Najczęściej zadawane pytania

Kto powinien pisać specyfikację oprogramowania?

Niekoniecznie osoba, która zna proces. Jej zadaniem jest wyjaśnić pracę i potwierdzić szkic. Spisać go może ktoś inny na podstawie krótkiej rozmowy: analityk, dostawca albo kolega, który umie zadawać pytania.

Jak długa powinna być specyfikacja?

Do pierwszej wersji wystarczy jedna strona: co dziś robi człowiek, co ma robić system, skąd bierze dane, kto z niego korzysta, czego nie ma w pierwszej wersji i po czym poznać, że jest gotowa. Długiej specyfikacji nikt nie doczyta do końca.

Co jest w specyfikacji najważniejsze?

Zdanie, po czym poznać, że jest gotowe. Na przykład: zamówienie z maila trafia do systemu bez przepisywania, a człowiek tylko je sprawdza. Bez niego nad specyfikacją można pracować bez końca.

Co, jeśli specyfikacja zmienia się w trakcie prac?

Zmiany są normalne. Ważne jest jedno miejsce, w którym żyje specyfikacja, jedna osoba, która mówi „to obowiązuje”, i data, po której każda zmiana idzie jako nowe zadanie, a nie poprawka starego.

Czy można zacząć bez specyfikacji?

Można zacząć od prototypu. Osoba, która wykonuje pracę, przeklika go i od razu powie, co się nie zgadza. Klikalny prototyp jest często lepszą specyfikacją niż dokument, bo widać na nim, czego brakuje.