Interjú: egy CTO vallomásai 2.

Beszéljünk a stackről!

A főtechnológus - mert a CTO-ra ilyenképp is tekinthetünk - meghatározó szereplő a cég által használt "stack" vagyis a változatos platformok, technológiák, nyelvek kiválasztásában és bevezetésében, vagy épp kivezetésében. Nyilván rákérdeztünk mi is Pálfy Sándornál, hogy az eredetileg "faltól-falig" Microsoft-technológiára épülő LogMeIn a felvásárlásokkal hogyan színesedett és hogyan kezeli házon belül ezt a sokszínűséget.

"Ez jó kérdés, amellyel kapcsolatban a cégen belül is sokszor parázs vita van." - mondja Pálfy. "Eredetileg valóban sok Microsoft-technológia volt házon belül. Microsoft-platformokra épült az eredeti LogMeIn Pro, Rescue és join.me, de később, főleg az akvizíciók során sok új technológia jött be. Ilyenkor sokszor felmerül sok mérnök oldalán, hogy írjuk újra, mert ez nem jó, nem ismerjük, nem tudjuk üzemeltetni, stb. Például a LastPass szerver oldal jó része a PHP egyik dialógusában van implementálva. Ez egy statikus, erősen típusos, objektum-orientált nyelvekhez - mint amilyen a C# vagy Java - szokott fejlesztőnek idegen, sokszor „lenézett” környezet. Az ilyen szituációkban volt, amikor úgy döntöttünk, hogy legyen újraírás, volt, amikor csak refaktoráltunk. Ezekből egy idő után az a tanulság született meg, hogy a nulláról teljesen újraírni egy egyébként jól működő terméket a legritkább esetben érdemes, két ok miatt. Az egyik, hogy miközben mi mondjuk egy évet eltöltenénk újraírással, addig a versenytársaink elhúznának mellettünk valódi fejlesztésekben, funkcionalitásban, amit utána nagyon nehéz lenne ledolgozni. A másik pedig, hogy az újraírt kód nagyon sokszor ugyanannyi, vagy akár még több hibát tartalmaz, mint az elődje. Ezt számtalan tanulmány támasztja alá. Tipikus például a speciális esetek lekezelésének elmaradása.

Új fejlesztéseknél persze törekszünk egységes technológiákat, platformokat használni, de amikor egy akvizícióval jön be új szoftver (a LastPass és a Boldchat volt eddig a két nagyobb), akkor csak a legritkább esetben éri meg csak az egységesítés vagy kódtisztítás miatt újraírni. Inkább úgy dolgozunk, hogy ahol bele kell nyúlni, ott részenként, apránként újradolgozzuk és a sztenderdjeink felé visszük, de maga az újraírás a legritkább esetben éri meg."

"Egy fontos kérdés viszont, hogy melyek azok az esetleges hiányzó struktúrák vagy folyamatok, amelyek kötelezőek egy nagyvállalati környezetben: hogyan lehet CI/CD-t bevezetni, hogyan lehet automatizált tesztekkel lefedni a kritikus részeket, egy-egy funkciót kiszervezni külön service-ekbe - és azt már az adott feladathoz legcélszerűbb megközelítéssel írjuk meg. Ezek azok a területek, amelyek egy kisebb cég felvásárlásánál tipikusan hiányoznak, de a skálázhatósághoz elengedhetetlenek. Az újraírással kapcsolatban sok tévhit: a régi hibáit látod, az újét viszont még nem, emiatt utóbbi sokkal jobbnak tűnik. De a tapasztalat az, hogy az újraírt szoftverben is ugyanannyi hiba van, ugyanannyi strukturális probléma jön elő. Igen, a régi hibákat nem követjük el újra, de sok új hiba jön be. Például rengeteg edge-case, egyedi, speciális eset, amelyekre az előző fejlesztők tekintettel voltak és tapasztalat alapján megtanultak helyesen kezelni, ilyenkor feledésbe merül. Ezeket újra kell tanulni, ami megint hibákat, gyomlálni való bugokat és gyenge felhasználói élményt hoz.”

"Emiatt házon belül inkább az a kérdés, hogy hogyan tudunk több technológiát hatékonyan támogatni - nem pedig az, hogy hogyan hozzuk közös platformra a meglévő (és megszerzett) szoftvereinket. Az összeolvadás előtt csak a backend oldalon volt .NET-ben, Javában, C++-ban, PHP-ban, Node.js-ben és Rubyban írt kódunk - és biztos vagyok benne, hogy ezeken kívül volt még ott más is. Ehhez persze hozzáadódnak még a kliensoldali platformok, iOS, Android, Windows és MacOS, és jön még a csillió webes framework. Emellett rendesen használunk AWS-t és Azure-t is. Az előnye ennek az, hogy amikor egy új team elindul, akkor ők azt a technológiát tudják választani, ami szerintük a legjobb - hiszen házon belül már értünk hozzá, tudjuk támogatni."

