Tekniset tiimit joutuvat aina silloin tällöin ongelmiin mistä tahansa syystä. Joskus räjähdysmäinen kasvu yllättää tiimin. Tai päivystys on karannut käsistä, ja hälytyksiä tulee viiden minuutin välein. Tai kehitys- ja käyttötiimit eivät yksinkertaisesti enää näe toisiaan silmästä silmään. Olipa syy mikä tahansa, tiimi on pahassa pulassa, ja jotain on tehtävä sen ratkaisemiseksi.
Jos kyseessä on uusi ongelma, ratkaisu voi olla helppo: lisätään muutama palvelin lisää, palataan tunnetusti hyvään sovellusversioon tai kutsutaan kaikki yhteen pizzan ja oluen äärelle selvittämään asia. Usein ongelma kuitenkin hiipii ajan myötä ja yhtäkkiä kuoppa on niin syvä, ettei ulospääsyä löydy. LinkedInissä tiimi, joka on päässyt tähän pisteeseen, julistaa usein tilan, joka tunnetaan nimellä ”Keltainen koodi.”
Keltainen hälytys
Jotkut ihmiset olettavat Keltainen koodi -nimen perustuvan liikennevaloihin, mutta oikeammin – ja nörttimäisemmällä tavalla – se on itse asiassa peräisin suosikkisarjastasi Star Trekistä. Tarkemmin sanottuna sillä tähtialus Enterprisen miehistö ilmaisee senhetkisen puolustustilansa. Joka tapauksessa määritelmä on selvä: jokin on vialla, ja meidän on edettävä varovaisesti. Molemmille vertauskuville uskollisena meillä on myös punainen koodi. Sitä kuvaa paremmin välitön kriisi, jossa kaikki työskentelevät 24 tuntia vuorokaudessa, kunnes tilanne on ratkaistu. Keltainen koodi on hieman rauhallisempi: Kaikki keskittyvät siihen ensisijaisesti, mutta vain työaikana. Keltaiset koodit kestävät yleensä myös kuukausien luokkaa, kun taas punaisen koodin pitäisi kestää päivien luokkaa.
Muissa yrityksissä saatetaan käyttää eri termiä kuin keltainen koodi, mutta vaikutus on sama: tiimi viestii muulle yritykselle, että se on havainnut vakavan ongelman, joka on ensisijaisesti korjattava tiimin ja siten myös yrityksen menestyksen varmistamiseksi. Kyky tehdä näin on tärkeä osa avointa ja rehellistä viestintää, joka on elintärkeä arvo terveelle kulttuurille ja joka usein jää huomiotta. Ongelmista puhuminen on aivan yhtä tärkeää, ellei jopa tärkeämpää kuin onnistumisten juhliminen. Tiimit voivat oppia enemmän ongelman korjaamisesta kuin täydellisestä menestyksestä.
Tämä ei ole epäonnistuminen
Keltaisen koodin aloittamisen ensimmäinen askel on ymmärtää, että tämä ei ole epäonnistuminen. Ei ole häpeällistä myöntää, että tiimillä on ongelma, joka on korjattava. Vikoja sattuu, vaikka yritämme parhaan kykymme mukaan välttää niitä. Voimme vain diagnosoida ongelman ja korjata sen. Epäonnistumme vain silloin, kun suljemme silmämme näiltä ongelmilta. Tämä pätee siihen, miten insinööritiimimme ovat vuorovaikutuksessa toistensa kanssa, yhtä lailla kuin tuottamiimme ja käyttämiimme ohjelmistoihin ja järjestelmiin.
On kuitenkin ratkaisevan tärkeää, että oikeisiin ongelmiin puututaan. Useimmiten olemme joutuneet nykyiseen tilanteeseen hitaan kiehumisen vuoksi – kasvavan teknisen velan, monien pienten ongelmien tai prosessin hajoamisen – jotka lopulta kasautuivat kriisiksi. Keltaisen koodin tavoitteena on oltava paitsi nykyisten ongelmien korjaaminen (reaktiivinen komponentti), myös sen varmistaminen, että ne eivät toistu tulevaisuudessa (proaktiivinen komponentti).
Suunnittelu onnistuneen keltaisen koodin toteuttamiseksi
On useita komponentteja, joita tarvitaan onnistuneeseen keltaiseen koodiin, sekä tarpeellisia palasia, jotta saadaan muulta organisaatiolta hyväksyntä:
- Ongelman selvitys: On oltava selkeä ja sovittu selvitys tiimin kohtaamista ongelmista, jotka ovat johtaneet Code Yellow -toimintaan. Tähän pitäisi sisältyä paitsi se, mitä nykyiset ongelmat ovat, myös se, mikä on nykyinen käsitys niiden perimmäisestä syystä.
- Poistumiskriteerit: Seuraavaksi on määriteltävä erityiset tavoitteet, joita kohti tiimi työskentelee poistuakseen keltaisesta koodista. Näiden tulisi olla perinteisiä SMART-tavoitteita: erityisiä, mitattavissa olevia, saavutettavissa olevia, merkityksellisiä ja ajallisesti rajattuja. Nämä tavoitteet mahdollistavat sen, että tiimi ylipäätään pääsee keltaiseen koodiin, sillä ne kattavat kiinteän laajuuden eivätkä ole avoimia.
- Viestintä: Kaikki keltaista koodia koskevat tiedot, mukaan lukien ilmoitus (joka sisältää ongelmanasettelun ja poistumiskriteerit), onnistunut päättäminen ja säännölliset tilapäivitykset, olisi lähetettävä laajemmalle organisaatiolle. Tämä voi olla oma osasto tai koko insinööriorganisaatio. Se voi olla jopa koko yritys, ongelmien luonteesta riippuen.
- Projektinhallinta: Kuten kaikissa suurissa projekteissa, tarvitaan joku, joka vastaa työn organisoinnista ja tietojen välittämisestä. Koska tämä edustaa ”kaikki kädet kannella” -skenaariota vaikutusten kohteena olevalle tiimille, on yleensä hyödyllistä, että on oma projektipäällikkö (PM), joka auttaa tässä. Kyseessä on yleensä PM, joka tuntee tiimin ja työn, mutta ei osallistu suoraan toteutukseen. Tämä vapauttaa johtajat ja yksittäiset tekijät keskittymään käsillä olevaan työhön.
Kun kutakin näistä näkökohdista on pohdittu ja päätös keltaiseen koodiin siirtymisestä on tehty, tiimin ensimmäinen teko on järjestää prioriteetit uudelleen poistumiskriteerien ympärille. Tämä tarkoittaa usein neljännesvuositavoitteiden hyllyttämistä. Saattaa myös olla tarpeen perustaa oma kokous, jossa keskustellaan poistumiskriteerien tilanteesta.
Tilaa hengittää
On ihan hyvä, että tiimi siirtyy keltaiseen koodiin ja työskentelee keskittyen vain niihin tavoitteisiin, jotka on asetettu asioiden korjaamiseksi, mutta se ei riitä tiimin menestymiseen. Todellisen onnistumisen edellytyksenä on, että kaikki tiimiä ympäröivät ymmärtävät tilanteen ja antavat tiimille tilaa tehdä työnsä. Tässä kohtaa terve insinöörikulttuuri nousee vastaamaan haasteeseen.
- Odota viiveitä: Yleisin tapa, jolla tangentiaalinen tiimi kärsii, on viivästykset. Niiden on varauduttava siihen, että vaikutuksen kohteena olevalle tiimille esitetyt pyynnöt voivat viivästyä, jos ne eivät kuulu poistumiskriteerien piiriin. Keltaiseen koodiin kuuluu pohjimmiltaan prioriteettien uudelleenjärjestäminen ilmoitetun ongelman ratkaisemiseksi. Ulkopuolisten tiimien on otettava tämä huomioon ja ymmärrettävä, että niiden omia projektiaikatauluja voidaan joutua mukauttamaan.
- Minimoi uudet pyynnöt: Muiden tiimien tulisi myös pidättäytyä pyytämästä vaikutuksen kohteena olevalta tiimiltä uusia asioita, jotka eivät kuulu määriteltyjen poistumiskriteerien piiriin. Näiden pyyntöjen minimoiminen sekä olemassa olevien pyyntöjen viivästymisen hyväksyminen antaa vaikutuksen kohteena olevalle tiimille mahdollisuuden käyttää rajalliset insinöörityötuntinsa siihen, että se pääsee Code Yellowin toiselle puolelle.
- Avunpyynnöt muilta tiimeiltä: Keltaisessa koodissa oleva tiimi saattaa huomata tarvitsevansa ulkopuolista apua saavuttaakseen tavoitteensa. Jos esimerkiksi liikenne kasvaa äkillisesti ja räjähdysmäisesti, heidän on ehkä nopeutettava uuden laitteiston käyttöönottoa. Jos joudut tällaisen pyynnön vastaanottajaksi, saatat joutua muuttamaan omia prioriteettejasi. Muista aina, että tiimi on osa samaa yritystä, ja siksi kaikki menestyvät tai epäonnistuvat yhdessä.
Tekniset tiimit seisovat harvoin yksin, ja on tärkeää, että kaikki ymmärtävät, miten tärkeää on, että nämä tiimit toimivat hyvin ja että ne tekevät hyvää yhteistyötä. Pieni tilapäinen viivytys tavoitteissa sen varmistamiseksi, että näin on, on sen arvoista.
Valoa tunnelin päässä
Keltainen koodi edustaa merkittävää määrää korkean prioriteetin työtä, ja sen läpikäyminen on usein tiimille stressaavaa. ”Ei” sanominen kohtuullista pyyntöä esittäville työtovereille on vaikeaa, ja laajuuteen kuuluva työ sisältää harvoin ajan käyttämistä mielenkiintoisiin uusiin ominaisuuksiin. Lisäksi jos käsiteltäviin ongelmiin kuuluu ryhmien välisiä viestintäongelmia, on käytävä vaikeita keskusteluja. Kun tiimi kuitenkin lähestyy työn loppua, on paljon helpompi nähdä läpi, mitä poistumiskriteerien toisella puolella on.
Koodikeltaisen perimmäinen tavoite on saada tiimi pois reaktiivisesta tilasta, jossa se juoksee kriisistä toiseen, ja siirtyä ennakoivaan tilaan, jossa se pystyy työskentelemään oikeiden isojen hankkeiden parissa. Poistumiskriteerien saavuttaminen tarkoittaa, että insinöörit ovat tehokkaampia ja pystyvät työskentelemään ennakoivasti. Tämä on vahvempi tiimi – insinöörit ovat tyytyväisempiä, koska heillä ei ole raskasta stressiä operatiivisesta työstä, tiimi toimii hyvin, koska he keskustelevat tehokkaasti keskenään, ja asiakkaat ovat tyytyväisiä, koska pyynnöt käsitellään joko automatisoimalla tai kohtuullisessa ajassa.
Onko yrityksellänne sisäinen prosessi, joka on samankaltainen kuin se, miten LinkedIn tekee Code Yellow:n?
– Todd Palino