A mérnöki csapatok időnként számos okból bajba kerülnek. Néha a robbanásszerű növekedés éri váratlanul a csapatot. Vagy az ügyelet kicsúszik az irányítás alól, és ötpercenként riasztások jelennek meg. Vagy a fejlesztési és üzemeltetési csapatok egyszerűen már nem látják egymást. Függetlenül az okoktól, a csapat rossz helyzetben van, és valamit tenni kell a megoldás érdekében.
Ha új problémáról van szó, a megoldás egyszerű lehet: adjunk hozzá még néhány szervert, térjünk vissza egy ismert jó alkalmazásverzióra, vagy hívjunk össze mindenkit egy pizza és egy sör mellé, hogy tisztázzuk a helyzetet. Gyakran azonban a probléma idővel kúszik feléd, és hirtelen olyan mély a lyuk, hogy nem találod a kiutat. A LinkedIn-nél egy csapat, amelyik eljutott erre a pontra, gyakran hirdet egy “Sárga kód” néven ismert állapotot.”
Sárga riasztás
Néhányan azt feltételezik, hogy a Sárga kód elnevezés a közlekedési lámpákból ered, de pontosabban – és egy geekesebb csavarral – valójában a kedvenc “Star Trek” sorozatodból származik. Pontosabban, az Enterprise csillaghajó legénysége így jelzi az aktuális védelmi állapotát. Akárhogy is, a meghatározás egyértelmű: valami nincs rendben, és óvatosan kell haladnunk. Mindkét metaforához hűen van vörös kódunk is. Ezt inkább azonnali válsághelyzetnek neveznénk, ahol mindenki a nap 24 órájában dolgozik, amíg meg nem oldódik. A Sárga kód valamivel nyugodtabb: Erre mindenki elsődlegesen koncentrál, de csak munkaidőben. A Sárga Kód szintén általában hónapokig tart, míg a Vörös Kódnak napokig kell tartania.
Más vállalatoknál lehet, hogy a Sárga Kódtól eltérő kifejezést használnak, de a hatás ugyanaz: a csapat azt kommunikálja a vállalat többi részének, hogy egy komoly problémát azonosítottak, amelyet a csapat és ezáltal a vállalat sikerének biztosítása érdekében prioritásként kell megoldani. Az erre való képesség a nyílt és őszinte kommunikáció fontos aspektusa, egy olyan érték, amely kritikus fontosságú az egészséges kultúra szempontjából, és amelyet gyakran figyelmen kívül hagynak. A problémáinkról való beszélgetés ugyanolyan fontos, ha nem fontosabb, mint a sikereink ünneplése. A csapatok többet tanulhatnak egy probléma kijavításából, mint egy teljes sikerből.”
Ez nem kudarc
A sárga kód elindításának első lépése, hogy megértsük, ez nem kudarc. Nem szégyen beismerni, hogy a csapatnak van egy problémája, amit meg kell oldani. A hibák előfordulnak, annak ellenére, hogy minden erőnkkel azon vagyunk, hogy elkerüljük őket. Az egyetlen dolog, amit tehetünk, hogy diagnosztizáljuk a problémát, és orvosoljuk azt. Csak akkor vallunk kudarcot, ha szemet hunyunk e problémák felett. Ez ugyanúgy vonatkozik a mérnöki csapataink egymás közötti kapcsolatára, mint az általunk gyártott és üzemeltetett szoftverekre és rendszerekre.
Kritikus azonban, hogy a megfelelő problémákat kezeljük. Legtöbbször azért kerültünk a jelenlegi helyzetbe, mert egy lassan forrongó – növekvő technikai adósság, sok apró probléma vagy egy folyamat meghibásodása – miatt végül válsággá alakult. A Code Yellow célja nemcsak a jelenlegi problémák orvoslása kell, hogy legyen (reaktív komponens), hanem annak biztosítása is, hogy azok a jövőben ne ismétlődjenek meg (proaktív komponens).
A sikeres Code Yellow megtervezése
A sikeres Code Yellow-hez több összetevőre van szükség, valamint a szervezet többi részének részvételéhez szükséges darabokra:
- Problémafelvetés: Egyértelmű és elfogadott nyilatkozatnak kell lennie a csapat előtt álló, a Code Yellow-t kiváltó problémákról. Ennek nemcsak azt kell tartalmaznia, hogy mik a jelenlegi problémák, hanem azt is, hogy mi a jelenlegi felfogás a kiváltó okokról.
- Kilépési kritériumok: Ezután konkrét célokra van szükség, amelyek elérésén a csapat a Sárga kódból való kilépés érdekében dolgozik. Ezeknek hagyományos SMART-céloknak kell lenniük: konkrét, mérhető, elérhető, releváns és időhöz kötött. Ezek a célok teszik lehetővé, hogy a csapat egyáltalán belépjen a Sárga Kódba, mivel az egy meghatározott területet fed le, és nem nyílt végű.
- Kommunikáció: A Sárga kóddal kapcsolatos minden információt, beleértve a bejelentést (amely tartalmazza a problémamegállapítást és a kilépési kritériumokat), a sikeres lezárást és az időszakos állapotfrissítéseket el kell küldeni a nagyobb szervezetnek. Ez lehet az Ön részlege, de lehet az egész mérnöki szervezet is. A problémák jellegétől függően akár az egész vállalat is lehet.
- Projektmenedzsment: Mint minden nagy projektnél, itt is kell lennie valakinek, aki felelős a munka megszervezéséért és az információk közléséért. Mivel ez egy “minden kéz a fedélzeten” forgatókönyvet jelent az érintett csapat számára, általában hasznos, ha van egy külön projektmenedzser (PM), aki segít ebben. Ez általában egy olyan PM, aki ismeri a csapatot és a munkát, de nem vesz részt közvetlenül a végrehajtásban. Ez felszabadítja a vezetőket és az egyéni közreműködőket, hogy az aktuális munkára koncentrálhassanak.
Mihelyt minden ilyen szempontot átgondoltak, és a döntés megszületett a sárga kódba való belépésről, a csapat első dolga, hogy a kilépési kritériumok köré szervezze át a prioritásait. Ez gyakran azt jelenti, hogy a negyedéves célokat a polcra kell tenni. Az is szükséges lehet, hogy külön értekezletet hozzanak létre a kilépési kritériumok állapotának megvitatására.
Tér a lélegzetvételhez
A csapat számára szép és jó, ha belép a Sárga kódba, és a dolgok rendbetétele érdekében kitűzött célokra összpontosítva dolgozik, de ez nem elég a csapat sikeréhez. A valódi sikerhez mindenkinek, aki körülveszi a csapatot, meg kell értenie a helyzetet, és teret kell adnia nekik a munkájuk elvégzéséhez. Ez az a hely, ahol az egészséges mérnöki kultúra felemelkedik, hogy megfeleljen a kihívásnak.
- Számítson késedelmekre: Az érintőleges csapatot leggyakrabban a késedelmek érintik. Számítaniuk kell arra, hogy az érintett csapathoz intézett kérések késedelmet szenvedhetnek, ha azok nem tartoznak a kilépési kritériumok körébe. A sárga kód lényege a prioritások átrendezése a megállapított probléma megoldása érdekében. A külső csapatoknak ezt figyelembe kell venniük, és meg kell érteniük, hogy saját projektjeik ütemezését esetleg módosítaniuk kell.
- Új kérések minimalizálása: Más csapatoknak is tartózkodniuk kell attól, hogy az érintett csapattól olyan új dolgokat kérjenek, amelyek kívül esnek a meghatározott kilépési kritériumok hatókörén. Az ilyen kérések minimalizálása, valamint a meglévő kérések késleltetésének elfogadása lehetővé teszi az érintett csapat számára, hogy korlátozott mérnöki idejüket a Code Yellow másik oldalának elérésére fordítsák.
- Segítségkérések más csapatoktól: A sárga kódban lévő csapat úgy találhatja, hogy külső segítségre van szüksége céljai eléréséhez. Például, ha hirtelen, robbanásszerűen megnő a forgalom, lehet, hogy fel kell gyorsítaniuk az új hardverek beszerzését. Ha egy ilyen kérés címzettjeként találja magát, lehet, hogy saját prioritásait kell megváltoztatnia. Ne feledje mindig, hogy a csapat mindannyian ugyanannak a vállalatnak a része, és mint ilyen, mindenki együtt ér el sikert vagy kudarcot.
A mérnöki csapatok ritkán állnak egyedül, és fontos, hogy mindenki megértse annak értékét, hogy ezek a csapatok jól működnek, és jól működnek együtt. A célok egy kis átmeneti késleltetése, hogy megbizonyosodjunk arról, hogy ez így van, megéri.”
Fény az alagút végén
A sárga kód jelentős mennyiségű, magas prioritású munkát jelent, és az ezen való dolgozás gyakran stresszes lesz a csapat számára. Nehéz nemet mondani az ésszerű kérést megfogalmazó munkatársaknak, és a hatókörbe tartozó munka ritkán jár azzal, hogy érdekes új funkciókkal töltsünk időt. Ráadásul, ha a kezelendő problémák közé tartoznak a csoportok közötti kommunikációs problémák, akkor nehéz beszélgetésekre is szükség lesz. Ahogy azonban a csapat közeledik a munka végéhez, sokkal könnyebb lesz átlátni, hogy mi rejlik a kilépési kritériumok túloldalán.
A Code Yellow végső célja, hogy a csapatot kivezesse a reaktív üzemmódból, ahol válságról válságra rohangálnak, egy proaktív állapotba, ahol képesek a megfelelő nagy projekteken dolgozni. A kilépési kritériumok elérése azt jelenti, hogy a mérnökök hatékonyabbak és képesek proaktívan dolgozni. Ez egy erősebb csapat – a mérnökök boldogabbak, mert nem éri őket az operatív munka nagy stressze, a csapat jól működik, mert hatékonyan beszélgetnek egymással, az ügyfelek pedig elégedettek, mert a kéréseket vagy automatizálással, vagy ésszerű időn belül kezelik.”
Vállalatánál van olyan belső folyamat, amely hasonló ahhoz, ahogy a LinkedIn a Code Yellow-t végzi?
– Todd Palino
.