Zasada nieoznaczoności?

Często spotykam się z poglądem, który można by nazwać informatyczną zasadą nieoznaczoności. Otóż, moi rozmówcy twierdzą, że szef projektu informatycznego nie może kontrolować jednocześnie wszystkich jego kluczowych czynników, czyli harmonogramu, zasobów (budżetu i pracy) oraz jakości produktu finalnego. Jeżeli ściśle próbuje trzymać się harmonogramu i budżetu, ''siada'' jakość. Kiedy usiłuje dostarczyć bardzo dobry produkt i zmieścić się w budżecie, projekt się wydłuża. A jeśli dotrzymuje terminów i chce, aby efekt pracy jego zespołu był bardzo dobry, potrzebne zasoby wymykają się spod kontroli.

Często spotykam się z poglądem, który można by nazwać informatyczną zasadą nieoznaczoności. Otóż, moi rozmówcy twierdzą, że szef projektu informatycznego nie może kontrolować jednocześnie wszystkich jego kluczowych czynników, czyli harmonogramu, zasobów (budżetu i pracy) oraz jakości produktu finalnego. Jeżeli ściśle próbuje trzymać się harmonogramu i budżetu, ''siada'' jakość. Kiedy usiłuje dostarczyć bardzo dobry produkt i zmieścić się w budżecie, projekt się wydłuża. A jeśli dotrzymuje terminów i chce, aby efekt pracy jego zespołu był bardzo dobry, potrzebne zasoby wymykają się spod kontroli.

Na pozór ta argumentacja brzmi rozsądnie. Proste podobieństwo do zasady Heisenberga czynią ją dodatkowo atrakcyjną intelektualnie dla każdego, kto podczas studiów przeszedł przez wszystkie osobliwości mechaniki kwantowej. Uwiarygodnia ją też powszechna praktyka, w myśl której projekty naruszają przynajmniej jedno z powyższych ograniczeń, a czasami wszystkie trzy. Weszła już nieomal do kategorii tzw. prawd obiegowych i tylko czekać, aż zostanie ogłoszona w Harvard Business Review przez jakiegoś mądralę w rodzaju Nicholasa G. Carra, autora słynnego IT Doesn't Matter.

Wiem, że powiem coś niepopularnego, ale uważam, że jest dokładnie odwrotnie. Brak kontroli nad którymś z elementów przedsięwzięcia informatycznego świadczy o braku kontroli nad przedsięwzięciem jako całością. Liderzy, którzy nie są w stanie zapewnić zgodności projektu z harmonogramem, z reguły nie kontrolują także jakości i zasobów. Zrządzeniu niebios mogą zawdzięczać, że ich projekt kończy się z tylko jednym elementem przekroczonym, a nie wszystkimi; albo że kończy się w ogóle jakoś, bo o jakości najczęściej mówić nie sposób.

Przedsięwzięcia informatyczne kończą się tak jak się kończą, nie dlatego że ciąży nad nimi jakieś transcendentne fatum rodem ze świata kwantów. Przekroczenia harmonogramu, budżetu i kiepska jakość to wynik braku mechanizmów pomiarowych i decyzyjnych. W każdym momencie lider powinien móc odpowiedzieć sobie na trzy proste pytania: czy to, co robię, prowadzi mnie do celu, gdzie się znajduję na drodze do tego celu i skąd wiem, że właśnie tutaj? A jeśli widzę, że coś nie idzie zgodnie z planem, to czy mam dostateczne narzędzia, żeby to zmienić?

Zdaję sobie sprawę, że w realnym świecie, w dziedzinie tak zmiennej jak informatyka, dobre prowadzenie przedsięwzięcia wymaga dobrych podstaw teoretycznych i wielu lat doświadczenia. Wiadomo że mistrzostwo osiąga się talentem i ciężką pracą. I tym bardziej irytujące jest powoływanie się na rzekomą zasadę nieoznaczoności, obowiązującą jakoby w projektach informatycznych.

W ostatnich latach niezależne organy (np. brytyjskie stowarzyszenie informatyków BCS) donoszą, że coraz więcej przedsięwzięć kończy się sukcesem. Czyżby zasada nieoznaczoności przestawała obowiązywać albo nagle osłabła? Czyżby jakiegoś cudu dokonały metodyki analizy i projektowania lub narzędzia informatyczne typu RAD? Nie wierzę. Po prostu przybyło wysoko wykwalifikowanych specjalistów od prowadzenia czy raczej od "udawania się" przedsięwzięć, którzy pokończyli dobre szkoły oraz parę rzeczy doprowadzili do końca. Ci ludzie rozumieją, na czym polega kontrola czasu, budżetu i jakości produktu. Trzymają przedsięwzięcie "na końcach palców", jak mówią Anglicy, czując jego "puls i oddech". I to od nich powinniśmy się uczyć i ich powinniśmy słuchać, nie mędrków formułujących wątpliwe zasady nieoznaczoności.