Mit ad a Szilícium-völgy a fejlesztőknek? A kérdés nem a "Brian élete" parafrázisának a kezdőmondata: egy sokat látott magyar fejlesztő összefoglalta, miért hatékony a sokak által irigyelt kaliforniai modell. Hagyják a fejlesztőmérnököt dönteni, és a jó döntéshez minden szükséges információt biztosítanak, így pénzben mérhetően is jobban hasznosul a munkája, ezért magasabb fizetést is tudnak neki adni. Tömören így foglalható össze, miben látja másnak Orosz Gergely a szoftverfejlesztők munkáját a modern, szilícium-völgybeli techvállalatoknál, mint egy konzervatív sturktúrában működő cégnél. A magyar fejlesztő, aki mindössze egy évtized alatt meglehetősen impresszív karriert futott be (J.P. Morgan, Skype, SkyScanner, Uber, ahol gyorsan bekerült a core fejlesztőcsapatba), saját blogján foglalta össze, hogy szerinte miért hatékonyabb a Szilícium-völgy stratégiája, amely szerinte a ilyen típusú cégek hatékonyságára is pozitívan hat.

És hogy ez miért fontos? Az IDC tavaly októberben kiadott FutureScape tanulmánya szerint a hagyományos vállalatok néhány éven belül szoftvervezérelt "digitális innovációs gyárrá" alakulnak. Az évtized közepére a vállalkozások közel kétharmada elképesztő mennyiségű szoftvert fog gyártani, és naponta fog új kódot telepíteni.

Az Ubert tavaly októberben elhagyó Orosz írásában következetesen szembeállítja a Szilícium-völgy szellemiségét a konzervatív, hierarchikus vállalati struktúrával. Szerinte az előbbi típus (amibe nem csak a Kaliforniában működő cégek tartoznak) többet ad a fejlesztőinek, és ezáltal többet is kap tőlük. Orosz több alapvető különbséget is felsorol, de messze a legfontosabb, hogy a Szilícium-völgyben a szoftvermérnököket értékteremtő és kreatív problémamegoldó munkatársnak tekintik, míg a hagyományos vállalatoknál a gyári munkás kategóriába sorolják őket. Szerinte minden ebből következik. De pontosan mi is?

A hét ok, amiért jobb a Szilícium-völgy

1. A fejlesztőmérnök autonómiát kap. Egy hagyományos cégben a fejlesztő kap egy JIRA-jegyet arról, hogy mit kell csinálnia. A lényegi információ a termék- vagy a projektmenedzsernél van, és ők azt várják el a fejlesztőtől, hogy a kiosztott részfeladatot maradéktalanul megoldja. Kérdés legfeljebb a jegy részleteinek tisztázásával kapcsolatban lehet.

Egy modern techvállalatnál is vannak projektek, projektmenedzserek, vezetők. De nem a szabályozás a dolguk. Elvárják és ösztönzik a fejlesztőket, hogy ők találják ki a munka mikéntjét, és ebbe beletartozik, hogy fontos döntéseket is nekik kell meghozniuk. Ennek előfeltétele, hogy minden csapattag lássa a nagy összképet, mert csak így érzékelheti a megoldandó problémákat. Ebből születnek például egy termékben olyan szolgáltatások, amikre eredetileg a tervezésnél nem is gondoltak, de jobbá, eladhatóbbá teszi azt.

Ez a szervezeti felépítésben is működik. Orosz Gergely negatív példaként egy bankot hoz, ahol hatszintű volt a projektmenedzsment, a fejlesztők természetesen a hierarchia legalján voltak, a döntéseket mindig fölöttük hozták meg. Ezzel szemben a hatékonyan működő vállalatok a releváns üzleti kontextust is megosztják a fejlesztőkkel, akik arra így megfelelő választ tudnak adni (és persze ehhez szabadságot is kapnak).

2. Problémamegoldónak, és nem agyatlan erőforrásnak tekintik. A szoftvermérnökök általában a legjobban fizetett szakemberek, de nem úgy lehet kihozni belőlük a legtöbbet, ha szigorúan előírjuk számukra a 8 óra kódolást. A Szilícium-völgy vállalataihoz hasonló cégeknél a szoftvermérnök problémamegoldó szakember. Ezért a technikai készségei mellett egyre inkább hangsúlyt kapnak a soft-skilljei, például a kommunikációs készsége vagy a problémamegoldó képessége. (A nyolc óra munka témájával kapcsolatban érdemes felidézni Derick és Harry egy korábbi írását is.)

3. Belső adatok, kódok és dokumentációk átláthatósága. Orosz szerint a Szilícium-völgy típusú cégek kevés kivétellel (Apple, Palantir) transzparensek az alkalmazottaik felé. A hagyományos cégek viszont igyekeznek csak annyi információt átadni, amennyi az adott munkához feltétlenül szükséges, a vezetők tudják a "miért"-re a választ, a fejlesztő meg aszerint végrehajt. Pozitív példaként hozta a Skyscannert, ahol még a napi bevételekről is részletesen tájékoztatást kaptak a fejlesztők. Persze ez egy tőzsdei cégnél már nem feltétlenül járható, de még azoknál is át kellene adni a mérnököknek azokat az üzleti adatokat, melyek alapján jobb döntéseket hozhatnak, hiszen egy alkalmazás működése sokszor akár közvetlenül is befolyásolja a bevételeket.

4. Ezért egy modern szervezetben minden csapattag láthatja, hogy munkája az üzleti tevékenység mely részére és hogyan hat. Az ilyen vállalatoknál arra ösztönzik a fejlesztőket, hogy lépjenek kapcsolatba az üzleti oldallal. (Az agilis szervezetekben ez egyre inkább hangsúlyossá válik – a témával kapcsolatban érdemes újraolvasni a jelenleg idomsoftos Both András két korábbi írását itt és itt.)

5. Lebontják a kommunikációban a hierarchiát. Az egyes csapatok tagjai közvetlenül is megkereshetik egymást tapasztalatcsere vagy akár együttműködés céljából, és nem kell az adott csapat vezetőjén keresztül, úgymond hivatalos úton kommunikálniuk. A hagyományos vállalatnál ez már csak azért sem lehetséges, mert ott a lényeges információk a vezetőknél vannak (lásd 3. pont).

A technikai környezet is fontos

6. Orosz szerint azonban nem csak a szervezet működését érdemes optimalizálni. A munkakörnyezetet is megfelelővé kell tenni. Levenni minden olyan fölösleges terhet a fejlesztők válláról, ami elvonja őket a kreatív munkától. Egyes jól működő vállalatok ezért külön fejlesztőcsapatot tartanak fenn a belső fejlesztőkörnyezet folyamatos fejlesztésére.

7. És a magasabb fizetés... A modern vállalatok felismerték: ha hagyják a szoftvermérnököket úgy dolgozni, mint a stratupokban, akkor azzal jól járnak (a stratupok lényegében a szoftvermérnökök munkáját felhasználva növekednek), és ezt érdemes honorálni magasabb fizetéssel és nagyobb autonómiával. Orosz szerint ez tükröződik a Facebook vagy a Google bérpolitikájában is. Ha egy vállalat jól használja a mérnökeit, nem okoz gondot számára akár a piac fölötti béreket is kifizetni.