Wnioski z bajki o królu

Wdrażanie na wczoraj. Praktyka dowodzi, że źródłem wszelakiego zła w realizacji projektów informatycznych są najczęściej napięte terminy. Ten czynnik rodzi często największe problemy w relacjach klient-dostawca.

Wdrażanie na wczoraj. Praktyka dowodzi, że źródłem wszelakiego zła w realizacji projektów informatycznych są najczęściej napięte terminy. Ten czynnik rodzi często największe problemy w relacjach klient-dostawca.

W artykule "Był sobie król" opowiedziałem trzy bajki, przy czym starałem się, aby ta ostatnia dosyć mocno przypominała rzeczywistość. W bajkach, jak to w bajkach, było trochę przesady, trochę naciągania. Chodziło o uwypuklenie pewnych ważnych kwestii. Teraz nadszedł czas, aby porozmawiać trochę poważniej i obiektywniej. Spróbujmy podsumować, jakie problemy próbowałem zasygnalizować w moim poprzednim artykule.

  1. Przy dużych, intratnych kontraktach dostawcy niejednokrotnie zgodzą się na bardzo niekorzystne warunki. Podejmują to ryzyko, bo liczą, że: między paragrafami uda im się zaszyć brak odpowiedzialności, jak już się zahaczą, to trudno będzie się ich pozbyć, więc ewentualne straty poniesione w pierwszym projekcie odbiją sobie w trakcie utrzymania systemu, na który będą mieli de facto monopol, jeżeli napiszą go wystarczająco źle.
  2. Wbrew pozorom, przedstawiciele klienta nie są panami sytuacji. Teoretycznie mogą podjąć decyzję o rozwiązaniu współpracy, co dla wielu firm może oznaczać ich koniec. Warto jednak mieć świadomość, że są oni odpowiedzialni przed swoimi zwierzchnikami za czasowe i skuteczne wdrożenie systemów.
  3. Klient często wdraża systemy, które powinny być wdrożone na wczoraj. Rozwiązanie umowy z podwykonawcą - w trakcie trwania projektu - wiąże się z poważnym ryzykiem niedotrzymania terminów.
  4. Publiczne przyznanie się do problemów z poddostawcą, może wpłynąć negatywnie na wizerunek klienta.
  5. W wielu firmach wytwarzane są standardy komunikacji, które sprzyjają ukrywaniu negatywnych informacji. Jest to spowodowane: dbaniem managerów o: swoją reputację przed swoim przełożonymi; wytworzenie propagandy sukcesu, która staje się stymulatorem i presją dla innych pracowników. Skutkiem takiej komunikacji jest: zmniejszenie szansy na uczenie się na własnych błędach; wyrabianie wśród pracowników fałszywego przekonania, co do realności terminów i nakładów potrzebnych do rzetelnego wykonania systemów; spadek zaufania do kierownictwa.

Znaleźć potrzebny czas

Praktyka dowodzi, że źródłem wszelakiego zła są najczęściej napięte terminy. To każdy instynktownie czuje i każdy jednocześnie unika powiedzenia tego wprost. Remedium jest oczywiste - unikać nierealnych terminów. To jednak nie jest takie proste. Jeżeli wszyscy wokół zaniżają swoje wyceny, to chcąc nie chcąc też musimy w jakimś stopniu grać w tę grę albo wypadniemy z rynku.

Punkt pierwszy nie wymaga, moim zdaniem, żadnych dodatkowych wyjaśnień. Czy jednak klient jest rzeczywiście górą w relacji z dostawcami? Zagadnienie warto przeanalizować na dwóch płaszczyznach - pojedynczych osób, odpowiedzialnych za współpracę z dostawcami i na poziomie całej organizacji.

W realnym świecie nadworny informatyk, czyli szef IT po stronie klienta, wbrew pozorom, wcale nie jest panem sytuacji. Ma do dyspozycji jakiś budżet, wyznaczone - teoretycznie nieprzekraczalne - terminy i musi się z realizacji zadań rozliczyć przed przełożonym. Tego zaś może nic nie obchodzić, że wszystko się posypało, bo poddostawca był zły. Trzeba było wybrać lepszego. Reprezentant klienta ryzykuje przyznając się, że coś jest nie tak, nawet jeżeli ma poddostawcę, na którego może zwalić winę. Dostawcy z zasady są jednak mistrzami w dbaniu o to, aby ich wina nie była ewidentna. Żyją z przekonywania klientów, że to co dostarczyli, to - z formalnego punktu widzenia - jest dokładnie to, czego klient zażądał. Co więcej, często bywa tak, że osoby negocjujące kontrakt ze strony firm dostarczających rozwiązania IT mają dobre wejścia na poziomie przełożonych nadwornego informatyka. I są naprawdę fachowcami w przekonywaniu, że ich ludzie zrobili wszystko dobrze. I jeżeli dojdzie do takiego momentu, że będzie się szukało winnych, dołożą starań, aby wina spadła na szefa IT.

