A cég

A történet egy körülbelül 50 főt foglalkoztató szoftverfejlesztő cégről szól. Magyarország egyik – ha nem a legnagyobb – online portálját fejlesztik és üzemeltetik egy bizonyos szektorban.

A szektort szándékosan nem nevezem meg, mert az alapján már túlságosan könnyen azonosítható lenne a cég.

A lényeg, hogy nem egy néhány fős garázscégről beszélünk. Egy komoly vállalkozásról van szó, komoly rendszerrel, komoly ügyfélkörrel és havonta százmilliós nagyságrendű forgalommal.

Hogyan kerültünk kapcsolatba velük?

CRM-rendszer fejlesztőjeként kerültünk kapcsolatba a céggel.

A feladatunk az volt, hogy a náluk keletkező bizonyos adatok automatikusan bekerüljenek az általunk fejlesztett CRM-rendszerbe, a megfelelő partnerekhez.

Technikailag egy egyszerű-közepes komplexitású, XML-alapú integrációs fejlesztésről beszéltünk. Első ránézésre semmi olyasmiről, aminek különösebb akadályt kellett volna jelentenie.

Legalábbis ezt gondoltuk.

A kapcsolatfelvétel

Mint minden hasonló integrációs fejlesztésnél, a folyamat azzal kezdődik, hogy azonosítjuk a másik oldalon azokat a technikai embereket, akik ismerik az érintett rendszert.

Ha van API-dokumentáció vagy más technikai leírás, azt átnézzük. Ha nincs – mint ebben az esetben –, akkor szükség van egy közös technikai tervezésre, ahol átbeszéljük az adatstruktúrát, a kommunikáció módját és a szükséges fejlesztéseket.

Megkaptuk tehát annak a fejlesztőnek az elérhetőségét, akiről azt mondták, hogy tud nekünk segíteni.

Küldtünk neki egy e-mailt néhány lehetséges időponttal.

Aztán vártunk.

Nem jött válasz.

Megpróbáltuk telefonon is elérni, de nem vette fel. Vártuk, hogy visszahívjon.

Nem hívott.

Újabb e-mail.

Újabb egy hét várakozás.

Közben természetesen az eredetileg felajánlott időpontjaink is rég elmúltak, ezért küldtünk újabb időpontokat.

Megint semmi.

Ezen a ponton már heteket veszítettünk egy olyan fejlesztésből, amely technikailag még el sem kezdődött.

Eszkalálunk

Végül jeleztük a problémát a fejlesztő felettesének, és segítséget kértünk.

A beszélgetés nagyjából így zajlott:

– Hű, ő most nagyon elfoglalt egy másik fejlesztéssel. Ha azzal végez, majd visszajelez.

– Értem. És körülbelül mikor végez vele?

– Nem tudom. Lehet, hogy egy-két hónap múlva.

– És nincs valaki más, aki tudna nekünk segíteni?

– De, van. Összekötlek vele.

– Szuper, köszönöm.

Meg is történt a kapcsolatfelvétel.

A második fejlesztővel meglepően könnyen sikerült összehozni a közös technikai tervezést.

Azt hittük, végre haladunk.

Csakhogy volt egy apró probléma.

A második fejlesztő gyakorlatilag semmit nem tudott arról, hogyan működik az a rész, amire nekünk szükségünk volt.

Szinte minden érdemi kérdésünkre ugyanaz volt a válasz:

„Ezt majd meg kell kérdeznem tőle.”

Tőle.

Az első fejlesztőtől.

Attól, akit hetek óta próbáltunk elérni.

A meeting végére nagyjából oda jutottunk, ahonnan elindultunk: a második fejlesztő beszél az elsővel, majd visszajelez nekünk, és akkor tudunk továbblépni.

Aztán megint vártunk.

Közben természetesen a saját ügyfelünkkel nekünk kellett folyamatosan kommunikálnunk arról, hogy miért nem halad a fejlesztés, és mikor tudunk végre továbblépni.

Teltek a hetek.

Válasz továbbra sem érkezett.

Aztán egyszer csak jelentkezett

Egy nap végre befutott az üzenet az első fejlesztőtől:

most már van ideje foglalkozni velünk.

Megbeszéltünk egy időpontot, leültünk közösen tervezni, és ekkor kezdett igazán érdekessé válni a történet.

A meeting során fokozatosan kiderült, hogy ez az ember nem egyszerűen „ismeri” a rendszert.

Ő ismeri a rendszert.

Gyakorlatilag egy személyben ő volt az az ember, aki átlátta a teljes portál működését.

A többi fejlesztő ismert belőle bizonyos részeket. Voltak saját területeik, tudtak fejleszteni rajta, és természetesen nem arról volt szó, hogy rajta kívül senki nem értett semmihez.

A teljes kép azonban egyetlen ember fejében állt össze.

Egy olyan rendszer teljes képe, amely havonta százmilliós nagyságrendű forgalmat bonyolított.

És itt jön a történet egyik legérdekesebb része.

Ez az ember nem volt alapító.

Nem volt tulajdonos.

Nem volt ügyvezető.

Nem volt CTO.

Egy vezető fejlesztő volt. Papíron.

