Mellékleteink: HUP | Gamekapocs
Keres

Interjú: egy CTO vallomásai

Gálffy Csaba, 2017. október 18. 14:59

Pálfy Sándorral, a LogMeIn műszaki vezérigazgatójával beszélgettünk a Citrix-üzletág felvásárlásáról - és arról, hogy egy ilyen sok milliárd dolláros gigabizniszben mi a CTO szerepe.

Az év elején hivatalosan lezárta a LogMeIn a Citrix GoTo üzletágának felvásárlását. A gyakorlatban az 1,8 milliárdos biznisz hivatalossá válásával indult a két entitás tulajdonképpeni összeolvadása, ami két informatikai cég esetében különösen izgalmas feladatnak számít. Ezért kaptunk az alkalmon, amikor Pálfy Sándor, a LogMeIn műszaki vezérigazgatója (angolosan CTO-ja) Budapesten járt, és leültünk egy hosszúra nyúlt beszélgetésre: tudomásunk szerint nincs még egy magyar informatikai szakember, akinek ekkora összeolvadást kellett előkészítenie és levezényelnie.

CTO - mit is jelent?

Ahogy a legtöbb szakmai titulus, a CTO is roppant képlékeny szerepkört jelent, szervezettől függően egészen más lehet a valós feladat. "A CTO-k tipikusan három dolgot csinálnak - vagy ezek valamilyen kombinációját. Amikor elindul egy kis cég, az összes technológia az övék - belső IT, termékfejlesztés és előremutató technológiák. Aztán ahogy a cég nő, ezek elkezdenek leválni: először általában az IT, a második szokott lenni a fejlesztés (software engineering) a napi szinten fejlesztéshez használt technológiákkal (.NET, Java, stb.), így végül fókusszá tevődnek a jövőbemutató technológiák és az innováció." - mondja Pálfy.

palfy_sandor

Ma már a LogMeIn is nagyjából itt tart, az összeolvadás lezárásával Pálfy a belső IT-val, az információbiztonsággal, és az innovációs projektekkel foglakozik. "Közvetlenül az összeolvadás előtt felvettünk egy CIO-t, aki nekem jelent a hierarchiában, de a belső IT-t gyakorlatilag már ő viszi. Vele stratégiai szinten dolgozom együtt, a mindennapi döntéseket már ő hozza."

Pálfy Sándor egyébként webfejlesztőként kezdte a LogMeIn budapesti irodájában 2004-ben, innen a ranglétrát végigjárva lett 2013-ban műszaki alelnök (VP Technology), majd 2014-ben Chief Technology Officer, vagyis CTO. "Gyakorlatilag minden létező pozíción végigmentem, ami szoftver- és termékfejlesztés területén létezik" - mondja. "Két éve váltottam infrastruktúrára, az adatközpontok, belső IT, biztonság, és az üzleti rendszereink, mint a Salesforce tartoztak hozzám."

Az 1,8 milliárd dolláros összeolvadás ezek mindegyikét alapvetően rajzolta át, a két nagy szervezet egyesítése, a párhuzamos rendszerek összevonásának jelentős része a CTO feladatkörébe tartozik - de nem egyenletesen. "Az összeolvadás során nekem a fő szerepem a due diligence alatt volt. A rendszerek tényleges integrációját, ami egy több hónapig tartó folyamat, a dedikált csapatok nagyrészt saját hatáskörben kezelik."

Hamarosan azonban változik megint a szerep: "Az összeolvadás lezárásával az IT mellé új feladatként bejött az innovációs program, a „következő lépés utáni” technológiákban rejlő piaci lehetőségek megtalálása. A termékeinkben mindig is jelen volt az innováció: folyamatosan reagálunk a piaci igényekre, a technológiai változásokra, az ügyfeleink kéréseire. Az innovációs program ennél megy tovább egy lépéssel. Megpróbáljuk megfejteni, hogy mik azok a trendek, amik alapjaiban fogják megváltoztatni, hogy hogyan élünk, hogyan dolgozunk, hogyan kommunikálunk, és mindez hogy fog hatni a jelenlegi és jövőbeli ügyfeleinkre, termékeinkre. A Blockchain, AR/VR, NLP, Machine Learning, Mobile és Cloud Computing néhány példa a jövőt alakító technológiákra, ezekkel mind foglalkoznunk kell majd. Itt van már kutatás, vannak prototípusok, és az én szerepem is ebbe az innovációs irányba tolódik."

