ITÉlet

Outsourcing az, amit minden nagyvállalat csinál, de nem mindenki csinálja jól. A legtöbb esetben a megrendelő naiv, túlzott – vagy épp ellenkezőleg, túl alacsony – elvárásai vannak, ami mindenféle káros pótcselekvéshez vezet. Az alábbiakban leírok néhány hasznos tanácsot.

Még mielőtt belekezdenénk, mindenkit kérek olvassa el a márciusban megjelent Őszintén az outsourcing-ról című cikket. Ott sok lényegi információ szerepel, ami fontos lesz a tanácsok megértéséhez.

Hogyan lehet a kiszervezést jól csinálni? Az alábbiakban néhány gyakorlati tanácsot osztok meg, a teljesség igénye nélkül.

Mint mindig, itt is a piszkos anyagaikon múlik minden. Egyik oldalon azt szeretnénk, hogy az informatikai szolgáltatások minősége ne romoljon – tehát a legjobb embereket kapjuk meg, akik a lelküket is kiteszik értünk -, a másik oldalon viszont ezt a munkát harmad áron végezzék.

Melyik konstrukció a legjobb, fixed price, time&material, projekt alapú elszámolás vagy elvégzett munka alapján?

Kezdjük hátulról. Elvégzett munka alapján fizetni logikusnak tűnik, csak éppen nem világos, mi az elvégezett munka, illetve mi a hasznosan elvégzett munka. Erre a tanácsadók azt mondják, hogy a lezárt ticket-ek alapján fizessünk, darabra. Szerintem ez a létező legrosszabb, hiszen gyakorlatilag azért fizetjük a fejlesztőket, hogy rossz munkát végezzenek. A rossz munka ugyanis több ticket-et jelent, sok apró hibát. Előbb-utóbb ez a konstrukció oda vezet, hogy a fejlesztők tudatosan bug-okat írnak bugfix helyett.

A projekt alapú elszámolás a kockázatok miatt azt fogja jelenteni, hogy az outsourcing partner rengeteg tartalékot épít az árba, tehát drága lesz.

A fixed price és a time&material jó megoldások. A fixed price a beszállító nagyobb önállóságára épít, a T&M pedig arra, hogy a megrendelő jobban kézben tartja a munkát.

Amikor az együttműködés szerződéses kereteit meghatározzuk, akkor ne felejtsük el, hogy mindenki másképp dolgozik, nem létezik egyetlen jó módszer. Lesznek olyan csoportok, akik szakmailag erősek, de lesznek, akik nem annyira. Lesznek nagy fejlesztői csapatok, és lesznek kicsik. Lesznek menedzserek, akik intelligens majomként kezelik a külső fejlesztőiket, míg mások teret adnak a fejlesztői kreativitásnak. Lesznek olyan csapatok, akik agilisan, dinamikusan dolgoznak, és lesznek olyanok, ahol inkább policy-k és szokások mentén.

Tehát a kiszervezés mindig arról szól, hogy egymástól függetlenül működő silókat építünk. Ez tény, hiszen a megrendelői oldalon ülő menedzserek munkastílusa különböző, a körülmények különbözőek, a beszállítói oldalon lévő csapat adottságai is egyedik. A lényeg tehát nem az, hogy mi a legjobb megoldás, hanem az, hogy mik az igényeink és milyen anyagból dolgozunk.

Tegyük fel, hogy van 10 fejlesztőnk Indiában – időzóna, kulturális különbség, nyelvi problémák. Hogyan lehet a munkát irányítani, a fejlesztőket kézben tartani? Sem a túlzott kontroll, sem a teljes szabadság nem jó. Két legjobb módszer létezik:         
1) A csapat egyik tagját csapatvezetőnek nevezzük ki, és hagyjuk, hogy ő irányítsa a fejlesztőket
2) A fejlesztőket mikromenedzseljük, tipikusan úgy, hogy párokba szervezzük a belső és külső embereket, minden belső ember kap egy külső fejlesztőt, akivel párban dolgozik közös feladaton.

