ITIL oraz Prince2. Klejnoty koronne brytyjskiego korpo imperium minionej ery.

Wprowadzenie

Jak zapewne z wielu z was moja styczność z tytułowymi metodologiami ograniczała się do tej pory do okazjonalnego odczytania ich na liście wymagań ogłoszeń o pracę na stanowiskach menedżerskich lub czyichś certyfikatów na LinkedIn-ie. Nawet pracując od prawie dekady w korporacjach, nie spotkałem się z sytuacją, w której ktoś bezpośrednio by się do nich odnosił. Mimo pięcia się w górę po szczeblach korpo kariery pozostawały one dla mnie mitycznymi stworzeniami znanymi tylko z drugiej ręki. Pewnie nadal by tak było i żyłbym ciągle w błogiej nieświadomości, gdyby nie wrodzona ciekawość, która kilka dni temu lekko muśnięta nowo odkrytym faktami odnośnie do źródła ich pochodzenia skłoniła mnie do branżowego dokształcenia się na ich temat. Mam oczywiście na myśli to iż obydwie te metodologie zostały sformułowane przez rząd brytyjski. Tak, dobrze przeczytaliście, rząd brytyjski! Osobiście nie mogłem uwierzyć w tę świeżo przyswojoną informację, ale jednocześnie gdzieś w otchłaniach mojej podświadomości coś kliknęło i kilka puzzli logicznych wskoczyło na swoje miejsce. Przecież to tak wiele wyjaśnia! Nagle sztywne ramy korporacyjnego zarządzania wysokopoziomowego zaczęło mieć ironiczny sens. To stąd musiały się wziąć te wszystkie patologiczne i absurdalne procesy, z którymi od lat na co dzień mam styczność, a czasami nawet walczę. Ewidentnie zakorzeniły się ona tak głęboko w świadomości i kompetencjach dyrektorów na stanowiskach wykonawczych, że nie da się ich wyplenić. W końcu większość z tych osób zaczynała swoje kariery w latach świetności owych, w mojej opinii, ideologii. Skąd to określenie? Otóż stąd, że tak jak w przypadku innych metodologii ewangelizowanych przez ostatnią dekadę na rynku IT brak jest jakichkolwiek wiarygodnych metryk ilustrujących ich efektywność. Przyjrzyjmy się zatem ich podstawowym założeniom w odniesieniu do współczesnych realiów organizacji technologicznych rozwijających produkty cyfrowe.

Biografia

Obydwa twory miały swoje początki w latach osiemdziesiątych zeszłego wieku, co samo w sobie powinno już skłonić wszystkich mających z nimi styczność do głębokiej refleksji. Jak można bowiem w sektorze, w którymi stack-i technologiczne zmieniają się z roku na roku, odnosić się do tak archaicznych metodologii? Na samą myśl o tym przypomniały mi się MooTools-y z 2007 roku, ktoś jeszcze ich używa?

Prince2

