Historia jednego projektu

Jeśli dostawca i odbiorca systemu informatycznego pozostają przy intuicjach i dobrych chęciach, nie sprecyzując, co uważają za dobrze wykonany projekt, przedsięwzięcie skończy się niepowodzeniem i wzajemnymi urazami.

Jeśli dostawca i odbiorca systemu informatycznego pozostają przy intuicjach i dobrych chęciach, nie sprecyzując, co uważają za dobrze wykonany projekt, przedsięwzięcie skończy się niepowodzeniem i wzajemnymi urazami.

Moja firma przekonała się o tym, realizując projekt dla jednej z ważnych polskich instytucji finansowych, projekt, który został opłacony przez zagraniczny fundusz pomocowy. Obie strony popełniły błędy wynikające raczej z ubogiego doświadczenia i z naiwności, a nie ze złej woli czy braku merytorycznych kompetencji. Dodatkowym czynnikiem komplikującym sytuacje były następujące fakty: z inicjatywą zbudowania systemu informatycznego nie wyszedł przyszły użytkownik, a finansował projekt jeszcze ktoś inny. W ten sposób od początku nasz kontrahent nie musiał czuć się zobowiązany do wykonania wszystkiego, aby projekt udał się.

Nie mogę jednak powiedzieć, że nie zależało mu na skomputeryzowaniu swojej działalności. Wprost przeciwnie. Inaczej jednak wyobrażał sobie współpracę z dostawcą systemu i chciał budować system w inny sposób, niż jest to możliwe. Również nasza firma popełniła błąd, nie biorąc poważnie różnicy między tymi wyobrażeniami a tym, jakie są wymogi prowadzenia projektu oraz nie uzgadniając na samym początku, co kto rozumie pod sformułowaniami "dobry projekt" i "zakończenie projektu".

Grzechy niekompetencji

Nasza firma wygrała przetarg m.in. dlatego, że bardzo dobrze znała Fox Pro. W dokumentacji przetargowej umieszczony został wymóg zbudowania systemu na tym oprogramowaniu. Po prostu główny informatyk tej instytucji pewnie czuł się w Fox Pro. Od początku sądziliśmy, że nie jest ono wystarczające i odpowiednie dla tej instytucji, ale nie perswadowaliśmy tego. Po pierwsze, było to bezcelowe, gdyż rozwiązanie to stanowiło gwarancję bezpieczeństwa i użyteczności dotychczasowych szefów działu informatycznego. Po drugie, naszym celem było wygranie przetargu, a nie pouczanie klienta. Teraz myślę, że było to krótkowzroczne. Aprobując takie rozwiązanie, skazywaliśmy się na niepowodzenie w sensie merytorycznym, a zatem i na niezadowolenie klienta. Nie poinformowany w porę o błędnych założeniach, klient uważa, że błędy zostały popełnione później - przez realizującego projekt, a nie przez osoby tworzące wymagania systemu.

Mimo że specyfikacja budziła pewne wątpliwości - potraktowane przez nas niewystarczająco poważnie - to wykonana już w ramach kontraktu analiza potrzeb w pełni ujawniła, że instytucja potrzebuje jednak czegoś o wiele większego, niż zapisano w specyfikacji i do czago nas zobowiązano. Zinterpretowaliśmy to w ten sposób: my robimy prototyp, z którego później wyrośnie prawdziwy system. Ostatecznie jednak zrobiliśmy podstawowy błąd: nasza pasja inżynierska zwyciężyła i w projekcie do realizacji zapisaliśmy znacznie więcej niż wynikało z obowiązującego nas kontraktu. Po prostu tylko tak można było postąpić zgodnie ze sztuką naszego zawodu. Nasz klient to zaaprobował. Przystąpiliśmy do pracy.

Sojusznicy i wrogowie

Dyrektor informatyzowanej przez nas instytucji przyglądał się za granicą, jak systemy informatyczne funkcjonują informatyka w podobnych instytucjach. Polskich doświadczeń nie ma, ponieważ firma ma charakter pionierski w naszym kraju. Z tych wizyt dyrektor odniósł wrażenie, że tam szef instytucji naciskał stosowny klawisz komputera i pojawiały się na ekranie odpowiednie dane, wykresy, analizy. On też chciał mieć taki system. Jednak nie uświadamiał sobie, że taki system budują wspólnie z informatykami przyszli użytkownicy, że to właśnie ci drudzy muszą określić wymagania systemu. Nie chciał też przyjąć do wiadomości, że system informatyczny spełni swoje zadanie tylko w dopasowanej do niego strukturze organizacyjnej, a więc że te zmiany należy przeprowadzić. Dyrektor sam uważał się za wybitnego fachowca i nie słuchał naszych podpowiedzi. Teraz widzę, że powinniśmy powołać komisję, aby ta autorytatywnie potwierdziła nasze sugestie.

