Udany lub nieudany projekt systemu klient/serwer nie oznacza wyboru na miarę życia lub śmierci, ale może wyraźnie wpłynąć na karierę szefa informatyki przedsiębiorstwa. Jak pokazują badania statystyczne, ponad 70% projektów jest opóźnionych, przekracza przewidziane koszty lub nie spełnia oczekiwań użytkowników.

Te dane nie muszą znaczyć, że już na początku projektu należy się poddać; oznaczają one jedynie, że jak każdy projekt informatyczny, także projekt systemu klient/serwer powinien być profesjonalnie zarządzany.

Najczęściej sądzimy, że technologia uratuje nieudany projekt? Badania pokazują, że zwykle nie ma to miejsca. Podobnie nie ma korelacji między elegancją techniczną rozwiązania a wynikiem końcowym. Istnieje jednak ścisła korelacja między sukcesem projektu a poziomem zarządzania.

Co więc ma robić szef projektu klient/serwer? Ustalić ścisłe zasady i twardo się ich trzymać. Poniżej podajemy siedem zasad dobrego prowadzenia projektów, które wprawdzie nie gwarantują jego sukcesu, ale dają większą szansę pozytywnego zakończenia.

Zasada 1: Poznaj główne przeszkody

Badania Deloitte & Touche, przeprowadzone wśród głównych informatyków dużych przedsiębiorstw określiły osiem głównych przeszkód w udanej realizacji projektów klient/serwer (patrz wykres).

Jeżeli także w naszym projekcie rozpoznamy te same przeszkody i nauczymy się im przeciwdziałać, mamy szanse na sukces.

Zasada 2: Nie usiłuj dowieść, że projekt przyniesie natychmiastowe korzyści finansowe

Tylko nieliczni szefowie projektów klient/serwer mogą sobie pozwolić na luksus natychmiastowego wyłączenia mainframa i pokazywania, że dzięki temu osiągnęli istotną obniżkę kosztów operacyjnych. A mimo to większość dostawców technologii klient/serwer usiłuje tak właśnie argumentować.

Jeżeli szefowie firmy zgodzili się na rozpoczęcie projektu posługując się taką właśnie argumentacją, trzeba jak najszybciej wyprowadzić ich z błędu.

Muszą zrozumieć, że termin "klient/serwer" nie jest synonimem "downsizingu". Jeżeli policzy się koszty dodatkowego oprogramowania, potężnych stacji roboczych i serwerów oraz koszty konsultacji zewnętrznych, małe są szanse, że natychmiast pojawią się oszczędności.

Firma Deloitte & Touche określiła pięć powodów, dla których firmy podejmują realizację projektów klient/serwer:

* pozwala na radykalną zmianę sposobu prowadzenia działalności

* zwiększa wydajność produkcyjną użytkownika końcowego

* ułatwia akcepatację systemu przez użytkownika

* ułatwia szybkie opracowanie aplikacji

* optymalnie wykorzystuje dostępne technologie.

Jak widać, żaden z tych powodów nie dotyczy obniżenia kosztów.

Zasada 3: Zarządzaj dobrze współpracą

Projekt klient/serwer wymaga ścisłej współpracy nie tylko ludzkiej, ale także technologicznej, co wymusza skoordynowany wysiłek techniczny specjalistów z wielu dziedzin informatyki.

Ponieważ typowy projekt wymaga łączenia wielu różnych pakietów oprogramowania, potrzebne będą kwalifikacje ludzi znających aplikacje na biurko, problemy sieciowe, administrowanie bazami danych, problemy komunikacji, zagadnienia bezpieczeństwa oraz niezbędna będzie dobra współpraca z użytkownikami końcowymi.

Trudności w zarządzaniu tak niejednolitym zespołem mogą być pogłębione przez fakt, że szef projektu niekoniecznie będzie szefem wszystkich osób, niezbędnych do sukcesu projektu.

Proszę porównać ten przypadek z prowadzeniem projektu na mainframie, gdzie należy martwić się jedynie o poprawność kodu. Zawsze można było liczyć na jedno, stabilne środowisko opracowania aplikacji, w którym programiści systemowi dbali o dostarczanie odpowiedniej pojemności pamięci i miejsca na dysku; administrator bazy utrzymywał w dobrym stanie bazę przedsiębiorstwa a obsługa techniczna dbała, aby to wszystko działało jak należy.