A valóságban viszont ő volt a cég egyik legfontosabb embere.

A meeting

Később sor került egy nagyobb egyeztetésre is, immáron más témában.

Jelen voltak a mi ügyfelünk képviselői, a másik cég képviselői – köztük természetesen a fejlesztő – és mi is.

Életem egyik legszürreálisabb üzleti meetingje volt.

Nagyon hamar kialakult egy furcsa helyzet.

A cég vezetői helyett gyakorlatilag a fejlesztő tárgyalt.

Felmerült egy kérés.

Nem megvalósítható.

Felmerült egy másik.

Ezt talán meg lehet csinálni, de legkorábban hat hónap múlva.

Újabb ötlet.

Nem.

Önmagában persze azzal nincs semmi probléma, ha egy fejlesztő azt mondja valamire, hogy technikailag nem jó ötlet. Sőt, pontosan ez is a feladata.

A probléma az a flegma, lekezelő stílus, ahogyan mindezt előadta.

Nemcsak velünk vagy az ügyféllel beszélt így.

A saját főnökeivel is.

És ami számomra igazán megdöbbentő volt: a vezetők láthatóan nem nagyon mertek mit kezdeni a helyzettel.

Nem állították le.

Nem tették helyre.

Nem vették vissza a meeting irányítását.

Gyakorlatilag hagyták, hogy ő diktálja a feltételeket.

A meeting végére a mi ügyfelünk képviselői teljesen kiakadtak. Egyértelműen jelezték, hogy ilyen formában nem tudnak együtt dolgozni a céggel.

És ekkor állt össze bennem a kép.

Ki volt valójában a főnök?

Papíron természetesen megvolt a szervezeti hierarchia.

Voltak tulajdonosok.

Voltak vezetők.

Voltak fejlesztők.

Csakhogy a valódi hatalmi struktúra teljesen máshogy nézett ki.

Mert tegyünk fel egy nagyon egyszerű kérdést:

Mi történne, ha ez az ember holnap reggel bemenne a főnökéhez, és azt mondaná, hogy kétszer akkora fizetést szeretne?

Mit mondhatna erre a cégvezető? Hogy nem?

És ha erre a fejlesztő azt mondja:

Rendben, akkor felmondok.

Mi történik utána?

Az az ember távozik a cégtől, akinek a fejében ott van egy üzletileg kritikus, havonta százmilliós forgalmat kezelő rendszer teljes működése.

Lehet, hogy a rendszer másnap még működik.

Valószínűleg működik egy hónap múlva is.

De mi történik az első komoly hibánál?

Mi történik a következő nagy fejlesztésnél?

Ki tudja megmondani, hogy egy tíz évvel korábbi döntés miatt miért működik valami úgy, ahogy?

Ki látja át, hogy egy módosítás milyen másik három rendszerre lesz hatással?

A válasz minden esetben ugyanaz:

az az ember, aki éppen felmondott.

Ebben a pillanatban a munkáltató és a munkavállaló közötti hagyományos erőviszony gyakorlatilag megfordul.

A munkaköri megnevezés már teljesen mindegy.

A szervezeti ábra is.

A tulajdonosi struktúra is.

Mert a működés szempontjából ő lett a kulcsember.

És ez nem a fejlesztő hibája

Itt van a történet szerintem legfontosabb része.

Nagyon könnyű lenne azt mondani, hogy a probléma a fejlesztő volt.

Szerintem nem.

Lehet vitatkozni a kommunikációs stílusán, a hozzáállásán vagy azon, hogyan kezelte a partnereket.

De a kulcsember-függőséget nem ő hozta létre.

Azt a cég hozta létre.

Évek alatt kialakult egy helyzet, amelyben egy üzletileg kritikus rendszer tudása egyetlen embernél koncentrálódott.

Nem volt megfelelően szétosztva a tudás.

Nem volt megfelelő helyettesíthetőség.

Nem volt olyan dokumentáció és folyamat, amely lehetővé tette volna, hogy más is átvegye a szerepét.

A szervezet pedig ezt egészen addig valószínűleg nem érezte komoly problémának, amíg szükség nem lett volna valaki másra.

Tanulság

Cégvezetőként érdemes időnként feltenni magadnak egy nagyon kellemetlen kérdést:

Van olyan ember a cégemben, akinek a holnapi kiesése komolyan veszélyeztetné a működésünket?

Ha a válasz igen, akkor nem az a probléma, hogy van egy nagyon értékes kollégád.

Az jó.

A probléma az, ha nincs B terved nélküle.

A kritikus tudásnak dokumentálhatónak és átadhatónak kell lennie. A fontos folyamatoknak nem egyetlen ember fejében kell létezniük. A rendszerekhez több embernek kell megfelelő szintű hozzáféréssel és tudással rendelkeznie.

És minél fontosabb egy rendszer vagy folyamat a vállalkozás működése szempontjából, annál veszélyesebb, ha egyetlen emberhez kötődik.

Mert onnantól nem az a kérdés, hogy ő fontos-e a cég számára.

Hanem az, hogy a cég képes-e nélküle működni.

Ha pedig a válasz az, hogy nem, akkor valójában nem ő függ a cégtől.

A cég függ tőle.