Mimo iż obydwa framework-i zostały udokumentowane w swoich pierwszych wersjach w 1989 roku, to jest to de facto starszy z brytyjskiego rodzeństwa, gdyż wyrósł on ze swojego precedenta o nazwie PROMPT, którego historia rozpoczęła się w 1975 roku! Tak dobrze przeczytaliście! 1975! Jakie zatem odkrywcze tezy mogły zostać użyte w tamtych mrocznych czasach jako podwaliny nowo powstającego frameworka mającego ułatwić i usprawnić zarządzanie projektami? Otóż nic innego niż sześciofazowy lifecycle projektu rodem z waterfalla. Zapomnijcie o iteracjach, kolejnym etapem ewolucji były bowiem chwytliwe slogany wygodnie zebrane wielokrotności liczby siedem, mianowicie, siedem zasad, siedem motywów oraz siedem procesów. Co daje nam sumarycznie dwadzieścia jeden ogólnikowych frazesów użytecznych tylko na poziomie kompletnego odseparowania od faktycznej pracy w projekcie. Nie będę tutaj wyliczał wszystkich poszczególnych elementów tej wyliczanki, gdyż każdy zainteresowany czytelnik lub czytelniczka może odnieść się do całej rzeszy dokumentacji i oczywiście słono płatnych szkoleń on-line *wink wink*. Chciałbym natomiast zaznaczyć, zanim przejdziemy do drugiego z upośledzonych merytorycznie bliźniąt, że cała ta rozdmuchana teoria nie oferuje, tak jak wspomniałem we wstępie, absolutnie żadnych metryk szeroko rozumianego sukcesu, zamiast tego odnosząc się to chwytliwego trzyliterowego skrótu – KPI – czyli kluczowe wskaźniki efektywności. Co to dokładnie oznacza? Otóż absolutnie nic, zero konkretów, a jedynie odniesienie do ogólnych wyników, głównie finansowych, czy też retencji klientów i ich satysfakcji. Innymi słowy, danych, które praktycznie każda firma zbiera niezależnie od wdrożonej czy też nie metodologii operacyjnej. Aha, no i oczywiście warto dodać, iż w 2017 roku została wypuszczona kolejna wersja tej paleontologicznej twórczości. Tym razem uwzględniając, niczym SAFe po porażce Agile’a, skalowalność i elastyczność, czyli kolejne puste frazesy bez żadnych faktycznych wytycznych jak owe cechy operacyjne osiągnąć. Co za to natomiast udało się wyprodukować to całą nową iterację szkoleń i certyfikatów, tym razem z innym numerkiem na końcu. No przecież hajs musi się zgadzać, a broń boże niech nikt się nie przejmuje monopolem PeopleCert, spokojnie, to też spółka rządowa, z którym Axelos – obecny właściciel PRINCE’a – podpisał kontrakt na dostawy usług egzaminacyjnych. Może komuś z was tak jak mi w momencie czytania nazw tych firm uniosły się ze zdziwienia brwi, ale niczego się nie bójcie, to nadal stary dobry rząd brytyjski pod korporacyjną przykrywką, ale na tym nie koniec. Współwłaścicielem i głównym udziałowcem Axelos’a jest już trochę bardziej znana i słynącą z sukcesów Capita, utrzymująca się głównie z o dziwo, kontraktów rządowych. W zeszłym roku natomiast PeopleCert wykupił Axelos’a, czyli podsumowując, firma dostarczająca usługi egzaminacyjne wykupiła firmę, której owe usługi dostarczała, ale i tak na wszystkim tak naprawdę łapę trzyma rząd, nadążacie? Nie będę przynudzał, gdyż w Internecie pełno jest artykułów opisujących całą powyższą koniunkturę, natomiast chyba nawet tych kilka zdań wystarczyło, żeby zarysować, na jak patologicznych podwalinach została wysnuta z palca, i w jakim celu, cała omawiana metodologia. Przejdźmy zatem do drugiego z dwóch takich, co ukradli księżyc, rzekomo.

ITIL

Młodszy brat księciunia, gdyż po co mieć jedną dojną krowę skoro można mieć dwie. Zbyt redukcjonistycznie? Niesprawiedliwie? Właścicielem ITIL jest nie kto inny niż, uwaga, Axelos, czyli obecnie PeopleCert, czyli tak naprawdę rząd brytyjski. Nie będę zagłębiał się w kwestie merytoryczne, gdyż podobnie jak w przypadku PRINCE2-a, nie mają one tak naprawdę większego znaczenia i służą jedynie jako podkładka do istnienia kolejnej rzeszy szkole i certyfikatów. Uzasadnienie? Otóż PRINCE2 jest bardziej ogólny natomiast ITIL to już konkretny framework zarządzania szeroko rozumianymi usługami informatycznymi. W praktyce natomiast jest to odrobinę bardziej zaawansowana kopia swojego starszego brata lub wręcz odgrzany kotlet, ale tym razem z surówką. Jedyną zauważalną różnicą w przypadku ITIL’a jest natomiast to, że w odróżnieniu od jakiegokolwiek braku merytorycznych analiz na temat efektywności, w jakimkolwiek znaczeniu tego słowa, metodologii PRINCE2, istnieje w internecie kilka wzmianek na temat efektywności ITIL. Idąc tropem wzmianek owych analiz na Wikipedii, których co prawda nie znalazłem, dotarłem do kilku artykułów ‘naukowych’ które chciałbym pokrótce omówić.

Twarde fakty

Przecież nie ma lepszej metody naukowej niż rozesłanie dwu-pytaniowego formularza na temat poziomu wdrożenia ITIL-a w odniesieniu do współpracy biznesowo-technologicznych. Jeśli współpraca układa się dobrze w firmie, w której został wdrożony ITIL, to krzywa dystrybucji odpowiedzi na powyższe pytanie dowodzi jego efektywności. Czy tylko mi wydaje się, że owa teza nie ma absolutnie żadnego sensu? Jeszcze ciekawszą lekturą był artykuł dosłownie zatytułowany „Evidence that use of the ITIL framework is effective” autorstwa trzech dystyngowanych pracowników uniwersyteckich, w tym dwóch doktorów. Teza? ITIL działa, ponieważ na przykładzie analizy danych otrzymanych z pojedynczej jednostki rządowej z Południowej Afryki, datujących na lata 2002/2003, wykazano korelację pomiędzy wdrożeniem omawianej metodologii a spadkiem ilości rozmów telefonicznych z petentami. Wszystko jasne? Tak myślałem. Na szczęście sami autorzy tej radosnej twórczości kwitują, iż opisywana analiza nie jest rozstrzygająca i potrzebne są dalsze badania na temat efektywności ITIL-a, szokujące.