A gyakorlatban ez egy igazi belső startup-inkubátor létrehozását jelenti, amit Pálfy vezet: "Ha valakinek van egy ötlete a cégen belül, akkor milyen lépésekkel juthat oda, hogy kapjon egy kis időt, befektetést, csapatot, és el tudja kezdeni a megvalósítást a cégen belül. Konkrétan kis startupokat kezdtünk el üzemeltetni a cégen belül - és ezek nagyon másképp működnek, mint a hagyományos szoftverfejlesztés."

Kötelező óvatosság!

No de térjünk vissza az összeolvadásra - ami egyértelműen az év sztorija a LogMeInnél! Ez a sztori pedig a due diligence-szel kezdődik. A due diligence (talán kötelező óvatosságnak fordíthatnánk) egy tipikusan amerikai jogi kifejezés, a gyakorlatban azt a folyamatot jelenti, amelyben a két szerződő fél felméri egymást és a szerződés potenciális hatásait. Ennek a tőzsdei cégek esetében különös jelentősége van, a cégek vezetése ugyanis felelősséggel tartozik a részvényesek felé, hogy a tranzakció tényleg értéket teremt és nem károsítja meg a befektetőket. Ezt a folyamatot a LogMeIn és a Citrix GoTo üzletág összeolvadásánál a két cég felsővezetése és az általuk felkért független tanácsadó cégek végezték, ennek függvényében adott az összeolvadásra ajánlatot végül a LogMeIn. Mindjárt látni fogjuk, hogy ez pontosan hogyan is nézett ki - belülről.

"A due diligence egy auditálási folyamat. Részletesen feltérképezzük a két összeolvadó vállalat üzleti, pénzügyi, szervezeti, jogi és technológiai hátterét, felmérjük az összeolvadással vagy felvásárlással járó kockázatokat, és próbálunk egy pontosabb becslést adni az összeolvadás utáni állapotra, főleg üzleti, pénzügyi szempontból. Ebben természetesen a CTO-nak is fontos szerepe van." - mondja Pálfy.

"Meg kell nézni, hogy kijön-e a matek. Az egyik legfontosabb eleme ennek a tranzakciónak az ún. költség-szinergia volt: tudjuk-e rövid időn belül egységesíteni a két összeolvadó cég hasonló, párhuzamosan üzemelő rendszereit, adatközpontjait, programjait, úgy, hogy ezzel az összevont cégben jelentős kiadásokat tudjunk megspórolni. Mindössze néhány hét alatt, és minimális számú ember bevonásával kellett előállnunk egy konkrét megvalósítási tervvel, ami alapján Bill (a LogMeIn-CEO) publikusan bejelentheti, hogy a kombinált cég 100 millió dollárral olcsóbban tud majd működni, mint a két szervezet külön-külön."

Az IT egyébként nem szokott az akadályozó tényezők közé tartozni, ezen a területen inkább azt szokták felmérni, hogy milyen erőfeszítéssel jár majd az integráció, mennyit lehet spórolni az összevont működésen, és mindezt milyen gyorsan lehet végrehajtani.

A due diligence során rendkívül fontos hogy ne szivárogjon ki semmilyen információ a jövendőbeli üzletről: "Nagyon szigorúan szabályozott az ilyen ügyletek előkészítésénél az információáramlás, a bennfentes kereskedelem elkerülése miatt. A döntés előkészítési folyamata maga is szenzitív információ és korlátozni kell azt, hogy hány ember tud erről. Ha a due diligence csapaton kívül bárki tudomást szerez arról, hogy mi készül, az onnantól bennfentes kereskedelem gyanúját veti fel. Csak egy példa: a tőzsdefelügyelet a folyamat után küldött egy részletes listát arról, hogy ki kereskedett a LogMeIn részvényekkel, és hogy ezek közül ismerünk-e valakit - ilyen szinten megy bele a hatóság."

A due diligence egyúttal arra is esélyt ad, hogy a csapatok elkezdjék előkészíteni az összeolvadást - értelemszerűen a szinergiákat is e terv birtokában lehet már számolgatni. "Mindkét oldalon felmérjük, hogy a rendszereink között mi a hasonlóság, mi a különbség, hogy néznek ki a struktúrák, csapatok, és a rendszerek. A folyamat végére el kell készülnie egy tervnek, ami leírja az integrációt stratégiai szinten, és azt, hogy a szinergiákat hogyan lehet elérni. Ez utóbbira egy nagyon erős kijelentést kell tenni, alátámasztva: hogyan tudjuk a költségeket lefaragni, spórolni a rendszereken (cost synergy) és hogyan tudjuk közösen a bevételeket növelni (revenue synergy)."

