Jó-e az – illetve szükséges-e – hogy egy szoftverfejlesztési projektben a projektvezető értsen a szoftverfejlesztéshez? Vagy elég egy „általános” PM, aki a szükséges projektmenedzsment tudással felfegyverkezve „bármilyen” projektet le tud vezetni?

Jó-e az – illetve szükséges-e – hogy egy szoftverfejlesztési projektben a projektvezető értsen a szoftverfejlesztéshez? Vagy elég egy „általános” PM, aki a szükséges projektmenedzsment tudással felfegyverkezve „bármilyen” projektet le tud vezetni?

A kérdést a LinkedIn-en vetették fel egy beszélgetés során, és bizony nagyon jó a kérdés.

Két iskola csap össze:

-       Ez egyik szerint a projektmenedzsment tudománya általános, ugyanúgy építünk házat, autót és szoftvert (sőt piramist is…). Éppen ezért egy képzett PM, akinek amúgy semmilyen IT képesítése nincs, majd tökéletesen le tud vezényelni egy szoftverfejlesztési projektet.

-       A másik iskola szerint nincs szükség öltönyös dilettánsokra, a programozókkal csak hasonszőrű informatikus érti a szót, és különben is ha a PM nem ért a szoftverfejlesztéshez akkor nem fog tudni döntéseket hozni és nem fogja érteni, mit csinálnak az emberei.

A témát már többször érintettem, például összehasonlítottam az IT vagy az üzleti oldalról érkező PM-eket, illetve olvasói kérdésre leírtam, hogyan lehet menedzser az informatikusból.

Nos, mi a helyes út?

A LinkedIn beszélgetésből az derül ki, hogy a PM-nek elsősorban a projektvezetéshez kell értenie, az informatikai tudás nem szükséges, sőt inkább káros.

Hogy is van ez?

A PM-ség az egy önálló szakma, úgy mint a pék, orvos vagy traktoros. Megvannak a saját eljárásai, saját eszközei, a saját szakmai tudáskészlete. Érteni kell hozzá. Ha a PM-től megköveteljük, hogy informatikus is legyen, akkor valószínűleg egyikhez a másik kárára fog érteni.

Na jó, de az öreg szaki bácsi nem tudja levezényelni a projektet? Le tudja. Ha valaki egész életében szoftverfejlesztéssel foglalkozott, mindent tud és mindent átlát, akkor projektmenedzsment eljárások nélkül is mindent meg tud csinálni. Hiszen már annyit csinálta és annyira ismeri, hogy csukott szemmel is tudja, mi mennyi munka lesz és hol mikor mire kell odafigyelni.

A gond ott van, amikor a szaki bácsi nagyon sikeres lesz, és egy számmal nagyobb projektet kap. Amit már nem lát át teljesen, amiben számára ismeretlen feladatok bukkannak fel. Mert akkor leblokkol és nem tudja, mit csináljon. Na ehhez kell a PM ismeret, hogy egy ilyen projekttel tudjon mit kezdeni.

Azt hiszem azzal is mindenki egyetért, hogy az a legjobb PM, aki nagyon ért a projektvezetéshez, PLUSZ MÉG ahhoz is ért, amiről a projekt szól. A baj az, hogy ilyen emberből nagyon kevés van. De ha valaki értene is mindkettőhöz, az csak egy ideiglenes állapot: hiszen az informatikai tudás elavul, a PM-ként dolgozó informatikusnak nincs lehetősége műszaki tudását pallérozni, néhány év kérdése és már nem fog érteni ahhoz, amihez az alá beosztott fejlesztők.

Tehát akárhogyan is nézzük, a PM informatikai tudása egy idő után irreleváns lesz. Vagy azért, mert eleve nem is volt elég erős, vagy mert egy idő után elavul. (Mennyire jó programozó valaki, aki 10 évvel ezelőtt IT guru volt, azóta viszont nem nyúlt kódhoz? Releváns-e, hogy nagyon ért valaki egy rég elavult technológiához?) A lényeg a lényeg, hogy nem a PM lesz a legjobb informatikus a projektben, és erre kell felkészülni.

Ami nem is baj. Ahogyan nagyon jól rámutatnak a LinkedIn beszélgetésben lévők, a PM nem hoz döntéseket (műszaki döntéseket). A PM szerepe „pusztán” annyi, hogy a projekt előrehaladását segíti, azaz megszerzi a szükséges erőforrásokat (információ, eszközök) és elhárítja a blokkoló akadályokat (nagyon leegyszerűsítve). A műszaki döntéseket nem ő hozza, hanem az architekt vagy a tech lead vagy a szenior fejlesztő. Amikor a PM „döntés hoz”, akkor csak megkérdezi ezt az embert (aki őnála sokkal jobban ért a technológiához) és a szakvéleményt alkalmazza.