Po nitce do kłębka 

O ile samo opisanie historycznych korzeni PRINCE2-a i ITIL-a powinno samo w sobie służyć jako zimny prysznic zapaleńców niekończących się certyfikacji, to siatka patologicznych zależności na tym się nie kończy.

RAG

Kolejnym pomocnym standardem korporacyjnym będącym w ciągłym użytku w połączeniu z powyższymi framework-ami jest Red-Amber-Green, czyli swoisty panteon statusów projektowych. Czerwony złe, bursztynowy nienajgorszej, zielony najlepiej, niczym światła drogowe. O ile pomocnicze w kontekście obrazowania raportów są kolory i powiązana z nimi semantyka, o tyle prowadzi to również to niebywałej skali redukcjonizmu percepcyjnego, w którym to cala gama problematyk technologiczno-projektowych wrzucona jest do jednego z trzech worków. W mojej opinii jest to nic więcej niż kolejne narzędzie służące rozmyciu przepaści kompetencyjnych pomiędzy warstwami strukturalnymi, co nie powinno nikogo dziwić, gdy uświadomimy sobie, że u korzeni owego narzędzia leży, nikogo nie dziwiący już w tym momencie, rząd brytyjski. Skąd zatem wziął się ów system? Otóż stwierdzono, że przeciętny Kowalski, czy w tym wypadku John Smith, ma problemy w przeczytaniu ze zrozumieniem tabeli składników odżywczych na opakowaniu produktu spożywczego, dlatego też, aby uprościć jego drogę do zdrowego odżywiania wprowadzono omawiany system oznaczania kolorami. Zadziwiające jak podobny jest sposób jego wykorzystania w sektorze IT, zbyt skomplikowane, nie rozumiem, jaki to będzie kolor?

Nie tylko imperium brytyjskie

Zbliżając się ku końcowi, chciałbym jeszcze dla porównania odnieść się do innej podobnej metodologii z innej części świata, ale o bardzo zbliżonych korzeniach. W 2001 roku Toyota opublikowała po raz pierwszy swoją sformalizowaną „Drogę Toyoty”. Był to bardzo rzeczowy manifest opisujący w bardzo przystępny i rzeczowy sposób czternaście podstawowych zasad, którymi powinno kierować się produkcyjne. U korzeni owych dogmatów leży natomiast Toyota Production System (TPS), czyli dogmaty opracowane na przestrzeni lat 1948-1975, czyli jeszcze przed pierwszym brytyjskim snem o PRINCE2-e. Nie byłoby w tym oczywiście nic zdrożnego, gdyby nie fakt, iż z uogólnionej wersji tej metodologii, a mianowicie Lean Manufacturing, powstała jej technologiczna implementacja.

LEAN IT

Kolejny przykład absurdalnego ekstrapolowania tradycyjnych metodologii produkcyjnych na sektor technologii informacyjnej. Kilka rozpisanych sloganów o usuwaniu czy minimalizowaniu szeroko rozumianych strat w procesach rozwoju oprogramowania służących niczemu więcej niż po raz kolejny zatuszowaniu braku zrozumienia faktycznej technologii przez kadry zarządzające. Tak jakby cala rzesza ekspertów domenowych nie była sama w stanie dostrzec i skorygować o ile to tylko możliwe nieefektywności procesowych czy technologicznych w bezpośrednio przez nich rozwijanych produktach. Doktryny zawarte w opisywanym zagadnieniu są tak ogólne, że aż bezsensowne w tak wysoko specjalizowanym sektorze. Nie mówiąc już w ogóle o tym, że każdy z krytycznych elementów potencjalnych strat został nadpisany już dawno temu przez bardziej nowożytne metodologie takie jak już wspomniany wyżej Agile, DevOps czy też Domain Driven Development, redukujących tego korpo przodka do roli samogratyfikującego żargonu, za którym nie stoi nic więcej niż tylko kilka ogólnych sugestii, do których każdy zdroworozsądkowy programista doszedłby sam.

Niekończąca się historia

