Specyfikacja systemu biznesowego: co powinna zawierać, zanim powstanie kod

Po co specyfikacja, skoro „wszyscy wiedzą, o co chodzi”

Na etapie rozmów każdy wyobraża sobie system trochę inaczej. Zarząd myśli o raportach, kierownik o zleceniach, a wykonawca o bazie danych. Specyfikacja zamienia te wyobrażenia w jeden opis, który wszyscy akceptują przed rozpoczęciem prac.

Co powinna zawierać dobra specyfikacja

1. Cel systemu. Jaki problem rozwiązuje i po czym poznamy, że działa.
2. Role użytkowników. Kto będzie korzystał z systemu i za co odpowiada.
3. Procesy. Kolejne kroki pracy: od zgłoszenia do zakończenia sprawy.
4. Ekrany. Co widzi każda rola, jakie ma przyciski i jakie dane wprowadza.
5. Uprawnienia. Kto może przeglądać, edytować, zatwierdzać i usuwać.
6. Raporty. Jakie zestawienia dostają zarząd i kierownicy, jak często i z jakich danych.
7. Integracje. Z jakimi programami system wymienia dane i w którą stronę.
8. Dane początkowe. Co trzeba przenieść z arkuszy i starych programów.
9. Podział na etapy. Co wchodzi w pierwszą wersję, a co w kolejne.

Czego często brakuje

• Sytuacji wyjątkowych. Co się dzieje, gdy dokument zostaje odrzucony, zlecenie anulowane, a pracownik odchodzi z firmy.
• Kryteriów odbioru. Po czym obie strony uznają, że dana funkcja jest gotowa.
• Listy rzeczy, których system nie będzie robił. Jest równie ważna jak lista funkcji.

Jak czytać specyfikację jako zamawiający

Nie musisz znać się na programowaniu. Wystarczy, że dla każdej roli zadasz pytanie: czy ta osoba będzie w stanie wykonać swoją codzienną pracę na podstawie tego opisu? Jeśli odpowiedź brzmi „nie wiem”, specyfikacja wymaga doprecyzowania.

Specyfikacja to też podstawa wyceny

Bez specyfikacji każda wycena jest zgadywaniem. Z nią wykonawca może rzetelnie oszacować zakres prac, a firma porównać oferty, które dotyczą tego samego. Dlatego u mnie planowanie i specyfikacja są pierwszym etapem każdego projektu. Jeśli chcesz porozmawiać o swoim systemie, umów konsultację.