"Összességében valamennyire próbálunk sztenderdizálni, ekkora méretnél ez már hangsúlyos, de főként a közös service-ek oldalán törekszünk egységesítésre." - vázolja a követendő irányt Pálfy. Az irány nem elméleti, azt már szervezeti szinten is erősen támogatja a LogMeIn belső platform csapata. "Van egy erős belső csapat, akik a közös LogMeIn platform service-eket adják: identitás (közös login és regisztráció), adat és üzleti intelligencia, és a kereskedelmi modulok, például az online vásárlás felülete. Ezek különböző fejlettségi fázisban vannak jelenleg, de a hosszútávú cél az, hogy ezek egységes szolgáltatásokként legyenek implementálva és üzemeltetve, és ezeket használja előbb-utóbb az összes termékünk. Ettől most még messze vagyunk, de a csapatok ott vannak, a service-ek ott vannak, folyamatosan azon dolgozunk, hogy efelé menjünk."

"Mindkét oldalon komoly probléma volt, hogy különböző csapatok ugyanazt implementálják pepitában nyolc helyen" - magyarázza a fő gondot Pálfy. Így az egyesüléstől várt szinergiák egy része az ilyen párhuzamos fejlesztések egyesítéséből fakad. "A legjobb példa erre az identitáskezelés, a beléptetés - régen ez egy egyszerű login-regisztráció volt. Ma ezt bonyolítja a kétfaktoros autentikáció, az SSO, az audit, a logok. Rendszerünk nézi például, hogy a belépés milyen IP-ről jön és annak az IP-nek milyen a története globálisan, például használták-e más szerverek támadására vagy illetéktelen belépésekre - ez szükséges a támadások kiszűréséhez. Ezeket nem akarjuk minden termékhez külön-külön kifejleszteni és karbantartani, inkább adunk egy belső szolgáltatást, amelyre minden termékünket felfűzzük. Ez nekünk méretgazdaságosságot nyújt, egy közös rendszert kell karbantartani és fejleszteni - annak fejlesztései pedig azonnal megjelennek egyszerre az összes termékben."

"A közös platform másik előnye, hogy sokkal jobb felhasználói élményt ad. Ha több termékre is előfizet, akkor a belépett felhasználónak rögtön meg tudjuk mutatni egy helyen az összes beállítását, az előfizetések státuszát is. Egy példa: ha épp lejárna a hitelkártya és újat kellene felvinnie, akkor azt elegendő lesz egy helyen megadni és érvényes lesz az összes termékre. Az ilyen pontokon tartjuk nagyon fontosnak a platformosítást és egységesítést."

Szervezeti kultúra -  érlelni organikusan?

A Szilícium-völgy startupjainál és nagyvállalatainál már nagyon fontos szempont a céges kultúra alakítása, de Európában is egyre inkább teret kap ennek tudatos alakítása. Pálfyt arról kérdeztük, hogy hogyan áll ehhez a LogMeIn - és hogyan kezelte a csapat a kérdést a masszív Citrix-összeolvadás nyomán. "A céges kultúrából nálunk az a legkézzelfoghatóbb, hogy milyen elvárásokat támasztunk magunkkal szemben, milyen viselkedést várunk el és tartunk normálisnak - a cafeteriástól a CEO-ig. Tehát mi az a viselkedés, mik azok az értékek, amelyek szerintünk a céget sikerre viszik. Ezt belsős dokumentumokban definiáljuk is, közérthető módon és rengeteg csatornán kommunikáljuk" - teszi le az alapokat a CTO.

"A legtöbb embernek nem mond sokat a szervezeti kultúra kérdése, mert nem olyan közegből jönnek, ahol tudatosan építették azt. Nekünk ez nagyon fontos, évek óta hangsúlyt fektetünk rá és a toborzástól a mindennapi munkáig nagyon odafigyelünk. Persze az összeolvadás nyomán nekünk is újra kellett gondolni, hogy hogyan is definiáljuk a céges kultúránkat."

"Ez cégről cégre változik, van rengeteg hozzáállás - és cégről cégre változik az is, hogy mi az, ami működik." Nagy kérdés, hogy a kultúra hogyan lesz kézzel fogható? "Mi már az interjúztatástól fogva nagyon odafigyelünk, hogy felmérjük, ezeket az értékeket, tulajdonságokat a jelölt hordozza-e vagy sem. Innentől kezdve a mentorálási időszakon át az értékelésekig ugyanazok az aspektusok jönnek elő újra és újra és újra. Segítjük az alkalmazottakat, hogy azt a viselkedési formát, amit elvárunk, elsajátítsák, eszerint éljenek, ennek megfelelően dolgozzanak. És ezt a teljesítménymérésben is kidomborítjuk. Így az értékelésben a faktorok közé tartozik, hogy segítesz-e a többi csapattagnak, kommunikálsz-e a többi csapattal, hogy mersz-e egyéni döntéseket hozni, és persze vállalsz-e felelősséget a döntéseidért. Ezek az interjútól kezdve a teljes alkalmazotti úton folyamatosan visszatérnek. Így épül ez organikusan."