I wszystko to działało bezbłędnie sporo czasu przed przystąpieniem do jakiegokolwiek projektu programistycznego!

Zapewne okaże się, że zespół do opracowania aplikacji klient/serwer musi zajmować się konfigurowaniem pamięci na PC, obciążeniem sieci, protokołami komunikacyjnymi, zgodnością różnych wersji programów na PC itd. Problemy te będą szczególnie widoczne w przypadku projektu pilotowego i wszystkie muszą być dobrze rozwiązywane, jeśli projekt ma się udać.

To szczególne środowisko pracy wymaga aktywnego zarządzania, dobrej komunikacji i współpracy. Zadania i zakres odpowiedzialności muszą być ściśle zdefiniowane, zespół powinien je zaakceptować, a każdy członek zespołu musi wiedzieć, jaki wpływ ma jego praca na poczynania innych osób.

Jeżeli np. specjalista ds. komunikacji musi zmienić sterowniki sieciowe w PC, pracującym jako klient Windows, to może to wpłynąć na sposób konfigurowania pamięci w tym PC i możliwość uruchamiania pewnych aplikacji.

Oprócz beztarciowej współpracy członków zespołu, udany projekt klient/serwer wymaga aktywnego zaangażowania każdego z jego uczestników. Nie wystarczy zaangażowanie typu "Poświęcę temu popołudnie w piątek" lub "Zajmę się tym, jak skończę swoją pracę".

Użytkownicy muszą być przygotowani nie tylko do dzielenia się sukcesem, ale także klęską przedsięwzięcia. Jeżeli sukces projektu nie będzie miał zasadniczego wpływu na ocenę ich pracy i karierę zawodową, nie będzie dostatecznego zaangażowania ani z ich strony, ani ze strony ich szefów.

Zasada 4: Dąż do określenia wymagań ilościowych

Jest to hasło dość popularne, ale szczególnie ważne w projekcie klient/serwer. Biorąc pod uwagę liczbę czynników technicznych, którymi trzeba się zajmować, należy dążyć do określenia prostych i dobrze sprecyzowanych wymagań ilościowych.

"Poprawiony dostęp", "szybsza odpowiedź" czy "łatwość użycia" są pożądanymi cechami systemu, ale nie mogą stanowić wymagań, według których da się ocenić sukces lub klęskę przedsięwzięcia. Należy posługiwać się dobrze sprecyzowanymi oczekiwaniami użytkowników.

Czy użytkownicy oczekują, że dostaną odpowiedź na zapytanie do bazy danych w czasie krótszym od 5 sekund? Czy oczekują, że ten czas będzie dotrzymany o każdej porze dnia i nocy?

Czy oczekują, że system przygotuje faktury w ciągu 3 dni po zakończeniu miesiąca? Czy spodziewają się, że system spowoduje alarm, jeśli poziom zapasów spadnie o 10% w stosunku do ustalonej normy?

Należy dojść do tego, że zarówno użytkownicy, jak i programiści będą myśleć w kategoriach ilościowych, przekształcą te ilości na wymagania projektowe i będą się ich trzymać przez cały czas trwania projektu.

Takie wymagania należy powtarzać do znudzenia, zapisać na plakatach, wywiesić w biurze, wbijać każdemu do głowy, wyśpiewywać przy śniadaniu, nawet wytatuować na czole każdego członka zespołu - jeśli zajdzie taka potrzeba.

Niech nikt nie zapomni, że wszyscy zgodzili się, jak będzie mierzony sukces przedsięwzięcia. Wspólna i ciągła troska o dotrzymywanie wymagań ilościowych, to dobra droga do kontroli zakresu pracy i spełniania oczekiwań użytkowników.

Zasada 5: Planuj złożoność techniczną projektu

W czasach mainframe'a nie trzeba było specjalnie martwić się różnorodnością narzędzi i sprzętu. W przypadku aplikacji klient/serwer trzeba zapewne mieć do czynienia z dwoma lub więcej systemami operacyjnymi, systemami zarządzania bazami danych, pośrednimi warstwami oprogramowania (middleware), protokołami komunikacyjnymi oraz różnorodnym sprzętem sieciowym i komputerami. Dobrze pasuje to do analogii z łańcuchem, który jest na tyle mocny, na ile mocne jest jego najsłabsze ogniwo.