"Amikor először ültünk le a GetGo csapattal, akkor mindenkinek ott ült a "párja" a másik szervezetből - talán nyolc-nyolc ember volt ott mindkét oldalról. Ez a csoport dolgozta ki az összeolvadás tervét és becsülte meg az összeolvadás pénzügyi vonzatát - és mondhatom, hogy az első becslés néhány százalékon belül volt a később elkészült sokkal részletesebb tervhez képest." - magyarázza Pálfy.

Intenzív hetek

"Az elején, az előkészítési fázis kezdetén volt egy intenzív 3-4 hét, amikor éjjel-nappal-hétvége kellett a feladaton dolgozni. A titoktartás hátránya, hogy kis csapatnak kellett ezt a munkát elvégeznie, így nagyon kevés feladatot lehetett delegálni. Ebben a fázisban csak a párokon, a két cég azonos státuszú (például a két CTO), együtt dolgozó tagjain múlik a siker." - emlékezik vissza a szakember. "Ilyenkor komoly kihívás, hogy a beszélgetéseket stratégiai, magas szinten kell tartani, anélkül, hogy túlzottan belemennénk a részletekbe, mert ezzel csak az idő menne el. A másik oldalon viszont kell annyi részletesség, hogy az elkészült integrációs terv ténylegesen működjön majd, és a jelentés konkrét, megbízható számokat tartalmazzon, ami alá tudja támasztani az összeolvadás üzleti modelljét. Ez az alaposság magától értetődőnek tűnik, de a külső tanácsadóink elárulták, hogy bizony vannak olyan összeolvadások, ahol nem tesznek ekkora energiát a tervezésbe, felületes becslések alapján jelentik be az összeolvadás várható eredményét, ami borítékolhatóan kapkodáshoz, kényszerű döntésekhez, vagy a részvényár zuhanásához vezet."

Pálfy számára pedig ez volt a legizgalmasabb periódus: számít az intuíció, hogy milyen irányokban érdemes gondolkodni, és a tapasztalat segít abban, hogy ezen az optimális absztrakciós szinten maradjon a beszélgetés. A siker pedig nagyrészt a párosokon, az ő együttműködési hajlandóságukon múlik: mivel csak korlátozottan van lehetőség belenézni a másik fél adataiba (hiszen ha meghiúsul az üzlet, továbbra is versenytársak maradnánk), így sokszor érzés alapján kell megtalálni, hogy az összeolvadás során melyek lesznek a problémás (vagy épp ígéretes) területek, amelyekkel mélyebben érdemes foglalkozni. Ez a periódus pedig másról sem szól, mint a folyamatos munkáról: "Ilyenkor a telefont hajnali egykor is felveszed, és ha neked jut eszedbe valami, akkor te is bármikor fel tudod hívni a partnert és tudsz kérdezni. Ez nagyon izgalmas, nagyon intenzív folyamat, ami ekkora méretben nem sokszor adódik az ember életében."

A feladatot bonyolítja, hogy ezen a ponton a cégek még de jure versenytársai egymásnak, így az adatokat csak szigorúan kontrollált úton tudják egymással megosztani, különösen a folyamat legelején: "Amit én akartam kérdezni, azt elmondtam a mi integrációs partnerünknek, aki elmondta az ő partnerüknek, az pedig elmondta annak az embernek, akiről szó van. Ő feldolgozta a kérdést és ugyanezen az úton jött meg a válasz." - emlékezik vissza Pálfy. És hogy lehet ilyen környezetben hatékonyan dolgozni? Például alapos felkészüléssel: "Bár ez a folyamat nyilvánvalóan kiemelt prioritást kapott mindkét cégnél, nem szabad elfelejteni, hogy ugyan ezek az emberek feleltek a napi szintű működésért is. Kulcsfontosságú volt, hogy ha van egy szabott, egy órás, közvetlen megbeszélés, amin minden fél benn ül, akkor mindenki nagyon alaposan felkészüljön az adott meeting témáiból, kéznél legyenek a háttér információk, adatok, hogy az egy órában az összes kérdéseden végig tudjunk menni és a döntéseket ott helyben meg tudjuk hozni" - magyarázza.

