Informatycy już w szkole uczą się jak pisać takie dokumenty. Właściciele firm z reguły nie mają takiego przywileju i często tworzą specyfikacje "na wyczucie" - i tak naprawdę nie ma w tym nic złego. Ważne, aby uniknąć kilku błędów, o których mowa w tym artykule.
Pisząc specyfikację, kieruj się przede wszystkim zdrowym rozsądkiem. W tym przypadku z jednej strony mamy bardzo ogólny dokument, który nie odpowiada na wiele ważnych pytań. Wykonawca musi dopytywać się o istotne kwestie, które powinny się w nim znaleźć. Mimo iż taka specyfikacja jest błędna, to i tak jest lepsza, niż jej przesadnie długa alternatywa.
Zbyt szczegółowe specyfikacje, to nierzadko obszerne dokumenty na kilkadziesiąt lub kilkaset stron, które można podsumować jednym i adekwatnym do sytuacji słowem - bełkot. Ciężko w nich odnaleźć ważne informacje, są nieintuicyjne i ich zrozumienie pochłania mnóstwo cennego czasu.
Jak widać łatwo tutaj popaść w skrajności. Z dwojga złego lepiej, gdy specyfikacja jest zbyt ogólna, bo wtedy wykonawca zapyta o brakujące informacje. Jednak w tym przypadku wszyscy tracą czas na zbędną komunikację, dlatego warto zastanowić się, czy Twoja specyfikacja zawiera wszystkie ważne informacje i czy są one podane w przejrzysty sposób.
Często zdarzają się klienci, którzy w specyfikacji próbują wyjaśnić, jak powinien działać system - a przecież to zadanie należy do wykonawcy. Twoim zadaniem jest jak najlepiej opisać problem, który ma rozwiązywać zamawiane oprogramowanie. Wyjątkiem jest sytuacja, gdy specyfikację tworzy osoba z doświadczeniem informatycznym - wtedy może zasugerować sposób realizacji systemu, ale wyłącznie w formie uzupełnienia do głównej specyfikacji.
Nie warto stawiać wymogów co do technologii z prostego powodu: wykonawca ma pod tym względem znacznie większe doświadczenie i z pewnością zaproponuje Ci najlepsze rozwiązanie. Jeśli jednak chcesz zasugerować jakąś technologię, uzasadnij, dlaczego uważasz ją za właściwą.
Podamy Ci tutaj przykład dla zobrazowania problemu. Zleceniodawca życzył sobie wdrożenia programu do rejestracji godzin pracy w technologii Java EE. Zrobił tak, ponieważ dowiedział się, że jest to platforma szeroko stosowana w biznesie. Nie wiedział jednak, że w tym konkretnym przypadku znacznie lepszą i równie funkcjonalną technologią mogło być PHP. Java jest wyraźnie droższa we wdrożeniu i utrzymaniu, a funkcjonalność obu systemów byłaby taka sama. Stąd prosty wniosek: w większości przypadków dobór technologii zostaw po stronie wykonawcy, a jeśli chcesz zaproponować własne, uzasadnij swój wybór.
Stylizowanie specyfikacji na wzór innych technicznych lub biznesowych dokumentów mija się z celem. Im prostsza i bardziej zrozumiała forma, tym lepiej dla wszystkich. Stosowanie skomplikowanych grafik, wykresów i map myśli nie jest dobrym rozwiązaniem. Podobnie ma się to z wykorzystaniem języka modelowania UML - nie przesadzaj z tym. Często lepiej będzie, gdy z niego zrezygnujesz, a wszystko wyjaśnisz własnymi słowami.
W specyfikacji liczą się konkrety - nadmierne rozpisywanie się zdecydowanie jest błędem. Jak myślisz, jaka treść znajdzie się w polu "Imię pracownika"? Odpowiedź jest oczywista, a jednak mieliśmy do czynienia ze specyfikacją, która wyjaśniała nawet tak banalne kwestie.
To zdecydowanie nie pomaga.
Popełnisz błąd, jeśli stworzysz specyfikację i na każde zapytanie wykonawcy będziesz odpowiadać "wszystko jest w specyfikacji". Rozumiemy, że nie chcesz tracić czasu na nadmierną komunikację na etapie, gdy przebierasz w różnych ofertach. Niestety, jeśli Twoja specyfikacja jest niekompletna, wina za napływające pytania leży po Twojej stronie. Wykonawca może nie znać specyfiki Twojej branży ani zasad panujących w Twoim biznesie, dlatego będzie potrzebował dodatkowych informacji, aby przygotować dla Ciebie precyzyjną wycenę.
Zwykle nie jest to dobre rozwiązanie, ponieważ firma, której zlecasz napisanie specyfikacji działa w innej branży niż Twoja. Mówiąc wprost: posługujecie się dwoma różnymi językami. Owszem, przygotowany dokument będzie technicznie w porządku, ale Ty nie dysponujesz odpowiednią wiedzą, aby go zweryfikować. Ponadto firma, która go przygotowuje, nie zna specyfiki Twojej branży i zasad, jakie panują w Twojej firmie. Rodzi to wiele możliwości do nieporozumień, przeinaczeń i wymagań niezgodnych z rzeczywistością. Zdecydowanie zachęcamy Cię, abyś napisał specyfikację samodzielnie lub z pomocą pracowników, gdyż Wy najlepiej wiecie, do czego potrzebny będzie zamawiany system i w jaki sposób ma on pracować w waszej firmie.
Ostatni problem, który w zasadzie dyskwalifikuje specyfikację techniczną, to niespójne wymagania. Sytuacja taka z reguły ma miejsce, gdy osoby z różnych działów firmy dopisują swoje wymogi, a nikt nie czuwa nad tym, aby nadać im jednolity sens i kierunek. W efekcie dostajemy dokument, który albo jest pełen sprzeczności, albo opisuje bardzo nieintuicyjny i wysoce kosztowny lub nawet niemożliwy do realizacji system.
Znasz już popularne i bardzo uciążliwe błędy, jakie popełniają ludzie, którzy nie mają doświadczenia w tworzeniu specyfikacji. Możesz je wyeliminować w bardzo prosty sposób - wystarczy, że zrobisz ich listę i prześledzisz świeżo napisaną specyfikację pod ich kątem oraz poprawisz wszystkie problematyczne miejsca. Zapewniamy Cię, że dobrze przygotowana specyfikacja da Ci mnóstwo korzyści, w tym oszczędność czasu i bardziej precyzyjne oferty od firm informatycznych. Wiele problemów ze specyfikacją wynika z niewiedzy lub dlatego, że klienci często bazują na popularnych mitach - i nie ma co się dziwić, gdyż nikt nie nauczył ich, jak robić to poprawnie. Skoro wiesz już jakich błędów unikać w swojej specyfikacji, zapoznaj się również z naszym poradnikiem, w którym dajemy 6 prostych wskazówek, jak napisać dobrą specyfikację techniczną.
Tak przygotowany nie będziesz miał problemów, aby we własnym zakresie stworzyć poprawną specyfikację, która będzie w czytelny sposób wyjaśniała problem, jaki ma rozwiązywać zamawiany przez Ciebie system.
Jeśli zainteresował Cię ten artykuł, przeczytaj również 6 wskazówek, dzięki którym napiszesz dobrą specyfikację.