Dokumentacja analityczna (np. model procesów biznesowych, specyfikacja wymagań, analiza funkcjonalna) zwykle podlega akceptacji i odbiorowi przez klienta. Po oficjalnej dostawie takiej dokumentacji klient ma oczywiście prawo zgłaszać do niej uwagi. Są one zwykle bardzo cenne, ponieważ obszerny, niekiedy kilkusetstronicowy dokument nawet po wewnętrznej kontroli jakości wykonawcy nie będzie wolny od błędów. Jak jednak sprawić, żeby odbiór dokumentacji analitycznej nie przeciągał się w nieskończoność?
Procedura odbioru...
Kluczowym czynnikiem sukcesu jest odpowiednie zdefiniowanie procedury odbioru dokumentów projektowych. Wiadomo, że musi ona umożliwiać klientowi zgłoszenie uwag, zaś wykonawcy uwzględnienie tych uwag i dostarczenie kolejnej wersji dokumentu. Koniecznie należy określić czas, jaki ma klient na zgłoszenie uwag oraz czas, jaki ma wykonawca na ich uwzględnienie (z reguły jest to od 3 do 5 dni roboczych). Warto także pamiętać o jednym pozornie drobnym, ale niezwykle ważnym zapisie: weryfikując kolejną (tj. inną niż pierwszą) wersję dokumentu, klient może zgłosić uwagi wyłącznie do zapisów, które uległy zmianie od wersji poprzedniej, lub które z taką zmianą są związane. Zapis taki blokuje możliwość zgłoszenia przez klienta uwagi do wersji 1.5 dokumentu, dotyczącej zapisów, które od wersji 1.1 pozostają niezmienione. Dzięki temu z każdą kolejną wersją dokumentu liczba uwag zmniejsza się. Weryfikując wersję 1.5 klient nie zaskoczy nas serią uwag do zapisów, na które "jakoś nikt wcześniej nie zwrócił uwagi".
Idealnie byłoby wprowadzić taką zasadę w samej umowie na wykonanie prac. Procedura odbioru dokumentów projektowych może być załącznikiem do umowy. Jednak nawet jeśli umowa nie określa procedury odbioru, lub procedura zawarta w umowie nie zawiera wspomnianego zapisu, warto się postarać o jego wprowadzenie już w trakcie trwania projektu. Można taki zapis umieścić w planie projektu, o ile jego dostarczenie jest przewidziane w umowie. Można także zaproponować go w trakcie bieżących ustaleń, np. podczas pierwszego spotkania projektowego, a następnie udokumentować w notatce ze spotkania. Z akceptacją takiej zasady przez klienta nie powinno być problemu, ponieważ jest ona zdroworozsądkowa i tak na prawdę korzystna także dla klienta. Zmusza go bowiem do uważnej lektury dokumentów projektowych i przyczynia się do szybszego zatwierdzenia tych dokumentów, na czym przecież zależy także klientowi. W mojej praktyce głównego analityka i kierownika projektów nie zdarzyło mi sie jeszcze, żeby po zaproponowaniu wspomnianej zasady i przedstawieniu korzyści z niej wynikających, klient odmówił jej przyjęcia.
... i jej praktyczne stosowanie
Co jednak zrobić w sytuacji, gdy wspomniana zasada została przyjęta, a mimo to klient zgłasza uwagi do zapisów, które nie uległy zmianie od poprzedniej wersji? Jeśli klient znajduje w ten sposób istotne błędy popełnione przez wykonawcę w dokumencie, które z jakiegoś powodu nie zostały wcześniej wychwycone, to warto takie uwagi przyjąć i błędy poprawić. Możemy na tym jedynie zyskać - zarówno jeśli chodzi o jakość dokumentacji, jak i relacje z klientem. Gorzej, jeśli zgłaszane w ten sposób uwagi nie dotyczą ewidentnych błędów wykonawcy, lecz np. nieścisłości merytorycznych, które klient powinien zgłosić od razu po otrzymaniu pierwszej wersji dokumentu. W pojedynczych, uzasadnionych przypadkach można takie uwagi uwzględnić (chociaż istnieje wtedy ryzyko, które można zilustrować powiedzeniem "daj palec, a weźmie całą rękę"). Co jednak zrobić, gdy nagle dostajemy takich uwag kilkanaście lub kilkadziesiąt?
Można w takiej sytuacji wykorzystać strategię, którą zastosowałem w projekcie doradczym dla dużej instytucji publicznej. Projekt polegał na opracowaniu modelu procesów biznesowych organizacji oraz przygotowaniu opisu przedmiotu zamówienia, który miał stać się załącznikiem do specyfikacji istotnych warunków zamówienia (SIWZ) na system informatyczny, jaki owa instytucja planowała zamówić. Ze strony klienta w projekcie uczestniczyło kilkanaście osób - specjalistów biznesowych, a więc i liczba zgłaszanych przez nie uwag była spora. Poszczególne dokumenty wykonały już po kilka iteracji, a ich numery wersji dochodziły do 1.5. Nieuchronnie zbliżał się termin odbioru prac. Po otrzymaniu jednej z kolejnych wersji dokumentacji, klient niespodziewanie nadesłał uwagi do zapisów, które nie uległy zmianie od pierwszych wersji dokumentów. Postąpiłem wówczas następująco: odrzuciłem wszystkie takie uwagi, podając jako uzasadnienie: "zgłoszone po terminie". Następnie poprosiłem zespół klienta o spotkanie. Na spotkaniu zaproponowałem, że uwzględnimy wszystkie zgłoszone po terminie uwagi, pod warunkiem, że zrobimy to wspólnie w trakcie tego spotkania i że wyjdziemy ze spotkania z zatwierdzoną dokumentacją. Zespół klienta, mając świadomość, że "zawalił" termin zgłoszenia uwag, przystał na takie rozwiązanie. Podczas całodziennego spotkania wszystkie otwarte uwagi (także te zgłoszone zgodnie z procedurą i w terminie) zostały omówione, a odpowiednie zmiany zostały od razu wprowadzone do dokumentacji. Dzięki temu nie była już potrzebna kolejna czasochłonna iteracja: przekazanie nowej wersji dokumentów, zgłoszenie uwag, uwzględnienie uwag przez wykonawcę. Termin wykonania prac został dotrzymany. Taki interaktywny tryb pracy okazał się w końcowej fazie znacznie bardziej efektywny od sformalizowanej wymiany pisemnych uwag i odpowiedzi na nie.
Szymon Zioło