Ráadásul mindezt az ilyenkor szokottnál sokkal erősebb időprés alatt kellett lezongorázni. A Citrix, a tulajdonképpeni eladó fél ugyanis épp egy drámai átszervezésen esett át - a vezetés pedig ígéretet tett arra, hogy 2016 végére eldönti (és hivatalosan be is jelenti), hogy mi lesz a GoTo üzletág sorsa - az eredeti tervek szerint a részleg vagy eladósorba kerül, vagy önálló cégként tőzsdére megy. Ez egy fix dátumot adott a fúzión dolgozó csapatoknak, a bejelentés időpontjára le kellett tenni az asztalra a jelentést, amiből egyértelműen kiderül: megéri-e belevágni az egyesülésbe?

A rendkívüli tempónak Pálfy szerint voltak pozitív hozadékai is, ugyanis már már ebben az előkészítési fázisban összekovácsolódott a felsővezetői csapat és megteremtett egy nagyon jó és személyes kontaktust a két fél között. Ez később, a konfliktusosabb időszakban jött jól, a csapat egyszerű telefonhívásokkal is fel tudott oldani és el tudott simítani komoly problémákat.

Az időprés a fókuszált munkavégzésen is segített: "Az ember hajlamos belemenni a kis hitvitákba, de ezeket egyszerűen kényszerből el kellett hagyni és mindkét fél nagyon pragmatikusan, fókuszáltan kellett hozzáálljon. Olyan döntések, amivel máskor akár hetekig is elmolyoltunk volna, kényszer alatt két óra alatt megszülettek." - mondja Pálfy. Neki személyesen ez nem okozott komoly gondot: "A személyes élmények közül nekem ez volt a legjobb, mert én egyébként így szeretek dolgozni, ezzel a tempóval. Egy ekkora méretű üzletet 4-5 hét alatt A-tól Z-ig úgy átnézni úgy, hogy a végén határozottan tudod állítani, hogy ennek így van értelme, tudjuk vállalni, és a szinergiák kapcsán is tudsz egy viszonylag pontos becslést letenni az asztalra."

Végre együtt

Az előkészítés után jön a tulajdonképpeni összeolvadás, a publikus bejelentés után már be lehet vonni sokkal több embert, a néhány tucat bennfentesről hirtelen nagyra nő az egyesülést segítő csoport. "Mivel korábban egyik cég sem csinált még ekkora tranzakciót, az integrációt segítendő felvettünk egy volt CIO-t, aki már nagyon sok ilyen összeolvadást végigvitt - ő kapott egy kis csapatot, nekik pedig semmi más feladatuk nem volt, mint magát az integrációs folyamat megtervezni, koordinálni és végigvinni. Ez egy teljes munkaidős állás, egy konkrét ember, akinek semmi más dolga nincsen, mint a PMO (projektmenedzsment) csapatával abszolút magas szintről koordinálni a nagyjából tíz funkcionális egység összeolvadását. Ezek közé tartozik a HR, az IT, a sales-rendszerek, a customer care rendszerek." - mondja Pálfy.

A sales egy érdekes terület: mindkét cég Salesforce rendszert használt, de a kialakított struktúrák, folyamatok, adatszerkezetek nagyon különböztek. "Ilyenkor két stratégia lehetséges: az egyik, hogy egy koncentrált, viszonylag fájdalmas de rövid periódus alatt ezeket összevonod és hamar egységessé teszed. A másik egy lassú, 9-12 hónapon át, lépésről lépésre zajló migráció, amely azzal jár, hogy ez idő alatt mindenki két rendszer használ.” - vázolja a dilemmát. "Mi a sales-nél tudatosan hoztuk azt a döntést, hogy a rövid stratégiát követjük és ez be is jött. Fájdalmas volt és sok probléma volt vele, egy intenzív három hónapos periódusban nehezen mentek a dolgok, elakadtak a rendszerek itt-ott, cserébe így a sales csapat sokkal hamarabb tudott a közös stratégiára és végrehajtásra koncentrálni. Ezt jól illusztrálja, hogy a kombinált sales rendszert használva az értékesítők 90 százaléka adott már el mindkét termékportfólióból - az eredetileg kitűzött 30-40 százalékot ez látványosan felülmúlja."

És mennyire volt problémás ez a néhány hónap? Megoszlanak a vélemények: "Akik nem éltek még át hasonló méretű összeolvadást, azok panaszkodtak, hogy akadoztak a rendszerek, döcögős volt az átállás. Azok viszont, akiknek már volt összehasonlítási alapjuk, azt mondták, hogy rendkívül gyors és relatíve fájdalommentes volt." Mert az iparágban a tipikus átfutási időszak 9-12 hónap, ezt harmad-negyed ennyi idő alatt lezongorázni tényleg merész vállalásnak bizonyult - de a folyamat gyakorlatilag ezzel le is zárult. Fél évvel a rajt után az összes nagyobb rendszernél befejeződött az átalakítás.