Az egész azon múlik, mekkora szabadságot adunk a fejlesztőknek, illetve van-e csapatvezetőnek alkalmas személy a csapatban.

Miután sikeresen felépítettük a silónkat, megeshet, hogy jön valaki és bele akar szólni. Ha sikerült összehangolni az onsite és offshore csapatokat, és a kooperáció működik, akkor ne engedjük, hogy abba valaki beleszóljon!

Már írtam róla cikket, hogy túlzott bürokráciával, például timesheet kitöltésével nem fogjuk tudni növelni a hatékonyságot. A túlzott bürokrácia alkalmas arra, hogy bizonyos veszteségeket megtaláljunk (például egy gyenge fejlesztő vagy egy naplopó), de ugyanakkor ennek ára van – a fejlesztők érdemi munka helyett adminisztrációval töltik az idejüket.

Amikor külső fejlesztői csapattal dolgozunk, azt hisszük, hogy mint megrendelő, mi vezetjük a fejlesztőket. Ez nem igaz. A külső csapatnak megvan a saját menedzsere, a saját QA-sa. Lehet, hogy ezt a személyt nem ismerjük, de ettől még létezik. Elképzelhető, hogy a partnernél dolgozó menedzser és a megrendelő egymással ellentétes utasításokat ad a fejlesztőknek – akik aztán saját elképzeléseik alapján vagy egyiknek, vagy másiknak engedelmeskednek. Éppen ezért fontos, hogy beazonosítsuk ezt a vezetőt és összehangoljuk a célokat.

A külső csapatnak nem csak saját menedzsere van, hanem saját controlling/monitoring eljárásai. Akár kéri a megrendelő, akár nem, a külső fejlesztő csapat rendszeresen report-ál az elvégzendő és elvégzett feladatokról saját vezetőiknek, akik ezeket az információkat vezetői szinten összesítik. Meglehet, hogy az összesített report egészen más státuszt tartalmaz, mint amit a megrendelő gondol. Például lehet, hogy miközben a megrendelő elégedett a munkával, a cég QA-sa szerint csapnivaló a minőség. Vagy ellenkezőleg, a fejlesztők szerint minden zöld, miközben a megrendelő elégedetlen.

Célszerű felderíteni, hogyan biztosítja a minőséget partnerünk, milyen report-okat gyártanak, és elérni, hogy ezeket hangolják össze a megrendelővel.

Megesik, hogy a partnerünk fogja a legjobb fejlesztőket és elveszi, hogy cserébe kezdőket adjon – természetesen ugyanolyan áron. Ezért célszerű kikötni, a megrendelőnek is legyen beleszólása a HR döntésekbe. Például a leendő fejlesztővel legyen egy formális interjú (önéletrajz megosztással), ahol az ügyfélnek legyen joga a nem megfelelő fejlesztőt visszautasítani. Ekkor a partnernek is érdeke lesz, hogy tapasztalt fejlesztőket adjon.

A korábban írt cikkben szó volt a bizalomról. Kiszervezés esetén mindig felmerül a kérdés, mekkora szabadságot adjunk a külső csapatnak. A tény az, hogy mindegy milyen szerződést írunk és milyen módon ellenőrizzük a teljesítést, a kiszervezett erőforrások fölött csak korlátozott hatalmunk lesz.

A kiszervezés körül a kulcskérdés mindig az, hogy kinek a kezében lesz tudás. Nos, ha a tudást teljes egészében kiadjuk a kezünkből – azaz nem ismerjük saját rendszereinket és nem értünk a technológiákhoz – akkor az sosem lesz jó. Függetlenül attól, hogy a beszállítónk mennyire jó. A helyes felállás az, amikor a fejlesztőcsapat vegyes: külsősökből és belsősökből áll. A tudás legyen közös, mint ahogy a munka és az eredmény is közös.