Ocena złożoności technicznej projektu, uwzględniająca ryzyko związane ze skomplikowanymi zależnościami między różnymi czynnikami lepiej pozwoli zarządzać projektem i doprecyzować oczekiwania użytkowników.

Dla projektów klient/serwer należy obliczyć ryzyko techniczne każdego dużego zadania i odpowiednio zaplanować harmonogram prac.

Inna metoda minimalizacji ryzyka polega na starannym dobraniu warstw projektu i dodawaniu ich kolejno po jednej (systemy operacyjne, bazy danych, middleware lub protokół komunikacyjny), upewniając się, że po dodaniu kolejnej warstwy całość działa poprawnie - zanim przejdzie się do następnego etapu. Na przykład - przed dodaniem warstwy Windows - należy przekonać się czy stacje klienckie są w stanie porozumiewać się z serwerem bazy danych.

Dodając oprogramowanie należy upewnć się, że zarówno członkowie zespołu, jak i dostawcy wiedzą, jaką posługujemy się wersją oprogramowania. Pozwoli to uniknąć kłopotów w przyszłości.

Powinniśmy przekazać tę informację dostawcom, aby uświadomić im, że powinni wziąć na siebie część odpowiedzialności za dobre współdziałanie różnych programów, i że nie będzie akceptowane zrzucanie na innych winy za błędy.

Zasada 6: Zrozum motywację partnerów

Różnorodność i złożoność technologii może spowodować, że w firmie nie będzie wszystkich specjalistów niezbędnych do dokończenia projektu. Niezależnie od tego czy pracujemy z konsultantami, czy dostawcami - ważne jest zrozumienie ich motywacji.

Będzie źle jeśli uznają oni nasz projekt jako okazję do przetestowania nowego oprogramowania lub przetrenowania swych pracowników w nowej technologii.

Uzgodniliśmy z konsultantami płacę za czas (i zużyte materiały). Czy została wynegocjowana niezmienna kwota? Przy ustalonej kwocie, konsultant prawdopodobnie zacznie w pewnym momencie przejadać swój zysk. Nie jest to zły kontrakt z punktu widzenia zleceniodawcy pod warunkiem, że ma się ściśle kontrolowany harmonogram i zakres pracy oraz uda się uniknąć jakichkolwiek zmian w projekcie.

Niestety jest to sytuacja występująca rzadko we współczesnym biznesie, zwłaszcza jeśli wykonuje się reengineering działalności całej firmy - jak obecnie czyni to wiele firm.

Wymuszenie na partnerze stałej ceny w zmieniających się warunkach, jest nie tylko nie fair w stosunku do niego, ale także zemści się w końcu na samej firmie. Jeżeli partner - w celu uniknięcia strat finansowych - wycofa się z projektu, to nie obędzie się bez wzajemnych oskarżeń i opóźnienia pracy.

Z drugiej strony, kontrakt polegający na płaceniu za czas i zużyte materiały, nie zachęca do kończenia pracy na czas i w ramach przewidzianych kosztów.

W tych warunkach umowa określająca podział ryzyka jest bardziej odpowiednia. Pozwala uwzględnić zmienność technologii. W razie osiągnięcia zysków dzieli się je w ustalonych proporcjach między obie strony; w razie przekroczenia budżetu projektu - w tych samych proporcjach ponosi się koszty.

Zasada 7: Kontroluj dystrybucję - program powinien dotrzeć do użytkowników

W procesie dystrybucji okazuje się ile wart jest program. Nie ważne jak technicznie doskonały lub elegancki jest system - będzie kompletną klapą, jeśli użytkownicy nie będą chcieli lub nie potrafią go używać.

Przed dystrybucją programu należy dokonać inwentaryzacji umiejętności użytkowników i upewnić się, że wszyscy przeszli szkolenie pozwalające im w pełni wykorzystać nowy system.

Należy upewnić się, że pomoc techniczna jest sprawna, i że jest w stanie wspomóc użytkowników w trudnym, początkowym okresie korzystania z systemu. Jeśli nawet system spełnia wymagania firmy, będzie klapą, gdy użytkownicy nie będą go używać z powodu braku odpowiedniej pomocy. Niech nasz projekt nie spowoduje załamania nerwowego ekipy pomocy technicznej.