Testreszabott horror

A Salesforce esete különösen érdekes. Ugyan mindkét csapat Salesforce-ot használt, maga a kialakított struktúra teljesen eltérő volt: "Ez a platform ugyanis nagyon bonyolult, rengeteg integrációval rendelkező állatfaj, teljesen a szervezet igényeire szabható - amit persze mindkét vállalat meg is tett, így hiába használta mindkettő papíron ugyanazt, maguk az üzleti folyamatok nagyban különböztek." - mondja Pálfy, és egy példát is felhoz: a GoTo-nál a megújuló licencek túlnyomó többsége havi, a LogMeInnél túlnyomó többségben éves konstrukcióban futott, az eltérő piaci stratégiának megfelelően. Ilyenkor először ezeket a folyamatokat kell közösíteni, és azután a rendszereket utána húzni. Ez tehát nem csak informatikai munka, hanem megosztott feladat a belső IT-csapat és a sales operation csapat között - ez utóbbi pedig egy másik részleg, az értékesítéssel foglalkozó egység része. "Az IT felel a rendszerek üzemeltetéséért, a kitalált szabályok és folyamatok implementációjáért, a rendszer testreszabásáért. A szabályokat, a működést viszont a sales operations találja ki, ők dolgozzák ki az értékesítés mechanikáját, folyamatait." - fogalmaz Pálfy. "Így az integráció is velük, a sales operations csapattól indul, de ez egy nagyon szoros együttműködés a két szervezeti egység között - a két céggel számolva tehát közvetlenül négy csapat együttműködése kellett az átálláshoz."

A belső IT-t tekintve érdekes csavar a történetben, hogy a GetGo nem egy önállóan működő cég volt, hanem a Citrix éppen leválóban lévő egyik üzletága. Tehát nekik az összeolvadásig a Citrix adta többek között az IT és biztonsági szolgáltatásokat, sok ilyen funkció ott egyszerűen nem volt meg, éppen ekkor kezdték ezeket házon belül kiépíteni. "Ebből a szempontból a klasszikus IT rész, mint a rendszerek, a hálózatok, az Active Directory viszonylag egyszerűnek bizonyult, mivel az (önálló) GetGónál nem épültek ki még ezek a struktúrák, így az összeolvadás során egyszerűen a LogMeIn rendszereit vitte tovább a kombinált szervezet." - mutat rá Pálfy.

Mechanikus összeboronálás

És hogyan áll neki egy CTO két ekkora szervezet összeolvasztásának? "Az IT oldalon viszonylag egyszerű volt a feladat, ahol az üzleti egységek nagyjából hasonlítanak, ott a rendszerek is hasonlítottak, még akkor is, ha egy oldal A-t, a másik B-t használt." - mondja Pálfy. Persze az egyszerű nem azt jelenti, hogy ne lett volna rengeteg munka: "Több száz különböző rendszerről beszélünk, a puszta számok miatt előjönnek olyan rendszerek, amelyekre nem is gondoltunk. Mikor kapcsolnánk már be az integrációt, akkor derül ki, hogy hoppá, van még három olyan rendszer, amiről eddig nem volt szó. Még az integrációs folyamat elején komoly energiát fektettünk abba, hogy az összes rendszert leltárba vegyük mindkét oldalon, mégis még egész kései fázisban is bukkantak elő komplett új rendszerek."

"Sokkal nehezebb feladat a folyamatok integrálása, ahol sok konfliktus van és ahol a részletek nagyon-nagyon számítanak. A nagy, kritikus rendszereknél az a tanulság, hogy nincs más mód: az üzemeltetőket be kell zárni egy szobába egy hétre és A-tól Z-ig végig kell menni az folyamat összes lépésén és annak minden paraméterén. Konkrétan a Salesforce esetében több száz ilyen lépés és paraméter lehet, aminek csak a ledokumentálása több tucat oldalt tett ki. Ilyen esetekben tényleg az van, hogy egy hétig egy fizikai helyen összeülnek a csapatok és apró lépésenként veszik végig, hogy 'nálunk ez így van, nálatok ez úgy van', és tervezik meg az új folyamatot."

