Hogyan fejleszt másképp szoftvert az ázsiai, európai vagy amerikai cég?
Hogyan fejleszt másképp szoftvert az ázsiai, európai vagy amerikai cég?
Van egy informatikai partnerünk, aki globálisan nyújt kiszervezett informatikai szolgáltatásokat és erőforrásokat, például fejlesztőket és rendszerszervezőket ad projektekhez, szoftvertámogatást végez, szaktudást hoz a céghez. Nem csak nekünk Európában, hanem Ázsiában és Amerikában is. Ez a bizonyos informatikai partner – a munkakapcsolatot erősítendő – készített egy tanulmányt, hogy ők hogyan látnak bennünket. Illetve hogyan látják az egyes régiókat, összehasonlítva egymással.
Íme az eredmény:
|
Ázsia |
Európa |
Amerika |
Offshore ratio |
50:50 |
80:20 (ideális) |
70:30 |
Külső erőforrások igénybevétele |
Csekély |
Átlagos |
Jelentős |
Munka jellege |
Szoftver támogatás |
Szoftver támogatás és fejlesztés |
Szoftver támogatás |
Üzleti domain |
Néhány kiválasztott |
Teljes körű |
Teljes körű |
Preferált technológia (fontossági sorrendben) |
Web alkalmazások |
Web alkalmazások |
Mainframe |
Pénzügyi konstrukció |
Fixed bid |
T&M |
Vegyes |
Szoftverfejlesztési módszertan |
Vízesés |
Iteratív |
Vízesés |
SLA |
Van, kötbér nélkül |
Van, kötbér nélkül |
Van, kötbérrel |
Nyilván a fenti adatokban lehetnek cégünkre jellemző specifikumok, de bizonyára jelentős részben dominál az egyes országokban/régiókban szokásos szoftverfejlesztési kultúra.
Mit is mondanak a fenti adatok?
Az Offshore ratio helyes értéke 80:20 lenne, vagyis a fejlesztői csapat nagyobb része legyen offshore a költségek racionalizálása miatt. Ázsiában ezt nagyon nem így gondolják, és úgy általában kevésbé vonják be a külső partnert, kevesebb területre engedik be.
Az igénybevétel azt sugallja, hogy míg a cég Amerikában azonnal igyekezett maximálisan felhasználó a beszállító erőforrásait (rövid idő alatt jelentős mennyiségű fejlesztőt sikerült alkalmazni), addig mi Európában óvatosabbak vagyunk, Ázsiában pedig elsősorban a kapcsolat lassú felépítésére összpontosítanak.
Azt gondolná az ember, hogy az amerikaiak kiszolgáltatottá válnak a jelentős beszállítói jelenléttől, de ha gond lenne a minőséggel, akkor pont ugyanilyen sebességgel tudnának egy másik beszállítóhoz átmenni.
Furcsa azt látni, hogy a külső partnert elsősorban szoftver támogatásra használjuk, és csak Európában vesznek részt projekt munkában. Személy szerint én is úgy érzem, ha egy informatikai partnerünk erőforrásokat biztosít, akkor miért ne használnánk ezeket fejlesztési feladatokban?
Az ázsiaiak elzárkózása bizonyára azon alapul, hogy elsősorban belső erőforrásokkal oldják meg az üzletileg érzékenyebb fejlesztéseket, míg Amerikában megválogatják és specializálják a beszállítókat.
Azt vártam, hogy a technológiai preferenciák egységesek lesznek – elvégre az IT egy globális iparág globális trendekkel – ennek ellenére jelentős eltérések vannak. Az amerikaiak mainframe és kliens alkalmazás preferenciája azt sugallja, hogy erőteljes szoftvereket készítenek, feltehetőleg az üzleti értéket tartva szem előtt.
Nálunk szinte ismeretlen a kliens alkalmazás: a webes megoldások és mainframe programok az üzemeltethetőség és a tiszta architektúra irányába mutatnak. (pl. telepítésmentes környezet)
Közismert, hogy mi európaiak szeretjük a T&M alapú elszámolást, ami viszont az előzetes becslés és a változó üzleti igények függvényében könnyen csalódást okozhat egyik, avagy másik oldalnak. Az ázsiai megközelítés a kockázatok megosztását jelenti anélkül, hogy a költségek elszaladnának.
A riport legnagyobb meglepetése a szoftverfejlesztési módszertan. Ugyanis mi Európában vízesés modellt használunk! Nem értem, honnan vehették a rendszerszervezők az iteratív/agilis módszertant. Feltehetőleg az „agilis vízesés modell” klasszikus esete áll fenn.
Az amerikai leányvállalatok vízesés modellje azok számára lehet meglepő, akik szerint Amerikában már mindenki agilisan fejleszt. (Számomra nem volt az)
Az SLA rész némi magyarázatra szorul. A beszállító erőforrásokat biztosít szoftver támogatáshoz, nem magát a szoftver támogatást szerveztük ki. Nem is biztos, hogy ennek a kiszervezése jó ötlet lenne. Mivel a beszállítónak nincs teljes mértékű felelőssége a támogatásban, ezért kötbér sincs. (Ez egy soktényezős egyenlet, például függés az informatikai környezettől, informatikai gerinchálózattal, szerverek rendelkezésre állása, stb)
Az amerikai hozzáállás itt is „kapitalistább”: ha játszunk, játsszunk keményen. Van kötbér, a beszállító felelőssége nagyobb, de a megrendelés volumene is nagyobb.
Utolsó kommentek