„Projekt IT”

Data: 2012-06-08
Autor: Sebastian Konkol
„Projekt IT”

W ostatnim czasie miałem przyjemność uczestniczyć w II Forum Kierowników Projektów IT, a nawet prowadziłem stolik ekspercki na temat komunikacji w projekcie. Było bardzo ciekawie, ale podczas tego forum naszły mnie przemyślenia jakby nie licujące z tematyką i majestatem tego wydarzenia. Otóż mam wątpliwości co do instytucji projektu IT. I to poważne. Trochę nie wiem, jak z tego wybrnąć, ale może rozgorzeje jakaś dyskusja poniżej tego wpisu i okaże się, że jestem w karygodnym błędzie. Tym niemniej, na teraz uważam, co następuje.

Zaczynając od początku, projekt ma sens w sytuacji, w której niezbyt wiele jest wiadome, nie mówiąc już o tym, że znikomą część wiedzy o przedmiocie projektu można uznać za pewnik. „Projekt IT” zaczyna się jednak wtedy, kiedy wszystko (w znaczeniu powodu, uzasadnienia, celu i zakresu projektu) jest już jasne niemalże jak Słońce. Już słyszę oburzone głosy, że przecież wymagania mogą się zmienić. Tylko jak porównać skalę konsekwencji „zmiany wymagań na system” z konsekwencjami negatywnej weryfikacji nowego produktu dokonanego przez rynek w ramach projektu NPD lub startup’u, to największe możliwe „zagrożenie” projektu IT, zmiana wymagań, wypada bardzo blado. „Projekt IT” nie jest stawiany przed istotnymi niewiadomymi.

Można postawić rewolucyjną tezę, że „projekt IT” to jedynie zespół zadaniowy i to bezzasadnie nadmuchany. Prawda jest bowiem taka, że nie spotkałem jeszcze w przyrodzie projektu IT, takiego prawdziwego, który miałby samodzielne uzasadnienie i cel biznesowy – nie biznesawy, ale prawdziwy, biznesowy. Jakoś zawsze Wielkiemu Projektowi IT towarzyszy jakiś projekt biznesowy, ale zawsze przychody generuje jakiś projekt biznesowy, a koszty – Wielki Projekt IT. W czasie wspomnianego II Forum wsłuchiwałem się w zdania niektórych kierowników projektów IT, którzy z powagą w głosie mówili, że nie do nich należy dbanie o uzasadnienie biznesowe – do nich należy zbudowanie systemu. Jeśli się nie mylę, to wykonanie jakiejś pracy współtworzącej ostateczny produkt projektu to zadanie zespołu zadaniowego w projekcie. Całe to zamieszanie z „projektem IT” musimy chyba zacząć nazywać właściwie. „Projekt IT” nie miewa uzasadnienia biznesowego.

Kolejną, socjologicznie bardzo ciekawą, cechą projektu IT jest (z żelazną konsekwencją) dzielenie świata na dwie części linią demarkacyjną: biznes kontra IT, zamawiający kontra wykonawca, zawsze jacyś oni i my. Ciekawe jest to, że projekty IT zawsze charakteryzują się konfliktem, wbudowanym na stałe w struktury zarządzania i metody pracy oraz na poziomie chemii mózgu każdego „rasowego” kierownika projektu IT. Mając w tle dowolną metodę zarządzania projektem, w której zawsze najwięcej mówi się o zespole, integracji, współpracy, komunikacji itp., projekt IT jest – delikatnie rzecz ujmując – nieco nieprzystający do tych metod. „Projekt IT” opiera się na istnieniu konfliktu, nie integracji.

Jeden cytat z wypowiedzi Dumnego z Siebie Kierownika Projektu IT wbił mi się w pamięć dość mocno. Zapytany o to, co jest celem projektu IT odpowiedział, że jest nim „zrobienie systemu jak najszybciej, przy angażowaniu jak najmniejszych zasobów, żeby jak najlepiej zarobić, czyli najbardziej standardowo, jak się tylko da”. Pominę milczeniem „jak najlepiej zarobić”. Cała reszta to jednak definicja standaryzacji procesu, w którym wszystko ma być wykonane dokładnie zgodnie z wytycznymi, a nie projektu, w którym – z definicji – trzeba najpierw opracować i dostosować do uwarunkowań sposób realizacji wszystkiego i wszystkich działań. „Projekt IT” jest bardziej fabryką niż podróżą w nieznane.

Zasłyszałem także coś na pograniczu herezji: celem projektu biznesowego jest wdrożenie systemu informatycznego. Tchnie to już paranoją, bo skoro wykonanie pracy specjalistycznej (stworzenie i wdrożenie systemu informatycznego) jest nazywane projektem i to biznesowym, to czym się zajmuje „projekt IT”?

Na moje wyczucie, nie istnieje w przyrodzie nic takiego, jak projekt IT – to taki jednorożec, albo Yeti – powszechnie wierzy się, że coś takiego istnieje, ale nikt tego nigdy nie widział. Od dziesięcioleci istnieją i są doskonalone metody zarządzania wytwarzaniem oprogramowania. Od wodospadu przez iteracje do żwawych metod, wszystkie one opisane są procesowo. To niemalże algorytmy postępowania krok po kroku, obejmujące zarówno zadania, dokumentację jak i psychotechniki rozwiązywania problemów. Co tu jest niewiadomą? Że się mogą zmienić wymagania?

Nie ma czegoś takiego, jak „projekt IT”.

Pozostaw komentarz