A PM ugyanis a projektet menedzseli és nem az egyes feladatokat. Az egyes feladatokat a fejlesztők menedzselik, mindenki önmaga menedzsere. A PM „csak” annyit tesz, hogy ezt a sok-sok dolgot összefogja egyetlen projektté.

Az informatikai projektek nem ott szoktak elcsúszni, hogy a fejlesztők ne értenének a technológiához és kell egy IT-s PM aki majd megmondja nekik a frankót, hanem inkább ott, hogy nem volt jó az ügyféllel a kommunikáció, vagy hogy nem voltak meg a szükséges eszközök a fejlesztéshez. Tehát a projekt sikeressége szempontjából fontosabb, hogy a PM tudjon kezelni „nem technológiai” jellegű problémákat, és hagyja a technológiai problémákat a fejlesztőkre.

Manapság a 21. században már nem releváns, hogy a PM értsen szót a fejlesztőkkel. A szoftverfejlesztés az ügyfélről szól, a tipikus szoftverfejlesztővel szemben már elvárás, hogy szót értsen az üzleti oldallal és az ügyféllel. Ezért nincs szükség „tolmácsra”. Sőt ha a PM „single point of contact”-ként viselkedik (azaz minden kommunikáció szigorúan csak rajta keresztül mehet át) azzal is rontja a csapata viselkedését.

Ennek ellenére sok olyan PM van, aki fejlesztőből nőtt ki. Hiszen a fejlesztők azt szeretik, ha a menedzserük „hasonszőrű” illetve „közülük való”, aki érti a problémáikat. Ez nekik jó rövid távon, de hosszú távon se az ügyfélnek, se a projektnek nem jó.

Érdemes azt észrevenni, hogy a fejlesztőből lett menedzserek nagy része „véletlenül” lett azzá. Vagyis egy adott helyzetben valakinek el kellett látnia bizonyos menedzsment feladatokat, nem volt pénz főállású PM-re, ezért ezeket a feladatokat valakinek a nyakába tolták a meglévő feladati mellé, úgy csomagolva hogy ez ne plusz feladatnak hanem kihívásnak tűnjön. Ők nem PM-ek, hanem a projektmenedzsmentbe belekontárkodó fejlesztők. Ami jól is elsülhet: a fejlesztő belátja, hogy ez egy új szakma, és képzi magát hogy jó PM legyen (hogy aztán IT tudása elavuljon).

Miért van az, hogy bizonyos cégek szoftverfejlesztéshez értő PM-et keresnek? Mert bizonyos esetekben működhet a dolog. Amikor a PM a fejlesztéshez is ért, akkor ő valójában 2 szerepet tölt be a projektben: PM + műszaki vezető. Ahol rosszul szervezett a munka, ott ez lehet jó megoldás. És ott is, ahol elég kicsi a projekt – hiszen ott kevés a PM feladat. Mint korábban írtam, ez ideig-óráig, bizonyos körülmények között jól tud működni, hogy aztán abban a pillanatban összeomoljon a kártyavár, amint egy picit is komolyabb projekt jön.

És itt jön a félelmetes következtetés: káros-e, ha a PM ért a szoftverfejlesztéshez? Vannak, akik szerint igen. (Ami vicces: egyesek szerint a PM-nek KELL értenie az IT-hoz, másik szerint viszont éppen, hogy káros)

Mint korábban írtam, a műszaki döntéseket a legjobb mérnök hozza a projektben, és nem a PM. Ha a PM akárcsak egy pillanatra is azt hiszi, hogy ért hozzá, és meghoz egy döntést a mérnök HELYETT, ott és akkor a projekt ellen dolgozik. Márpedig ez a fajta mentalitás (kikérni mások véleményét) tökéletesen ellentétes azzal, amit egy informatikus csinál (van műszaki elképzelése és nem fél azt megvalósítani).

Tehát nem maga a műszaki tudás hátráltatja a PM-et a munkája elvégzésében, hanem az ezzel járó fals önbizalom, a konzultáció hiánya és a kommunikáció hiánya. Ennél már az is sokkal jobb, ha egy teljes „szűz”, az IT-hoz nem értő PM-et dobunk be a mély vízbe, hiszen ő rá lesz kényszerítve, hogy a többiekkel kommunikáljon és kikérje véleményüket.

A fentiek teljesen összevágnak a megfigyeléseimmel: nemzetközi környezetben olyan ritka az IT diplomával rendelkező PM, mint a fehér holló.