Podobnych wymysłów, bo inaczej nie umiem tego nazwać, jest oczywiście jeszcze wiele, jak chociażby Sigma Six z Motoroli, ale wszystkie mają ze sobą jeden wspólny element. Wszystkie te „metodologie” są wysokopoziomową ekstrapolacją procesów optymalizacji produkcyjnych z innych sektorów gospodarki na sektor IT. Zadziwia mnie natomiast kompletne ignorowania faktu, iż wszystkie te metodologie produkcyjne wywodziły się z faktycznych procesów produkcyjnych, a nie tak jak w przypadku ich wersji technologicznych, z teorii. W Toyocie, Motoroli czy innej korporacji formalizowały one pewien konkretny zakres namacalnych problematyk wewnętrznych i służyły jako wyznacznik szeroko rozumianej jakości. W IT natomiast są odgórnie narzucanymi transformacjami kompletnie oderwanymi od jakiejkolwiek codziennej rzeczywistości operacyjnej. No dobrze, wystarczy marudzenia.

Dinozaury w świecie cyberpunka

Jeśli od opublikowania manifestu agile’owego w 2001 roku do pierwszych publicznych wzmianek o SAFe minęło raptem 6 lat, a do oficjalnego jego oficjalnego sformalizowanie w 2011 zaledwie dekada, można by się zastanawiać jakim cudem w tak archaiczne twory, zwłaszcza rządowe, z korzeniami sięgającymi lat 80. zeszłego wieku w ogóle mają jeszcze miejsce w sektorze IT?. Otóż odpowiedź jest bardzo prosta, nie mają. Utrzymywane przy życiu są jedynie przez ludzi, którzy zostali w nich kiedyś wyszkoleni oraz przez miłośników bezsensownych certyfikacji w celu stuningowania sobie dziurawego lub słabego CV. Tak, zdaję sobie sprawę, że są od tego wyjątki, ale w tak dynamicznie rozwijającym się sektorze, jak polskie IT, w którym coraz więcej osób wchodzi na rynek pracy po ukończeniu średniego szczebla edukacji, zamiast iść na studia cała ta mityczna historia, jest po prostu niewiele warta.

Podsumowanie

Są one antytezą kolaboracji, gdyż nie dość, że opierają się o waterfall-owe planowanie to w dodatku w zdecydowanej większości przypadków, są one wdrażane na podstawie jakże nowoczesne narzędzia w postaci Excela i PowerPointa, a tym samym o izolacjonistycznie tworzoną dokumentacje, która służy jako podkładka pod niekończące się spotkania na różnych szczeblach, których celem jest nic więcej niż bąbelkujące w górę raportowanie. Oczywiście można by zaimplementować podobna metodologie zarządzania projektami z wykorzystaniem współczesnych narzędzi w postaci, chociażby JIRY i Confluence. Zarządzające poszczególnymi elementami poprzez tickety w JIRZe przy jednoczesnym, opartym o kilka zapytań raportowaniu w czasie rzeczywistym wszelkich zmian na stronie w Confluensie. Tylko skoro możemy mieć coś takiego to po co ubierać to w archaiczne szaty i dorabiać do tego ideologię? Na jednej stronie każdy zainteresowany mógłby asynchroniczne śledzić postępy prac, powstałe problemy itp. itd. Jednocześnie, również asynchroniczne, wszyscy chętni mogliby nawiązać poprzez wspomniane rozwiązanie działania kolaboracyjne. Bez zaśmiecania kalendarza tylko po to, żeby ktoś na głos przeczytał tabelkę z trzema kolorami czy też wymienił dane statystyczne, których i tak nikt za chwile nie będzie pamiętał, chociaż oczywiście po spotkaniu zostanie wysłany ‘deck’ z PowerPoint-a, który prawie że natychmiast ginie w otchłani identycznie zatytułowanych załączników w folderze plików pobranych.

Nie pozostaje mi chyba nic innego, niż użyć najbardziej kiczowatego słowa w historii analiz i powiedzieć, że reasumując opisane w tym tekście metodologie, nie różnią się praktycznie niczym od Agile’a, którego w pewnym sensie były duchowymi prekursorami i skupiając się na żargonie oraz słowach kluczowych kompletnie pomijają jakakolwiek merytoryczna dyskusja na temat ich skuteczności czy wymiernych zysków co w dobie meta-analiz, big data oraz śledzenia wszelkich możliwych metryk, jest według mnie kompletnie niezrozumiałe. Tym bardziej biorąc pod uwagę od jak dawna, są w obiegu i jakimi nie merytorycznymi przesłankami kieruje się cały przemysł certyfikacyjny.

Wnioski

Wydaje mi się oczywiste, że odejście omawiany framework-ów do lamusa jest jedynie kwestią czasu. Niestety zapewne potrwa to jeszcze co najmniej dwie lub nawet trzy dekady, na których przestrzeni wszyscy ówcześni proponenci, a później obrońcy skamieniałości odejdą najzwyczajniej w świecie na emeryturę. Nie wiem jak Wy, ale ja już nie mogę się doczekać.