De hogyan lehet egyesüléskor a kultúra problémáját kezelni? A Citrix GetGótól több alkalmazott érkezett, mint amennyivel a LogMeIn eredetileg rendelkezett. Nem hígítja ez a belső kultúrát? "Nagyon sok felvásárlás és összeolvadás kudarcát hozta már a világban, hogy olyan kultúrák kerültek egymás mellé, amelyek nem működtek jól egymással, a veszélyt így nyilván mi is jól láttuk. Konfliktusos esetben van, hogy az egyik csapat egy pillanat alatt elpárolog, elmennek a dolgozók mert nem érzik jól magukat. Ezzel nekünk nagyon nagy szerencsénk volt, már az első pillanattól, amikor a két cég felsővezetése először ült közös asztalhoz, látszott, hogy hasonló értékrendünk van, hasonló irányokba akarunk menni. Például nagyon sok hasonló projektünk volt folyamatban - kultúra területén is, de technológiai területeken is. Ugyanabból a motivációból ugyanabba az irányba tartott mindkét szervezet."

A puding próbája az evés, a szervezeti kultúráé pedig a konfliktushelyzet - egy összeolvadásnál pedig bőséggel akadt ilyen is - mondja Pálfy. "A kemény döntéseknél, amikor a két szervezet érdekei ütköznek és az egyik oldal úgy érzi, hogy az érvei háttérbe szorulnak és a másik csapat nyer, ott jönnek ki igazán a kulturális különbségek és a hasonlóságok. Hogy képesek-e a csapatok ezt megfelelően kezelni: egy erős, heves vita zajlik, amelyben ütköztetjük az érveket. De miután eldöntöttük, hogy merre van az előre, akkor mindenki képes feladni az addig védett álláspontját és magáévá tenni a közös döntést akkor is, ha nem értett vele korábban egyet. Nekünk fontos kulturális pillérünk, hogy ösztönzünk mindenkit, hogy szólaljon fel, védje az érveit, de amikor a csapat eldöntötte az irányt, akkor ő is beáll a sorba."

"A kultúrának érdekes része, hogy nagy hangsúlyt fektetünk a személyes kapcsolatra - ugyan rengeteg távmunkás eszközt fejlesztünk, cégen belül igyekszünk befektetni abba, hogy az egymástól távol dolgozó csapatok személyesen is megismerjék egymást. A németek rendszeresen látogassanak el Budapestre (és vissza), Európa, Amerika és India között is rengeteget utaztatjuk a csapatokat. Nagyon sok ilyen utazás van, ebbe tudatosan fektet be a cég, hogy a vezetőket illetve a csapattagokat egymással közelebbi ismeretségbe hozza. Ettől ugyanis később a távkommunikáció is sokkal jobban megy - a személyes találkozás előtt csak egy név, egy arc és egy pozíció, utána pedig egy ember és személyiség is társul hozzá."

"Egy érdekes különbség volt például a GetGo és a LogMeIn-kultúra között, hogy eddig a LogMeIn csapatok a telefonos távértekezleteken nem igazán használtak videót. A GetGónál viszont a videós kapcsolat is szinte kötelező volt az ilyen remote meetingek esetében. Ezt a közös cég átvette, mert sokkal hatékonyabb így kommunikálni. Egészen másképp viselkednek, egészen másképp figyelnek a résztvevők, el lehet kapni gesztusokat - az élő videó rengeteget hozzáad az élményhez."

Így jön ki az összeolvadás előnye

A fejlesztők a cég egyharmadát adják, a kétharmadot más csapatok teszik ki. A fejlesztőközpontok négy országban találhatók - Magyarország, Németország, az Egyesült Államok és India is jelentős kapacitással rendelkezik. "Az új LogMeIn európai és indiai fejlesztőbázisai nagyon erősek és továbbra is ezeket a központokat akarjuk erősíteni. Jelenleg a fejlesztők kétharmada az európai központokban dolgozik - az 1000-1100 mérnökből Budapesten van 350, Németországban további 350, az európai és indiai központok pedig tovább fognak majd erősödni."

"Azt viszont már most el tudjuk mondani, hogy a termékdöntések nem a régióktól függnek - a fejlesztési feladatokat könnyen tudjuk régiók között mozgatni, jelenleg Budapesten fejlesztünk olyan terméket, amin eddig a német központ, Karlsruhe dolgozott. Karlsruhe pedig átvett egy terméket a nyugati parttól. Ilyenkor a csapatok elutaznak egymáshoz, átadják a tudást és nagyon gyorsan átveszik a terméket. Az, hogy eddig ki mit fejlesztett valamilyen szinten fontos, hiszen az újratanulás azért időigényes, de inkább az a vezérelv, hogy melyik csapat a legalkalmasabb az adott területet tovább vinni. Vannak vezérelveink erre: próbáljuk minimalizálni, hogy egy terméket egyszerre több helyszínen fejlesszünk, igyekszünk maximum két helyszínre szorítani egy terméket, lehetőleg azzal a feltétellel, hogy ők ne 12 órányi távolságra legyenek egymástól. A lényeg, hogy a munka mozog, az emberek pedig maradnak."

Interjúnk első része itt olvasható.