Magiczna moc dokumentu

Magiczna moc dokumentu wywiera magiczny wpływ także na projektantów.

Typowym błędem, który my informatycy popełniamy, jest tworzenie dokumentacji projektowej "na półkę". Do takiego postępowania często przyczyniają się nieświadomie handlowcy i kierownictwo wyższego szczebla, którzy bez wstępnej analizy problemu tworzą na poziomie umowy dokumenty, które muszą powstać przed wytworzeniem kodu. Bardzo często z takimi dokumentami związane są płatności za poszczególne etapy. W efekcie wykonawca skupia się na tworzeniu dokumentu, a nie na projektowaniu systemu. Usłyszałem kiedyś takie zdanie: "Za dokumenty bierzemy 70% kosztów, dlatego nie zastanawiamy się w tej chwili nad projektem systemu tylko nad wykonaniem dobrych dokumentów".

W pewnym projekcie wykonawcy popełnili błąd na początku, niepoważnie traktując model wymagań. Potraktowano go jako kolejny dokument, który musi dobrze wyglądać, by klient za niego zapłacił. Projektanci praktycznie zaraz po oddaniu modelu wymagań przeszli do projektowania systemu nie zaglądając do dokumentu, który wcześniej stworzyli.

Źródłem wielu problemów związanych z niewłaściwym zrozumieniem roli dokumentacji projektowej jest brak porozumienia i współpracy między wykonawcą a zleceniodawcą. Projektanci nie mogli uzgodnić z klientem wizji tworzonego systemu. Wszystkie dokumenty, jakie tworzyli, powstawały w zaciszu pracowni projektanta bez współpracy lub z nikłą współpracą użytkownika. Im dalej posuwały się prace, tym większe napięcie narastało między projektantami a użytkownikiem. Projektanci uważali, że użytkownik "czepia się" ich rozwiązań. Natomiast użytkownik sądzi, że projektanci w ogóle go nie słuchają, a dokumenty zawierają zbyt powierzchowne treści. W wyniku takiego postępowania maleje motywacja użytkownika do dalszej współpracy, rośnie natomiast frustracja i przekonanie, że powstający system będzie nie tym, czego użytkownik oczekuje.

Jednak wpływ kierownictwa na oddawanie i odbiór prac jest na tyle silny, że obie strony przyjmują strategię "spychania śmieci pod dywan". Użytkownik zwraca uwagę tylko na ewidentne błędy, które udało się wykryć. Projektant skupia się na oddaniu dokumentów w terminie. Prawdziwe projektowanie rozpoczyna się dopiero podczas kodowania, gdy już nie da się robić uników na papierze.

Przypomnijmy jeszcze raz, ludzie wymyślili modele danych, modele procesów, diagramy zdarzeniowe i inne notacje po to, by móc się komunikować. My, projektanci, często tak się zachowujemy, jakbyśmy zupełnie o tym nie pamiętali.

Skoro jest tak źle, to czy może być lepiej?

Skoro techniki analizy i projektowania nie sprawdzają się w praktyce, czy oznacza to, że nie kwalifikują się do budowy systemów? Moim zdaniem nadają się doskonale, pod warunkiem że są właściwie stosowane.

Zacznijmy od wymagań. Trudno jest zbudować system użyteczny z punktu widzenia użytkownika bez współpracy z nim. To on jest odpowiedzialny za określenie celu systemu i zdefiniowanie wymagań, jakie muszą być przez system spełnione. Jest to podstawowe zadanie merytorycznych specjalistów, definiujących wymagania na system w obszarach, w których są kompetentni. Nie możemy oczekiwać od projektantów-informatyków, że będą wiedzieli, jak ma np. działać system do monitorowania pacjenta na sali operacyjnej. Oczywiście, zespołem analityków kieruje doświadczony analityk-informatyk, który odpowiada za formalną poprawność i spójność modelu. Jego zadaniem jest również pragmatyczne stosowanie technik modelowania, tak aby jak najlepiej opisać dany projekt.

Merytoryczna poprawność wymagań zależy jednak przede wszystkim od użytkowników.

Sposobem na ich zaangażowanie mogą być sesje interakcyjnego projektowania (zwane w skrócie sesjami JAD - Joint Application Development). Sesje JAD różnią się od zwykłych spotkań. Każda musi być dobrze przygotowana i przeprowadzona. Użytkownicy powinni znać plan i jej cel przed spotkaniem. Sesja trwa kilka godzin i dzięki stosowaniu odpowiednich technik pracy zespołowej z reguły kończy się pomyślnymi ustaleniami. Użytkownicy i projektanci mają satysfakcję z uczestniczenia w spotkaniach, które są efektywne. Jest to doskonały sposób na zwiększenie motywacji projektantów i użytkowników. Praca grupowa podczas sesji JAD jest również dobrym sposobem na integrację zespołu. Wspólne rozwiązywanie problemów powoduje, że użytkownicy, podobnie jak projektanci, czują się autorami systemu. Jest to nieoceniona wartość dla projektu.

Obserwowałem kiedyś pracę dwóch zespołów, które miały podobne zadania. Oba zespoły pracowały w ogromnym stresie pod dużą presją czasu. W zespole A kierownik przydzielił każdemu projektantowi jeden dokument do opracowania. W zespole B przydzielił trzy projekty trzem grupom składającym się z 2-3 osób każda. Zespół A długo nie mógł przygotować dokumentów, które byłyby spójne. Co więcej, dokumenty te nie opisywały systemu na zadowalającym poziomie. Zespół B był mniej doświadczony od zespołu A, mimo to bardzo szybko przygotował jeden z lepszych dokumentów w projekcie. Był to wręcz kliniczny przypadek przewagi pracy zespołowej nad indywidualną.