Według życzenia

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 o tym nie pamiętali.

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 o tym nie pamiętali.

Wielu z nas pamięta jeszcze nie tak odległe czasy, kiedy w sklepie trudno było kupić produkty o zadowalającej jakości i użyteczności. Jeżeli ktoś zapragnął nabyć coś specjalnie dla siebie, wybierał się w tym celu do rzemieślnika, zwanego w ówczesnej nomenklaturze prywaciarzem, np. do krawca. Krawiec cierpliwie słuchał, czego klient oczekuje, pokazywał kilka wzorów kroju i materiału, brał niezbędne miary i po pewnym czasie przynosił zamówiony garnitur. Jeżeli okazało się, że rękawy są za długie lub marynarka marszczy się na plecach, wprowadzał niezbędne poprawki. W efekcie klient otrzymywał taki garnitur, jaki chciał. Owszem, kosztował on więcej niż "garnitur z półki", ale za to klient miał pełną satysfakcję z otrzymanego produktu.

Klient, który zamierza wdrożyć u siebie system informatyczny, ma do wyboru dwa rozwiązania, podobnie jak klient, zamierzający kupić garnitur. Może wybrać system "z półki" lub zbudować nowy na własne potrzeby.

Informatyka jednak nie jest tak prostą dziedziną, jak krawiectwo (z całym szacunkiem dla krawców). Wśród opinii wyrażanych przez niezależnych analityków rynku informatycznego można spotkać się z oceną, że w przypadku wdrażania systemów gotowych 30% kosztów użytkownik poświęca na zakup systemu, a pozostałe koszty związane są z analizą potrzeb i wdrożeniem. Podobne proporcje są w przypadku budowy systemu na własne potrzeby: ok. 30% kosztów poświęca się na budowę i testy systemu. Mamy zatem do czynienia z dwiema stronami zaangażowanymi w doprowadzenie do wdrożenia systemu - zamawiającym i wykonawcą. Przez 30 lat informatyka dopracowywała się kolejnych, coraz doskonalszych metod projektowania i wytwarzania systemów. Już od wielu lat znane i używane są takie metody projektowania, jak analiza wymagań, modelowanie danych czy procesów. W latach 90. pojawiły się kolejne, doskonalsze metody: modelowanie obiektów użytkownika, prototypowanie, analiza obiektowa i projektowanie obiektowe. Wszystkie te rozwiązania służą jednemu celowi - zaprojektowaniu systemu w taki sposób, by spełniał oczekiwania użytkownika.

Skoro jest tak dobrze, to czemu jest tak źle?

Wielu czytelników może zapewne pokazać więcej projektów nieudanych niż zakończonych powodzeniem. Przyczyn niepowodzeń może być wiele: niewłaściwie zaplanowany budżet projektu, źle określony cel i zakres systemu, uwarunkowania polityczne, brak wykwalifikowanej kadry menedżerskiej lub technicznej i wiele innych. Chciałbym skupić się na jeszcze innym, być może najważniejszym, kryterium sukcesu - umiejętności nawiązania porozumienia między zleceniodawcą a wykonawcą.

Iluzja współpracy

Znane powiedzenie "klient - nasz pan" jest dewizą wszystkich solidnych rzemieślników. Umiejętność słuchania życzeń klienta połączona z doświadczeniem i zdolnością proponowania rozwiązań, które spełniają jego oczekiwania, daje gwarancję sukcesu, pod warunkiem że rzemieślnik potrafi wykonać to, co z klientem uzgodnił.

W przypadku systemów informatycznych współpraca wykonawcy z klientem powinna mieć tym większy zakres, im większa jest złożoność problemu.

Głównym czynnikiem decydującym o sukcesie lub porażce jest zdefiniowanie odpowiedniej struktury organizacyjnej projektu. Kierownicy projektów z reguły wiedzą, jak powinien być zorganizowany zespół wykonawcy, mało kto przywiązuje jednak wagę do zbudowania odpowiednich struktur organizacyjnych po stronie klienta. Znam kilka takich projektów, w których brak takiej struktury skutecznie uniemożliwiał realizację projektu zgodnie z harmonogramem. Najczęstszym skutkiem niewłaściwej organizacji jest brak czasu przedstawicieli klienta na współpracę z wykonawcą. Wszyscy są zajęci pracami bieżącymi i niewielu, oprócz prawdziwych pasjonatów, jest w stanie odpowiednio zaangażować się w definiowanie wymagań i odbiór poszczególnych dokumentów projektowych. Bardzo często trafiają one do różnych ludzi, zależnie od tego, kto aktualnie ma czas lub kogo udało się zmusić do pracy na rzecz projektu. Naturalną reakcją jest brak zaangażowania lub "symulowanie zaangażowania", które przejawia się ciągłym zgłaszaniem uwag i wymagań, często sprzecznych z uwagami innych pracowników klienta. Symulowanie zaangażowania jest najprostszym sposobem zabezpieczenia się przed oskarżeniem o brak zaangażowania lub akceptowanie złych rozwiązań zaproponowanych przez wykonawcę. W konsekwencji pracownicy klienta nie czują się odpowiedzialni za tworzony system.

Powołanie zespołu po stronie klienta jest jednym z czynników, które pozwolą na nawiązanie porozumienia między obiema stronami kontraktu. Zespół taki może być lustrzanym odbiciem zespołu wykonawcy i powinien aktywnie uczestniczyć w definiowaniu wymagań i akceptacji proponowanych rozwiązań. Powinien też mieć kierownika odpowiedzialnego przed swoją firmą za powodzenie projektu. Ponadto oba zespoły powinny stworzyć jeden duży zespół projektowy, który ma jednego kierownika (najczęściej jest to kierownik ze strony wykonawcy lub zleceniodawcy). Doświadczony kierownik łatwo zauważy, czy zespół projektowy ma motywację i tzw. wizję aplikacji. Zespół bez motywacji do pracy tworzy kolejne dokumenty, które mają wymaganą liczbę stron, ale nie zawierają oczekiwanych treści.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200