HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

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.

Címkék: menedzsment erőforrás osztott

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr605211378

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása