Mary Poppendieck és Tom Poppendieck a jövő hónapban Budapestre látogat, hogy az IIR Hungary és a Sprint Consulting március 24-25-én sorra kerülő Optional konferenciáján előadást és workshopot tartson a témában.
Computerworld: Az üzleti lehetőségeket kereső, magyar IT-cégek, és különösen a start-upok közül egyre több fordul a regionális és a világpiac felé. Ha nemzetközi téren is sikeres termékkel vagy szolgáltatással jelennek meg – és néhányukról ez már elmondható –, gyorsan kell növelniük a gyártást, méretezniük a szolgáltatást. Miért jelenthet ez legalább akkora kihívást, mint a termékfejlesztés?
Mary Poppendieck: Ha a termék felhőalapú és az architektúrát megfelelően alakította ki a vállalat, akkor viszonylag könnyen megoldható a növekvő felhasználói tábor támogatása. Gyakran azonban magát a szervezetet is méretezni, bővíteni kell ahhoz, hogy felhasználóit kiszolgálhassa, és a terméket újabb piacokra is adaptálhassa. Az összetettebbé váló szoftverkód és a mindinkább szakosodó feladatköröket betöltő emberek együttes kezelése és irányítása komoly hátráltató erővé válhat.
Tom Poppendieck: A sikeres szoftvertermékek nem statikusak, folyamatosan nőnek és átalakulnak, ahogyan a növekvő felhasználótábor igényei is fejlődnek. Ahogyan a vállalat is nő, hogy kiszolgálja ezeket az igényeket, a kezdetben egyszerűnek számító termék, amelyet egy kis csapat is támogatni tudott, összetett rendszerré bővül, melynek bonyolult összefüggéseit nehéz átlátni és menedzselni. Technológia vonatkozásában ez azt jelenti, hogy az összefüggések miatt a kis változtatásoknak is nagy, nem tervezett következményei lehetnek, amelyek megnehezítik és költségessé teszik a módosításokat. Szervezeti oldalon ezzel párhuzamosan egyre több csatornán szükséges kommunikálni ahhoz, hogy bármit is keresztül lehessen vinni. A két erő együttes hatása lelassíthatja a vállalatot, és ugrásszerűen megnövelheti a költségeket.
CW: Jellemzően mi mehet rossz irányba, amikor egy vállalat gyorsan növekszik? Melyek a tipikus buktatók, és hogy kerülhetők el?
MP: Tizenöt éve a méretezés legfőbb problémáját a nagy IT-beruházás jelentette, amelyet a cégnek még azt megelőzően végre kellett hajtania, hogy ténylegesen növelte felhasználói táborát. Ma a vállalatok tizedannyi alkalmazottal és tizedakkora pénzügyi keretből is bővülhetnek, mint tíz évvel ezelőtt, mert a felhőalapú megoldásokkal menet közben méretezhetnek, és csak a ténylegesen használt erőforrásokért kell fizetniük. Napjainkban ezért nem a hardverkapacitás bővítése, hanem a rendszertervezés, az architektúra kialakítása rejti a buktatókat. A legnagyobb problémát a szorosan egymásra utalt, monolitikus kódalapok jelentik, amelyek megnehezítik és a várható megtérüléshez képest aránytalanul megdrágíthatják a változtatásokat.
TP: A modern architektúrák, különösen a felhőalapú platformokra épülők, a kis, egymástól függetlenül bevezethető szolgáltatásokat helyezik előtérbe, amelyek önállóan kezelik az adataikat, és megerősített API-kon keresztül kommunikálnak egymással. A tesztelés korszerű technikái pedig olyan megoldásokat kínálnak, mint pl. a szerződésalapú tesztelés és a lépcsőzetes bevezetés, frissítés. Ezek az architektúrák és technikák segíthetnek a méretezés és a költségek megtérülésarányos szinten tartásában, de csak akkor, ha helyesen alkalmazzák őket. Új területről lévén szó, ez nem könnyű. A szolgáltatások összekapcsolásakor például a vállalat ismét létrehozhatja azokat az egymásra utaltságokat, amelyeket a monolitikus kódalappal szakítva el akart kerülni.
CW: Az agilis szoftverfejlesztést megfelelő eszközkészletek támogatják, de az agilitás problémaköre túlmutat az informatikán. Miként kezelje a menedzsment a szervezeti és emberi vonatkozásokat, létezik erre aranyszabály?
MP: A vállalat maradjon közel ügyfeléhez. Minden csapatnak, amely az ügyfél és a termék kapcsolatához hozzájáruló szolgáltatásokért felel, tudnia és követnie kell, hogy munkája miként hat az ügyfélélményre. Meg kell kapnia minden szakértelmet, információt és döntéshozatali hatáskört ahhoz, hogy folyamatosan javíthassa az ügyfélnek adott szolgáltatásait. A csapatoknak teljes felelősséggel kell tartozniuk a szolgáltatásokért, beleértve a szolgáltatás tartalmának meghatározását, a kód megírását, tesztelését és bevezetését, az eredmények kiértékelését és a változtatások végrehajtását. Ha a szolgáltatás túl nagy egyetlen csapat számára, akkor több csapathoz kell rendelni a problémát, és az irányítást olyan vezetőre bízni, aki minden érintett bizalmát élvezi.
TP: A katonaság már száz évvel ezelőtt megoldotta a skálázás problémáját; a vállalatok okosan teszik, ha tanulnak tőle. A hadsereg szakaszokba szervezi a katonákat, amelyeket a szakaszvezetőre bíz. A feladatokat a szakaszok, nem az egyének kapják. Ha a probléma meghaladja a szakasz erejét, két másik szakaszt rendelnek mellé, még nagyobb feladatokhoz két további, három-három szakaszból álló csoportot is felvonultatnak. De a szakaszok minden esetben tudják, hogy mi a küldetésük és az elvárt eredmény, és miként fognak együttműködni a többi szakasszal, hogy elérjék azt.
CW: Márciusban Budapesten, az IIR Hungary és a Sprint Consulting Optional konferenciája előtti napon egy műhelyfoglalkozást is tartanak. Kinek ajánlják ezt az interaktív eseményt?
MP: Workshopunkra a szoftverfejlesztés területéről várjuk a csapatvezetőket és a termékfelelősöket. A foglalkozáson azt vizsgáljuk majd, hogy a munka folyamata miként halad a szervezeti egységeken keresztül, és hol lehetnek a szűk keresztmetszetek; rávilágítunk ezek hátterére, és arra is, hogy más szervezetek miként oldottak meg hasonló problémákat. Gyakran tapasztaljuk ezen a ponton, hogy a vállalatok egymást is kisegítik ötleteikkel!
TP: Arra fókuszálunk, hogy miként érhető el az ideális állapot, hasonló ahhoz, amelyet a fentiekben említettem. Hasonló szervezetekkel szerzett tapasztalatunkból merítve a workshop résztvevőit olyan gyakorlati lépések kigondolásához segítjük hozzá, amelyeken keresztül szervezetük közelebb kerülhet ehhez az eszményi állapothoz.