No i jeszcze kwestia czasu. Wyobraźmy sobie sytuację, że firma (np. bank) wie, że musi wdrożyć jakiś system w 2014 r. Więc spokojnie sobie planuje wdrożenie pierwszej wersji na 2010 r. Tak na wypadek, gdyby, jak coś się nie uda, były jeszcze 4 lata na poprawienie. To kolejna sytuacja spotykana tylko w bajkach. Normalnie bank w styczniu dowiaduje się, że musi coś zaimplementować na grudzień (bo tak zażyczył sobie Regulator), a roboty jest na dwa lata. Jeżeli w sierpniu bank zorientuje się, że wybrany poddostawca nie spełnia jego oczekiwań, to niewiele już może zrobić. Co prawda, w kontrakcie są zapisane kary umowne. Ale co z tego? Czasu nie cofną.

Kontrakt jak małżeństwo

O relacjach przy dużych kontraktach nie powinno się myśleć jak o relacjach klient-ekspedient. Bardziej to przypomina szukanie męża, a potem małżeństwo. W fazie RFP, klient jest taką panną na wydaniu, z dużym posagiem. Wszyscy o nią zabiegają i obiecują jej złote góry. Podpisanie kontraktu jest jak małżeństwo, tzn. klient nie jest już obiektem westchnień, tylko staje się zwykłą żoną, związaną wspólnym losem ze swoimi dostawcami. Rozstanie po pół roku, to nie jest już zwykłe danie kosza. To rozwód. Pełen stresu i komplikacji będących pochodną wzajemnych powiązań, jakie się zdążyły wytworzyć między partnerami.

Jest truizmem mówić, że nie warto brać tych, co robią najtaniej. To każdy niby wie. Zauważyłem jednak, że klienci mają skłonność do wykorzystywania mocnej pozycji do negocjowania nierealnie korzystnych warunków. Dostawca, któremu zależy na kontrakcie może się na wiele zgodzić. Ale nie jest cudotwórcą. Jeżeli czegoś się nie da zrobić w danym terminie, to dostawca też tego nie zrobi. Jeżeli więc w wyniku negocjacji, uda się go skłonić do podpisania wymagającego dla niego kontraktu, to efekt wcale nie będzie taki, że zrobi on co tylko może, aby dostarczyć na czas jak najlepsze oprogramowanie. "A dlaczego?" - zapyta czytelnik. Czyż nie zadziała tu niewidzialna ręka gospodarki rynkowej, która wywyższa bardziej efektywnych kosztem partaczy? Może i zadziała, ale jeżeli ktoś pamięta smak wędliny sprzed 20 lat to jedząc dzisiejsze uświadamia sobie, że ta ręka rynku niekoniecznie promuje jakość.

Kluczem do zrozumienia, dlaczego to wszystko nie chce się samo dobrze wyregulować, jest uświadomienie sobie, że konkretne role w projekcie nie są wykonywane przez jakieś abstrakcyjne byty, tylko przez ludzi. Ludzie mają ambicje i operują w strukturze wzajemnych relacji i powiązań. Spróbujmy wejść w skórę managera, od strony dostawcy, takiego projektu z wyśrubowanymi terminami i budżetem. Właśnie wygrano projekt, co ogłoszono w firmie jako wielki sukces. Realizacja tego projektu jest dla firmy wielką szansą na dalsze kontrakty, a dla managera następnym krokiem w karierze. Porażka projektu może oznaczać klęskę firmy i na pewno nie pomoże managerowi w karierze. W takiej sytuacji manager nie może ot tak powiedzieć, że projekt nie da się zrealizować. Ale to, że tego nie mówi, to nie znaczy, że tego nie widzi.

