ITÉlet

Avagy hogyan kezeljünk 40 offshore fejlesztőt, hogy rendesen dolgozzanak?

Avagy hogyan kezeljünk 40 offshore fejlesztőt, hogy rendesen dolgozzanak?

Egy elsősorban nagyvállalatnál előforduló problémával szeretnék foglalkozni: az erőforrás menedzsmenttel, abban az esetben, amikor nagy mennyiségű erőforrást akarunk hatékonyan felhasználni.

Az egyik dolog amit el szeretnénk érni, hogy az offshore munkatársak azzal és csak azzal foglalkozzanak, amit mi szeretnénk. Lehet hogy a távolság miatt elveszett valamilyen információ, nem értik a prioritásokat, vagy nem motiváltak.

A másik dolog az, hogy a munka nem konstans mennyiségű, hanem rapszodikus: néha sok és néha kevés. Nem szeretnénk azt, hogy a munkatársak munkaidőben malmozzanak feladatok hiányában, hogy aztán meg amikor beesik a munka, akkor túlórázni kelljen.

A feladatok elosztására és az igénybevétel egyensúlyozására nagyjából 3 modellt láttam eddig.

1) A kupacnyi fejlesztőt egy „erőforrás menedzser” alá soroljuk be. Ha valakinek fejlesztőre van szüksége a projektjéhez, akkor az erőforrás menedzsertől kér. Ha gond van a fejlesztővel, akkor az erőforrás menedzsernek kell megmondani, és majd ő lerendezi.
Ami miatt ez nem hatékony:
- A fejlesztőnek 2 főnöke lesz (az erőforrás menedzser és a projekt menedzser), igazából egy sem.
- Az erőforrás menedzser nem fog tudni effektíven motiválni egy ekkora csapatot. (Egy menedzser igazából csak 10-12 beosztottat tud vezetni, ennél nagyobb csapatnál más megoldásokra van szükség)
- Ki dönti el, hogy a párhuzamosan futó, össze nem hasonlítható projektek közül melyik mennyi és milyen erőforrást kapjon? Elvesznek a prioritások – aki hangosabban kiabál, az kap fejlesztőt.

2) A fejlesztőket kézivezérelni, azaz az egyes projekt menedzserekhez kötni. A PM adja nekik közvetlenül a feladatokat és ellenőrzi azok végrehajtását.
Különösen diktatórikus menedzserek számára lehet ez a tökéletes megoldás, de lesznek hátulütői:
- A munkatársak projektről projektre vándorolnak, nem alakul ki az identitásuk, nem lesz csapat kohézió
- Az aktuális főnökük nem ismeri őket, nem tudja hogyan kell motiválni őket

3) A fejlesztőket kisebb csapatokba lehet osztani (pl. szakmai alapon), az egyes csapatoknak vezetői lesznek (vezető fejlesztők vagy koordinátorok), akik a csapat napi feladatait egyénekre szabják. A projekt vezetők az egyes koordinátoroknak adják a feladatokat, ő pedig gondoskodik róla, hogy valaki megcsinálja. Tehát a csapatok egyfajta osztott erőforrások lesznek, akik a terhelés függvényében hol egyik, hol másik projekttel foglalkoznak. De mivel a csapat kicsi, ezért mindenki ismer mindenkit, és van csapat kohézió.
Szerintem ez az ideális, de természetesen ennek is vannak hátrányai:
- Nem biztos, hogy az egyes projektek egyenlő vagy szükséges mértékben kapnak fejlesztőket
- Attól függően, hogy az egyes menedzserek mennyire motiválják a fejlesztőket, a fejlesztők az egyéni preferenciájuk szerint dolgoznak egyik vagy másik projekten
- Lesznek projektek, ahova mindegyik fejlesztő szeretne bejutni, míg másokra egyik sem

Nálunk a 2-es és 3-as megoldást alkalmazzák. Az informatikai menedzserek nagy része a 2-esre szavaz, mert úgy érzik, a fejlesztők napot lopnak, ha nem állnak erős irányítás alatt. Az mondjuk igaz, hogy egy kiszervezett fejlesztésnél előfordulnak az ügyfélnek kiszámlázott furcsa tételek. Például a cég karitatív tevékenységet végzett 1 nap, amikor a fejlesztők nem is voltak az irodában, hanem valahol máshol a napi jócselekedetüket végezték – na erről is kaptunk számlát, mintha fejlesztettek volna.

Személy szerint én a 3-ast használom, és igen jól működik. A különbséget a motiváció és a csapat kohézió jelenti – az én csapatom motivált és lelkesen dolgozik. Bár már többen is elmagyarázták, hogy rosszul csinálom J
Szerencsére kifogtam egy jó koordinátort, és igyekszek az értékeinket megtartani.

A 3-as persze nem alkalmazható mindenhol – ha olyan a csapat minősége, és a menedzsernek nehezére esik ezt a stílust követni, akkor inkább jobb valami más.