Pełnomocnikiem zarządu do odbioru naszego projektu był główny informatyk. W swojej dziedzinie był dość kompetentny, jednak jego wiedza nie wykraczała poza sprzęt i oprogramowanie, a jedynie w niewielkim stopniu dotyczyła zagadnień organizacji i zarządzania. Jednak nawet ta wiedza nie mogła być wykorzystana ze względu na jego niskie usytuowanie w hierarchii instytucji i brak wyobrażenia o prowadzeniu dużych projektów. Do zespołu oceniającego wykonanie systemu (zespół wdrażający nawet nie powstał) zapraszał kierowników różnych działów, ale oni ograniczali się do potwierdzenia, czy w projekcie uwzględniono to, co praktykowali od dawna. Z pewnymi wyjątkami zupełnie nie interesowali się tym, co nowego informatyka może wnieść w ich pracę. Krój czcionek i wygląd okien to był szczyt ich inicjatywy. Tylko nieliczni kierownicy mieli świadomość, że projekt wymaga zmian w instytucji, a przede wszystkim uporządkowania spraw organizacji, odpowiedzialności oraz gospodarki finansowej. Nie chcieli jednak "wychylać się".

Konflikt i finał

Kiedy dyrektor uświadomił sobie, że stawiamy mu wymagania, formułujemy zalecenia organizacyjne, że informatyzacja to nie tylko zainstalowanie komputerów i oprogramowania, atmosfera wokół kontraktu stała się zimna, żeby nie powiedzieć - wroga. Dyrektor oczekiwał korzyści z systemu, czyli że będzie on zaspokajał jego potrzeby informacyjne. Uważał jednak, że system spełni te oczekiwania bez wkładu jego samego i innych kierowników, bez sprecyzowania, co właściwie chcą uzyskać. Innymi słowy w trakcie realizowania przedsięwzięcia zarząd coraz bardziej rozumiał, że z informatyki może mieć ogromną korzyść, i chciał ją mieć. Przyjął też za dobrą monetę nasz rozszerzony ponad specyfikację kontraktową projekt. My jednak nie mogliśmy go wykonać, ponieważ zarząd nie realizował naszych zaleceń organizacyjnych i nie opracował nieinformatycznego wsadu do systemu. Inna sprawa, że zarząd nie miał kompetentnego partnera w osobie własnego informatyka, który przekładałby wizje prezesów na rozwiązania informatyczne i organizacyjne.

Różnica wiedzy i świadomości zarządu w czasie zawierania kontraktu i w chwili odbioru oprogramowania oraz nasze błędne postępowanie przy analizie przed rozpoczęciem projektu, czyli niesprecyzowanie z zarządem wymagań systemu, stały się przyczyną poważnych nieporozumień. Nie można powiedzieć, że nasz projekt był pochopny. To wymagania odbierającego odbiegały od kontraktu i projektu. Byliśmy w stanie zrozumieć, że odbierający sporo się nauczyli, że wymagania wobec systemu są dużo większe niż w momencie zawierania kontraktu, a nawet w chwili zatwierdzania projektu, ale nie mogliśmy się zgodzić na permanentne wykonywanie systemu w ramach nie rozszerzanego kontraktu.

W tym momencie pojawiło się pytanie, jaki projekt ma być odebrany jako zakończona praca: czy ten zgodny ze specyfikacją kontraktową czy ten, który tkwi w wyobrażeniach zarządu i częściowo w naszych propozycjach? Zgodnie z kontraktem: nasz system miał stanowić początek prawdziwej informatyzacji. Dalszy ciąg wymagał następnych kontraktów i funduszy.

Ostatecznie o odebraniu systemu i zapłaceniu nam za tę pracę przesądziła postawa dysponenta pieniędzy, uznającego, że system jest zgodny ze specyfikacją, oraz ocena niezależnej komisji ekspertów, która również oceniła, że - po dopełnieniu pewnych spraw technicznych - wywiązaliśmy się z zobowiązań kontraktowych. Niemniej klient nie używa naszego systemu.

Piotr Kulesza jest konsultantem w firmie Computer Consulting.

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

TOP 200