Doświadczenie pokazuje, że klienci często nie mają wiedzy technicznej, a jednak są zmuszeni takie specyfikacje pisać. Bywa to dla nich stresujące: obawiają się, czy specyfikacja będzie profesjonalna" i czy nie pominą żadnych istotnych informacji. To zupełnie zrozumiałe i dlatego, jeśli Ty też masz podobne obawy, ten artykuł pomoże Ci stworzyć przejrzystą specyfikację techniczną dla zamawianego systemu.
Z artykułu dowiesz się:
jakie informacje powinieneś podać w specyfikacji
jakim językiem ją napisać
jak długa powinna być specyfikacja
Właściwie przygotowana specyfikacja gwarantuje, że wykonawca dobrze zrozumie Twoje wymagania, a Ty zaoszczędzisz mnóstwo czasu na komunikacji z nim. Przygotowaliśmy dla Ciebie wskazówki, dzięki którym dowiesz się, co jest najważniejsze przy tworzeniu specyfikacji oprogramowania. Rozwiejemy też wątpliwości związane z "profesjonalnym" językiem oraz odpowiednią długością tego dokumentu.
Tworząc dokument z wymaganiami dla wykonawcy, kieruj się zdrowym rozsądkiem. Skup się na problemie, jaki chcesz rozwiązać i opisz go jak najlepiej. Zacznij od ogólnych informacji o tym, czym się zajmuje Twoja firma i jakie miejsce ma w niej zająć nowy system. Pamiętaj, że wykonawca jest ekspertem IT i prawdopodobnie nie zna fachowych pojęć z Twojej branży, dlatego zastąp je językiem zrozumiałym dla ludzi spoza Twojej dziedziny. Wprowadź definicje, jeśli jakiejś kwestii nie da się opisać w inny sposób, ale pamiętaj, by z nimi nie przesadzać. Zdrowy rozsądek i prostota to klucz do napisania dobrej specyfikacji.
Kieruj się zasadą "od ogółu do szczegółu". Kiedy już przedstawisz kontekst, skup się na możliwie najdokładniejszym opisaniu kluczowego problemu, jaki będzie rozwiązywał zamawiany system. Opisz, w jaki sposób radzisz sobie z tym problemem obecnie (inny system, praca ludzka itp.) To pomoże wykonawcy lepiej zrozumieć całe zagadnienie i oszacować czas oraz koszty. Pamiętaj o bardzo ważnej kwestii: nie sugeruj, jak powinien działać program! Wprowadza to niepotrzebny chaos w dokumencie i negatywnie wpływa na jego czytelność.
Pozwól, że posłużymy się przykładem. Jeśli napiszesz: "po kliknięciu drugiej pozycji lewego menu otwiera się okno z formularzem rejestracji nowego klienta", to takim zdaniem zasugerujesz działanie systemu. Być może wykonawca zaproponuje rozwiązanie, w którym nie będzie takiego menu lub w którym nie będzie potrzeby otwierania nowego okna. Poprawnie to zdanie brzmi: "w systemie rejestrowani będą klienci". Tylko tyle potrzebuje wykonawca na tym etapie. Nie skupiaj się na wyglądzie - ten element rzadko jest istotny z punktu widzenia problemu, który chcesz rozwiązać.
Są to bardzo mile widziane elementy, które pozytywnie wpłyną na zrozumienie Twoich wymagań. Chodzi o to, żebyś opisał, jak według Ciebie będzie wyglądała praca z systemem. Jeszcze lepiej, gdy uwzględnisz kilka scenariuszy według poniższych podpunktów:
przykład typowej pracy z systemem,
kilka przykładów częstych odstępstw od standardu (np. program do przyjmowania faktur otrzymuje błędną fakturę - jaka powinna być reakcja systemu),
krótki opis ról użytkowników systemu (jakie mają mieć uprawnienia i na czym ma polegać ich interakcja z systemem).
Tutaj po raz kolejny powtórzymy naszą mantrę: kieruj się zdrowym rozsądkiem. Nie przesadzaj z ilością scenariuszy, opisz te oczywiste i pożądane z Twojej perspektywy.
W tym przypadku chodzi o konkretne dane liczbowe:
ilość użytkowników,
liczba lokalizacji, w których będzie działał system,
przewidywana liczba nowych rekordów głównego typu, czyli mówiąc obrazowo, jak intensywnie będzie eksploatowany system,
wszelkie inne dane ilościowe, które mogą być istotne w danym przypadku (np. jeśli system rejestruje przebieg samochodów, wypada podać przybliżoną liczbę pojazdów).
Nie myśl o tym, czy wykonawca uzna, że Twój dokument jest nieprofesjonalny. Nie jesteś fachowcem od systemów informatycznych i nikt nie oczekuje, że będziesz używał fachowego slangu. Pisz w jak najprostszy sposób, tak żeby nawet zwykły człowiek bez większych problemów zrozumiał Twój dokument. To wykonawca ma się wykazać profesjonalizmem i zrozumieć Twoje potrzeby, a im prościej je wyrazisz, tym bardziej mu to ułatwisz. W razie nieścisłości dostawca zawsze zapyta o niezrozumiałe kwestie.
To nieprawda, że dłuższa specyfikacja jest lepsza. Jest dokładnie na odwrót. Tutaj doskonale nada się przykład z naszej pracy. Jedna z najlepszych specyfikacji technicznych, jaką kiedykolwiek otrzymaliśmy, miała około pół strony tekstu i zdjęcie kartki, na której ręcznie naszkicowano schemat całego procesu.
Czy było to profesjonalne? Nie.
Czy tego typu specyfikacja dobrze wyjaśniała działanie systemu? Tak, robiła to doskonale.
To jedna z historii, z jaką mieliśmy styczność w naszej pracy.
Pewnego dnia, klient zlecił wykonanie specyfikacji do zewnętrznej firmy. Dokument opisywał nie tylko problem, ale też sugerował działanie systemu i robił to w absurdalny sposób. Po pierwsze każda klasa danych była przedstawiona za pomocą (błędnie przygotowanego) diagramu UML. Jakby tego było mało, do każdej klasy przypisana była tabela opisująca wszystkie atrybuty (cechy) danej klasy. Masa obrazków, schematów i tabel z informacjami, które w większości powtarzały te same treści.
Smutne jest to, że klient nie miał odpowiedniej wiedzy, aby zweryfikować zamówioną specyfikację i zapewne wyszedł z założenia, że jej długość znaczy o wysokiej jakości.
Zapłacił za coś, co prawdopodobnie sam przygotowałby lepiej.
Dla ukazania skali problemu: ten dokument z powodzeniem zmieściłby się na kilkunastu stronach A4. Domyślasz się, jaką miał rzeczywistą objętość?
Ponad 100 stron!
Jeśli tylko zastosujesz się do naszych wskazówek, bez problemu napiszesz dobrą specyfikację techniczną. To nie jest trudne i polega na tym, żeby jak najdokładniej opisać swoje wymagania względem systemu. Dzięki lekturze artykułów takich jak ten - napisanych przez ludzi tworzących systemy informatyczne znasz nasze oczekiwania i wiesz, co powinna zawierać specyfikacja. Zapewniamy Cię, że nikt nawet nie mrugnie okiem na "brak profesjonalizmu" Twojego dokumentu, a wręcz przyjmiemy to z ulgą, bo klienci często dosyć niefortunnie próbują używać technicznego żargonu.
Zachęcamy Cię też do wykonania specyfikacji osobiście lub z pomocą współpracowników, gdyż jako ludzie zapoznani z branżą, dokładnie wyjaśnicie, jaka ma być rola systemu w Waszym biznesie.
Teraz już wiesz, jak się do tego dobrze przygotować.
Jeśli zainteresował Cię ten artykuł, przeczytaj również 8 najczęstszych problemów ze specyfikacją techniczną.