Ez pedig egészen extrém megoldásokat igényelt. "Adott esetben előfordult, hogy húsz ember repült kontinensek között egy hétre ilyen maratoni feladatokra, de erre szükség van, hogy együtt tanulják újra az átvett rendszereket és hozzák meg a döntéseket: hogyan működjön a közös rendszer. Ezzel már el is indul e közös rendszer implementációja, ennek első lépéseit tették meg ezek az összevont csapatok. A tapasztalat az, hogy legtöbbször nem lehet a gordiuszi csomót valamilyen ötletes módon megoldani, hanem a kétszer tíz vagy kétszer húsz embernek össze kell ülni egy hétre és nekik kell ezt az aprólékos munkát elvégezniük."

Ki nyer a végén?

Az összeolvadásnál az is végig izgalmas kérdés, hogy melyik oldalról veszi át a közös szervezet a gyakorlatokat, folyamatokat. "A LogMeIn az IT biztonságban jár nagyon sok cég előtt, így adta magát, hogy ezen a területen a LogMeIn struktúrái maradjanak meg: például a termékeink mindegyikével követjük a Microsoft által kidolgozott Security Development Lifecycle metodológiát. Sokan cég állítja, hogy ezt ők is csinálják, de a gyakorlatban legtöbbször nagyon messze van attól, hogy erre konkrét csapat legyen, az eredményeket mérjék, a legfelsőbb, executive szinten is figyeljék. Ez egy módszertan, de nem egyenletesen kidolgozott, például a számszerű mérése nincs jól definiálva az eredeti metodológiában, ezt a LogMeIn házon belül találta ki." - fejti ki az egyik példát a szakember. „Mi ezt hosszabb ideje implementáltuk - a LogMeIn legelső termékei (például az eredeti LogMeIn Pro) is roppant érzékenyek biztonsági szempontból, így a szervezetben mindig megvolt ennek a lenyomata. Néhány éve pedig nagyon tudatosan úgy építkezünk, úgy védjük az infrastruktúrát is, és úgy fejlesztjük a szoftvereket is, hogy a security checkpointok és best practice-ek beépülnek a mindennapi munkába. Talán a legjobb példa, hogy van egy security champion hálózatunk, amely minden egyes fejlesztőcsapatba delegál legalább egy szakembert, aki a biztonságot képviseli. Minden egyes scrum teamben van képviselője a security-nek, ami nagyon meglátszik a mutatóinkon és a hibákon. Ők bármikor segítséget tudnak kérni a központi, biztonsági csapattól, másrészt oda-vissza tudnak közvetíteni a célkitűzésekkel, irányokkal kapcsolatban is. A közös cégben is ezt a gyakorlatot vittük tovább.”

"Visszafelé, a GetGótól is érkeztek jó gyakorlatok - ez részben annak köszönhető, hogy az egy másfélszer akkora csapat, így sok struktúra jobban ki volt dolgozva." - mondja Pálfy. Egy ilyen példa az adatközpontok és a termékek felügyelete: "A LogMeIn-nél a monitorozás főleg riasztásokra épült, amire egy ügyeletes csapat reagált. A GetGo-nál viszont egy dedikált csapat két helyszínen, Santa Barbarában és Bangalore-ban, 24/7 a TV kijelzők előtt ültek egy kifejezetten erre kialakított helységben. Ezen a szinten ez már szükséges, így itt a ezt a működési formát vettük át." - mutat rá.

És mi a legnehezebb feladat? "A műszaki kérdések egyszerűen megoldhatóak, az emberi tényező sokkal komolyabb kihívás" - mondja Pálfy. "Ha két csapat egymásnak feszül egy olyan kérdésben, ahol mindkét opció elég jó, azt nagyon nehéz feloldani. Ilyenkor természetesen mindkét félnek halálosan komoly érvei vannak arra, hogy miért az ő megoldása jobb, és ha nem azt választjuk, úgy érzik „veszítettek”. Teljesen mélységében kielemezni mindkét lehetőséget nincs idő és sokszor nincs is értelme. Ilyenkor az emberi tényezők kerülnek előtérbe: a csapatvezetőknek meg kell hozni a döntést és legfőképpen egységesen képviselni az új, közös irányt, hogy az adott részleg ne a konfliktusra, hanem az előttük álló feladatokra kezdjen koncentrálni."

A második (befejező) részre is maradtak izgalmas témák, így például megtudjuk, hogy mikor érdemes újraírni a felvásárolt szolgáltatás kódját, hogyan lehet tudatosan céges kultúrát építeni, illetve mi lesz a szerepe a cég budapesti fejlesztőközpontjának az egyesülés után.

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.