Od czasu do czasu spotykam się w projektach z takimi oto tezami, wypowiadanymi przez kierowników projektów, głównych architektów itp.:

„Wiedza akademicka to jedno a wiedza praktyczna to drugie 😉 Nie da się tego połączyć :(„

To objaw tragedii kompetencyjnej… takie zdanie może wypowiedzieć tylko kompletny ignorant, którego jedyną kompetencją (bo zakładam, że jakąś musi mieć, skoro zajmuje to stanowisko) jest chyba pełna lojalność wobec pracodawcy i skuteczne wyciąganie protokołów odbioru z klientów (czytaj wyciąganie pieniędzy), nie dam głowy jak z etyką pracy.

Co jakiś czas czytamy o porażkach projektów w sferze publicznej, zapewniam, że są one nie takim rzadkim zjawiskiem w sferze prywatnej. Dlaczego nie czytamy o tym? Bo, na szczęście dla firm prywatnych, nie dotyczy ich ustawa o dostępie do informacji publicznej itp., projekt nabywa status „tajemnica korporacji”’  i nikt nie wie poza tymi, co brali udział w projekcie.

Miewam konsultacje, korepetycje, coaching itp. Pytany jestem często: „czy zdarza się Panu w projektach, że np. kierownik projektu mówi, że nie ważna jest jakość tych projektów tylko termin i protokół odbioru, klient i tak nie potrafi tego skontrolować”. Powiem tak, zdarza mi się i wtedy – o ile to ja nie nadzoruje projekt po stronie kupującego – odmawiam albo rezygnuje z udziału w projekcie, jednak ja nie mam umowy o prace i nie jestem nią szantażowany (jej utratą). Prawdę mówiąc nie wiem co mam tym ludziom mówić, poza powyższym oczywiście, ale i tak zawsze mówię: bądź uczciwy (co jest bardzo trudne).

Ale co z ta teorią i praktyką? To troszkę jak z samochodem, wielu ludzi nimi jeździ ale nie każdy rozumie działanie skrzyni biegów. Wielu ludzi wyuczyło się przy jakiej prędkości zmieniać bieg na wyższy, kiedy redukować, ale już nie każdy wie jak się zachować jadąc pod górkę, z górki, co to jest hamowanie silnikiem i kiedy się to robi, dlaczego chcąc przyśpieszyć wrzucamy wyższy bieg później… aby to wiedzieć, należy rozumieć. Dlatego wielu ludzi bez problemu jeździ samochodem do pracy czy na wczasy, ale już nie tak wielu radzi sobie z sytuacjami nietypowymi…

Owszem można się wielu rzeczy nauczyć na pamięć i teoria tu nie jest potrzebna, ale prostych sytuacji na drodze jest mało, owszem są to te najpowszechniejsze ale tylko te. Każdy nietrywialny przypadek wymaga… no czego? Na pamięć? Nie – zrozumienia tego czym się zajmujemy. Człowiek ma ograniczone możliwości zapamiętywania, paradoksalnie to, czego używamy rzadko, szybko ulatuje z naszej głowy, to naturalny mechanizm mózgu.

Dlatego, niestety, wiedza teoretyczna, rozumienie, to podstawa w każdym nietrywialnym projekcie. Nauka na pamięć to bardzo ograniczone możliwości, rutyniarstwo i zupełny brak możliwości rozwiązywania nowych problemów. Zrozumienie powoduje, że niczego nie musimy się uczyć na pamięć i radzimy sobie w nowych sytuacjach, tak samo jak ze skrzynią biegów: kto rozumie temu nie gaśnie silnik… kto nie rozumie – zawsze będzie „zwykłym kierowcą”…

Ignorowanie wiedzy akademickiej, jest przyczyną większości porażek, bardzo wiele projektów IT to jak leczenie ludzi przez znachorów: nie ma pojęcia o anatomii i wpływie substancji chemicznych na ludzi ale z uporem maniaka serwuje ludziom pijawki, suplementy, pseudoleki, upuszczanie krwi itp. wielu z takich znachorów do końca życia uważa, że akademia medyczna szkodzi i tych „lekarzy” należy się bać…

Zacytuję: „prawdziwa wiedza to znajomość przyczyn” (Arystoteles), bez tego wielu PM,ów doskonale operuje ryzykami ocenianymi z ich bogatego doświadczenia ale nie ma bladego pojęcia od czego one zależą… tak powstała cała AGILE metodyka: reagujemy na to co zaobserwujemy, dokładnie tak jak górale prognozują pogodę…

Swego czasu pewien, jak sam o sobie mówi, bardzo doświadczony tester oprogramowania (czytaj długo pracuje) napisał do mnie, że dobre testy to … i tu litania metod. Doskonale rozumiem spojrzenie tego testera, takie 'kompetencje” widuję często. Z perspektywy testera w zasadzie ma on rację twierdząc, że „podnoszenie jakości oprogramowania to podnoszenie jakości testów”. Zapomniał jednak, że są dwa sposoby na podnoszenie jakości:

1. coraz skuteczniejsze wykrywanie błędów
2. robienie coraz mniejszej ilości błędów

Niestety w gestii testera leży wyłącznie to pierwsze i tu go rozumiem….ale dodam, że drugie jest znacznie tańsze. Tylko do takiej decyzji potrzeba po pierwsze zrozumienia a po drugie spojrzenia z szerszej perspektywy.

I niestety nie liczę na zrozumienie u większości PM’ów (ich wiedza jest często taka jak powyższy kamień pogodowy),  realizują cele swojego pracodawcy a nie cele kupującego, a Ci ostatni albo mają kompetencje by nadzorować własne projekty albo nie…