Nasz manager szybko zda sobie sprawę z dramatyczności jego sytuacji i jego celem będzie dostarczenie czegoś, co da mu choć cień szansy na przekonanie klienta, że to jest to, czego chce. Będzie w panice łatał dziury i ratował swoją skórę. I będzie za wszelką cenę dążył do spełnienia warunków kontraktu. "No to super, o to chodzi" - pomyśli czytelnik. Niestety problem polega na tym, że dostarczenie stabilnego oprogramowania a formalne spełnienie warunków kontraktu to nie jest to samo. Dostarczenie stabilnego oprogramowania jest być może priorytetem dla programistów i kierowników niższego, technicznego szczebla. Managerowie szczebla wyższego, niejednokrotnie nie znają się na tym, co robią ich ludzie. Oni widzą projekt z perspektywy kontraktu i faktur, które klient ma podpisać i za nie zapłacić. A ta perspektywa niekoniecznie wytwarza sprzyjające warunki do powstania stabilnego oprogramowania. Jeżeli klient kupuje jacht, a kontrakt jest tak spisany, że podstawą do wystawienia faktury może być patyk unoszący się na wodzie, to klient dostanie właśnie taki patyk. A manager dostawcy ma duże szanse, aby przez zarząd swojej firmy zostać uznanym za bardzo efektywnego.

Urealnienie projektu

Czy to znaczy, że klienci nie powinni negocjować z dostawcami? Nic bardziej błędnego. Apetyty renomowanych firm dostarczających oprogramowanie nie mają granic. I jak rzucimy im hasło "OK, no to powiedzcie ile chcecie za zrobienie tego tak porządnie, a ja zapłacę ile trzeba" to puszczą nas z torbami. Ale nie należy przesadzać. Czując, że dostawca jest gotów dużo zrobić, aby wygrać kontrakt, klient powinien to wykorzystać, ale w rozsądnych granicach. Dostawcy nie są cudotwórcami, terminy nierealne dla klienta są również nierealne dla nich. Klienci przeceniają znaczenie kar umownych, które dają im pozorne poczucie bezpieczeństwa. Pozorne, bo o problemach bardzo często dowiadują się, kiedy już jest za późno i kara umowna niewiele im pomoże.

Warto też sobie odpowiedzieć na pytanie, czy rzeczywiście warto udawać, że coś da się zrobić, kiedy wiadomo, że się nie da. Już nie raz widziałem takie sytuacje. Coś koniecznie musi być zrobione na za miesiąc. Ale to zajmie nie wyjęte trzy miesiące i wszyscy to wiedzą. Ale to musi być na za miesiąc, bo jak nie to się świat zawali. Więc udajemy, że się uda i próbujemy sami bądź dajemy firmie trzeciej, która w nadziei na większy kontrakt, zgodziła się na taki termin. I oczywiście to nie jest gotowe za miesiąc. I nie jest nawet gotowe za trzy miesiące, bo robiąc w wielkim pośpiechu, zrobiliśmy taki bałagan, że będziemy się zbierać przez następne pół roku. Aha, i bardzo często okazuje się, że o dziwo, świat się nie zawalił. Czy nie lepiej byłoby powiedzieć sobie - OK. To musi być na za miesiąc, ale nie będzie. Zastanówmy się, co tak naprawdę da się zrobić i róbmy "nie na wariata" przez trzy miesiące.

Czy można stworzyć takie warunki, aby klient był Panem sytuacji nie tylko w fazie przetargu, ale i po jego rozstrzygnięciu? Moim zdaniem po przekroczeniu pewnej skali projektu (w stosunku do wielkości zleceniodawcy) wzajemne uzależnienie jest nieuniknione. Jedynym ratunkiem jest dołożenie wszelkich starań, aby wybrać dostawcę, który będzie jak najlepszym i rzetelnym partnerem. Jeżeli już takiego mamy, zastanówmy się zanim go wymienimy na kogoś innego, tylko dlatego, że jest dużo tańszy. Trzeba jednak dodać, że dobrzy dostawcy szybko wyczuwają zaufanie klienta i jak klient się od nich za mocno uzależni, to stawki zaczynają szybko rosnąć. Nie ma lekko…

Nie przeceniajmy znaczenia reputacji dostawcy. To, że nie słychać nigdzie o tym, że dostawca zawalił jakiś ważny projekt, może dowodzić tego, że dostawca rzeczywiście niczego nie zawalił. Ale może też dowodzić tego, że zawalił bardzo ważny projekt tak strasznie, że klient boi się o tym głośno mówić.

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

TOP 200