Sprzedawcy srebrnych kul - częśc 3 - Alternatywy 4

Gdy się ciągle żyje nad brzegiem przepaści, już się jej nie dostrzega.- P. Negri

Gdy się ciągle żyje nad brzegiem przepaści, już się jej nie dostrzega.- P. Negri

Z racji zajmowania się problematyką doskonalenia procesów wytwórczych oprogramowania los często stawia mnie w roli "spowiednika" kierowników projektów IT. Powody tych szczerych rozmów są różne. Pomoc w uruchomieniu projektu, weryfikacja stosowanych technik zarządzania, system jakości, problemy z zespołem. Tajemnica spowiedzi to rzecz święta, warto jednak pokusić się o ogólną analizę stanu rzeczy w projektach IT. Trzeba mieć nadzieję, że uda się uratować kilku nieszczęśników, zanim włożą swoje "wrotki", a audyt projektu będzie dla nich "ostatnią posługą".

Grzech "Dominacji"

Każdy informatyk ma go na sumieniu. Chodzi o czerpanie satysfakcji z manipulowania nieświadomymi niczego klientami/użytkownikami z departamentów biznesowych. Dominacja informatyków pojawia się najczęściej w organizacjach, które przechodzą "pierwszą poważną informatyzację". Kiedy komputer i system informatyczny są czymś nowym dla zwyczajnych ludzi, nieuniknione jest postrzeganie grupy informatyków jako "szafarzy wiedzy tajemnej" i poddawanie się bez zastrzeżeń ich zaleceniom. Mało kto z nas potrafi oprzeć się pokusie wykorzystania szczerego zaufania użytkowników i sięgnięcia w obszarze IT po "władzę absolutną". Klient zgłasza problem, informatyk pryncypialnie ustala termin oddania projektu i znika pod "czapką niewidką", aż do momentu, gdy system będzie gotowy. A jeśli system nie jest taki jak chciał klient, spóźnił się o dwa miesiące i kosztował o połowę drożej? Informatycy mają swoje sposoby, by wszystko wytłumaczyć systemowo i holistycznie z uwzględnieniem immanentnej podatności organizacji na złożoność technologii i procesów programowych! Szary użytkownik nie ma żadnych szans w starciu ze specjalistą, prawda?

Grzech "Obłudy"

Sprzedawcy srebrnych kul - częśc 3 - Alternatywy 4

Wagi czynników decydujących o sukcesie projektu IT

W organizacjach, które przeszły swoją pierwszą informatyzację, proces wdrażania lub wytwarzania systemów siłą rzeczy wkracza w fazę dojrzałą, która charakteryzuje się większą dyscypliną i sformalizowaniem. Procesy formułowania wymagań, zarządzania projektem i jakością są nadal w rękach informatyków, ale użytkownicy częściej są zapraszani do współpracy. Są to przeważnie prace najbardziej nie lubiane przez informatyków, jak specyfikacja wymagań, testowanie i dokumentowanie systemu. Niewielu klientów potrafi odkryć, że mimo znacznego zaangażowania i udziału w ważnych fazach projektu, w istocie nadal są niewolnikami informatyków. Projekty są zarządzane i finansowane przez działy IT, a o kształcie systemu decyduje zespół fachowców - inżynierów oprogramowania. Klient jest jedynie "podwykonawcą", a formalizacja relacji służy zabezpieczeniu interesów informatyków - "podpiszcie wymagania, bo przez następne trzy miesiące nie przyjmujemy reklamacji!".

Grzech "Zaniechania"

Lata 80. to w zarządzaniu okres "reformacji". Krytyce dotychczasowych nieefektywnych technik zarządzania towarzyszą ruchy odnowy związane z koncepcjami reengineeringu, kompleksowych systemów jakości i organizacji uczących się. Panuje ogólna tendencja do rewizji procesów organizacyjnych, także IT. Zarządy firm stawiają niewygodne pytania, na które informatycy nie potrafią znaleźć prostych odpowiedzi. Czy i w jakim stopniu nasze systemy są dopasowane do potrzeb biznesowych, jak wpisują się w realizację długofalowych strategii, jaki jest poziom zwrotu z inwestycji w obszarze IT, czy dzięki komputerom lepiej obsługujemy klienta itp.

Role się odwracają. Władza wraca w ręce klientów biznesowych, a działy IT traktuje się jako wewnętrzne biura usługowe i centra kosztów, które należy uważnie rozliczać zgodnie z zasadą "każdy koszt większy od zera jest podejrzany". Jeśli informatyka w organizacji może być traktowana jak usługa, to znaczy, że można ją wycenić i określić wpływ na obszary biznesowe na podstawie wskaźników ekonomicznych, takich jak ROI, miary ryzyka i całkowite koszty posiadania. Projekty, które nie spełniają powyższych kryteriów, są kasowane. Działy biznesowe wreszcie biorą odwet na informatykach, ingerując w najdrobniejsze aspekty projektu, uzasadniając to prawem właściciela inwestycji do redukcji kosztów nie przynoszących wartości (obcinając np. wydatki na narzędzia do modelowania czy automatyzację testów).

Cnota "Partnerstwa"

Przedstawione trzy typowe sytuacje charakteryzują większość środowisk realizacyjnych współczesnych projektów IT. Są one wynikiem zastanej bądź celowo wytworzonej kultury organizacyjnej, będącej pochodną określonego układu sił i wpływów. Kierownik projektu, chcąc odnieść sukces, musi przede wszystkim zmierzyć się z kulturą organizacji. Niestety, zmienić ją bardzo trudno, a to często jest równoznaczne z porażką już na starcie projektu. Można zmarnować mnóstwo pieniędzy na szkolenie i certyfikacje, systemy motywacyjne i premiowe, poprawę procesów projektowych itd. W realnym świecie o tym, czy projekt się uda, decydują tylko i wyłącznie rodzaj i jakość relacji między IT a obszarem biznesowym organizacji. Jeśli kierownik projektu nie decyduje ani o polityce jakości firmy, ani o wydatkach, ani o tym, kogo zatrudnia do projektu, ani o zakupie potrzebnych mu narzędzi, ani o harmonogramie i kamieniach milowych, ani o doborze właściwych standardów realizacji projektu, to znaczy, że wyznaczono mu zaszczytną i odpowiedzialną rolę "kozła ofiarnego".

Na poparcie moich słów przytoczę wyniki badań Standish Group, w których poszukiwano kluczowych czynników decydujących o sukcesie projektu. Z wyników badań prowadzonych nad setkami tysięcy amerykańskich projektów IT przedstawionych na rysunku wynika dobitnie, że doświadczenie kierownika projektu ma trzeciorzędne znaczenie. Najważniejszy jest świadomy swoich celów, priorytetów i ograniczeń sponsor projektu, a po nim użytkownik traktujący informatyków jak partnerów w osiąganiu sukcesu biznesowego środkami IT. Budowanie zrozumienia powyższych faktów jest pierwszym krokiem na drodze poprawy jakości współczesnych projektów informatycznych.

Tomasz Byzia jest dyrektorem ds. rozwoju firmy Premium Technology.

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

TOP 200