Älä anna teknisen velan ohjata tiekarttaasi – ota ohjat nyt viidellä strategialla

Kaikki alkaa pienestä: väliin jätetystä koodikatselmoinnista, viivästyneestä Rails-siirrosta tai teknisten resurssien uudelleenkohdentamisesta ylläpidosta uuden ominaisuuden määräajan saavuttamiseksi.

Vuotta myöhemmin tekninen tiimisi käyttää kolmanneksen ajastaan ongelmien sammuttamiseen, asiakasvalitukset kasaantuvat ja talousjohtajasi tuijottaa 2 miljardin dollarin budjettiylitystä.

Jeff Watkins, CreateFuturen teknologiajohtaja, on nähnyt tilanteen toistuvan kerta toisensa jälkeen: tekninen velka kasvaa hitaasti, alkaa heikentää teknistä tuottavuutta ja leviää lopulta liiketoimintaan. 

”Tekninen velka on väistämätöntä toiminnan kasvaessa”, Watkins sanoo, ”mutta yritykset ovat usein haluttomia osoittamaan resursseja sellaisten asioiden korjaamiseen, jotka eivät ole näkyvästi rikki, etenkin kun uutta toiminnallisuutta pitäisi julkaista.” Pitkällä aikavälillä tämä ”jos se ei ole rikki, älä korjaa sitä” -ajattelutapa voi kuluttaa jopa 20 % teknisistä budjeteista. 

Kun nopeampien julkaisujen ja skaalautuvien järjestelmien kysyntä on ennätyksellisen suurta, korjausten lykkääminen tänään aiheuttaa suurempia ongelmia huomenna. Näin käsittelet teknistä velkaa strategisesti pysäyttämättä etenemissuunnitelmaasi.

Mitä tekninen velka on?

Tekninen velka on uudelleentyön kumuloitunut kustannus, joka syntyy nopeuden syrjäyttäessä pitkän aikavälin laadun kehitysprosessissa. Se ilmenee useissa eri muodoissa:

• Arkkitehtuurivelka: Järjestelmäarkkitehtuuri ei pysy kasvun tai skaalautuvuuden vaatimusten tahdissa.
• Koodivelka: Heikkolaatuinen tai puutteellisesti testattu koodi aiheuttaa tuotannossa epävakautta ja johtaa toistuviin häiriöihin.
• Prosessivelka: Työnkulkujen tehottomuus, automatisoitujen prosessien puute tai ongelmallinen CI/CD-putki aiheuttaa pullonkauloja.
• Dokumentaatiovelka: Puuttuva tai vanhentunut dokumentaatio, tiimin jäsenten hiljaiseen tietoon tukeutuminen sekä vianmäärityksen ja perehdytyksen vaikeutuminen.
• Infrastruktuurivelka: Vanhentuneiden riippuvuusversioiden käyttäminen tai palautumisen laiminlyönti katastrofitilanteissa voi johtaa haavoittuvuuksiin ja järjestelmähäiriöihin.

Teknisen velan syyt

Et voi korjata sellaista, mitä et ymmärrä. Teknisen velan kasvun syyn tunteminen on ratkaisevan tärkeää, jotta voit pysäyttää sen ennen kuin se riistäytyy hallinnasta. Tässä ovat teknisen velan keskeiset syyt, joita kannattaa seurata:

• Kasvava liiketoimintapaine: Pyrkimys nopeaan toimitukseen johtaa usein laajuuden hallitsemattomaan kasvuun, teknisten resurssien ylikuormittumiseen, testauksen ohittamiseen ja huonosti suunniteltuihin ominaisuuksiin, jotka on myöhemmin korjattava, jos niitä korjataan lainkaan. 
• Vanhentunut järjestelmäarkkitehtuuri: Vanhentuneisiin järjestelmiin takertuminen ja siirtojen laiminlyönti tarvittaessa luovat hauraita integraatioita ja lisää teknistä velkaa. Vanhentuneet rajapinnat ja tunnistautumisjärjestelmät jäävät usein kasaantumaan useiden palveluntarjoajien kanssa.
• Heikko kehitysprosessi: Liian sallivat tai olemattomat koodikatselmoinnit, heikosti luettava toistettu koodi ja suuret koodikannat, joissa on yli miljoona koodiriviä (LoC). 
• Vanhojen järjestelmien monimutkaisuus: Viivästyneet korjaukset, vanhentunut infrastruktuuri ja tuettomien versioiden käyttö johtavat järjestelmien yhteensopimattomuuteen ja kasvavaan ”tietoturvavelkaan”. Microsoft yrittää yhä toipua sen seurauksista. Exchange Online -hakkeroinnin ja Midnight Blizzard -hyökkäyksen välillä yhtiö maksaa edelleen hintaa ajan mittaan kertyneen velan sivuuttamisesta.
• Siiloutunut tiedonhallinta: Huonot teknologiavalinnat, puutteellinen suunnittelumallien toteutus ja viitekehysten väärinkäyttö voivat pakottaa tiimit ylisuunnitteluun, kuten mikropalvelujen käyttöönottoon ilman hajautettujen järjestelmien asiantuntemusta.
• Heikko kehittäjien tuottavuus: Jatkuvan paineen alla työskentelevät kehittäjät, joilla ei ole aikaa dokumentaation tarkistamiseen tai keskittymistä vaativaan työhön, priorisoivat aina lyhyen aikavälin tavoitteita, mikä voi kasvattaa teknistä velkaa. 

Tehokkaimmat teknisen velan hallintastrategiat kohdistuvat näihin perimmäisiin syihin eivätkä pelkästään oireiden käsittelyyn.

5 vaihetta teknisen velan vähentämiseen teknologiajohtajille

Tekninen velka on usein tietoinen päätös, etenkin kun tavoitteena on julkaista MVP nopeasti ja suunnitelmissa on tehdä refaktorointi myöhemmin, jos se menestyy. Se toimii – kunnes ei enää toimi. Jos olet siis saavuttamassa tuon käännekohdan tai haluat pysyä ennakoivana, tässä on viisi strategiaa suoraan teknologiajohtajan työkalupakista kasvavan teknisen velan hallintaan: 

1. Tee tekninen velkasi näkyväksi 

Et voi korjata sitä, mitä et pysty mittaamaan, mutta kuten Martin Riley, Bridewellin teknologiajohtaja, sanoo, et myöskään voi mitata sitä, mitä et näe. Tämä tarkoittaa sen varmistamista, että kehitystyösi voidaan jäljittää aina sen synnyttämään tekniseen velkaan asti. Tämän näkyvyyden avulla voit sovittaa teknologiainvestoinnit liiketoimintatavoitteisiin, perustella refaktorointiponnistelut ja välttää järjestelmän yllättävät vikatilanteet. ”Kun tiedetään, kuka on vastuussa velkaa synnyttävästä koodista ja onko se hyväksytty, sen hallinta helpottuu.”

Yksityiskohtainen näkyvyys tekniseen velkaan alkaa laadukkaasta datasta. Käytä tekoälyagenttia, joka yhdistyy CI/CD-putkeesi, hakee tietoja tiimikokouksista ja seuraa viestintämalleja, työkuorman jakautumista ja sprintin etenemistä. Voit jopa automatisoida lokikirjausten tekemisen vanhentuneen tai monimutkaisen koodin tunnistamiseksi samalla, kun seuraat koodin laadun paranemista tai heikkenemistä ajan mittaan. Yhdistä nämä havainnot säännöllisiin kyselyihin, joissa IC:t voivat arvioida koodin muokkaamisen vaikeutta, ylläpitoon käytettyä aikaa ja ongelmakohtia. 

2. Ota käyttöön velkarekisteri prioriteettien määrittämistä varten 

Luo keskitetty teknisen velan rekisteri, johon kirjataan kaikki velan muodot: koodi, arkkitehtuuri ja prosessidokumentaatio. Teknisen velan lähteiden listaaminen ei kuitenkaan riitä; vaikeampaa on tunnistaa ne alueet, joilla on suurin vaikutus. Watkins kehottaa keskittymään sijoitetun pääoman tuottoon: ”Jos korjaus säästää 20 kehittäjältä tunnin päivässä ja sen toteuttamiseen kuluu vain viikko, sijoitetun pääoman tuotto on lähes välitön.” Hän näkee vastaavia hyötyjä myös esimerkiksi testauksen epävakauden tai pitkien koontiaikojen ratkaisemisessa. 

Kun luot velkarekisteriäsi, noudata 80/20-sääntöä: keskity siihen 20 prosenttiin teknisestä velasta, joka aiheuttaa 80 prosenttia ongelmistasi. Tunnista kriittinen ”20 %” seuraamalla: 

• Ylläpitoon käytetty aika verrattuna uusien ominaisuuksien kehittämiseen
• Toistuvien ja ratkaisemattomien virheiden määrä
• Kehittäjien palaute muutosten tekemisen vaikeudesta
• Testikattavuuden prosenttiosuus
• Koontiajat (10 minuuttia tai enemmän)
• Koodin uudelleenkirjoitusten suuri määrä (yli 20 % sprinttiä kohden)

Määrälliset mittarit antavat sinulle faktat, mutta tarvitset myös laadullisen näkökulman saadaksesi kokonaiskuvan siitä, miten ja missä tekninen velkasi kertyy ja mitkä liiketoiminnan osat kärsivät eniten.

Watkins suosittelee seuraamaan käyttökokemukseen liittyviä ongelmia, pidempiä käyttöönottoaikoja ja ennen kaikkea kehitystiimisi tuottavuuden laskua. Tarkastele kehittäjiesi syvälliseen työskentelyyn käyttämää aikaa, käyttökatkoista valittavien asiakkaiden CSAT-pisteitä, hitaita latausaikoja ja tuotannossa epävakaita koonteja. Tee tästä osa säännöllistä työnkulkuasi yhdistämällä rekisterisi JIRAan ja nimeämällä jokaiselle luokalle ”velan omistaja”, jotta pysyt tilanteen tasalla. 

3. Sisällytä tekninen velka sprinttisuunnitteluusi 

Jeff Delaney, Black Duckin tutkimus- ja tuotekehityksen suunnittelusta vastaava johtaja, käyttää älykästä lähestymistapaa teknisen velan hallintaan: sisällytä se kapasiteettisuunnitteluusi neljännesvuosittaisten tavoitteiden ja JIRA-taulun avulla. ”Varaamme jokaisessa julkaisussa tietyn määrän kapasiteettia teknistä velkaa varten. Määrä voi vaihdella, mutta tiedämme aina, mitä teknistä velkaa meillä on, priorisoimme sen ja annamme sille asianmukaisen huomion.”

Aloita 45 päivän työkiertojaksoilla, joissa kehittäjät vuorottelevat vanhojen järjestelmien ylläpidon ja uusien ominaisuuksien rakentamisen välillä. Työskentele vaihtojen aikana pareittain, jotta uudet näkökulmat ja tehokas tiedonsiirto mahdollistuvat. Pareittain työskentely jakaa ylläpitokuormaa luontevasti, antaa kaikille syvemmän ymmärryksen järjestelmästä ja lisää empatiaa vähemmän hohdokkaita ”ylläpitotehtäviä” kohtaan. 

Haasteena on kuitenkin saada ylimmän johdon hyväksyntä, etenkin jos he näkevät kehittäjien työskentelevän vanhojen järjestelmien parissa uusien liiketoimintatavoitteiden edistämisen sijaan. Watkins ehdottaa korjaamiseen käytettävän ajan lisäämistä kehittäjien tehtäviin ja ”korjaa ennen kuin laajennat” -ajattelutavan omaksumista. ”Toimitus saattaa aluksi hidastua, mutta pitkän aikavälin lopputulos täyttää sekä tekniset että liiketoiminnalliset tavoitteet.”

4. Rakenna ”velkaportit” CI/CD-putkeen

Teknisen velan ehkäiseminen on halvempaa kuin sen siivoaminen myöhemmin – rajoita sitä, kun se on vielä harmitonta. Ota käyttöön arkkitehtuuripäätösten tallennusmenettely (ADR) standardoidulla mallipohjalla, johon kirjataan vaihtoehdot, päätöskriteerit ja odotettu vaikutus tekniseen velkaan. Tallenna se koodin yhteyteen versionhallintaan. ADR:t auttavat välttämään tahatonta teknistä velkaa ja ohjaavat tulevia refaktorointiponnisteluja. ADR:t antavat kuitenkin kokonaiskuvan. 

Todellinen, päivittäinen teknisen velan vähentäminen syntyy kuitenkin laadukkaan koodin julkaisemisesta. Voit käyttää tekoälyagenttiasi tai koodianalyysityökalua (jos et ole vielä valmis hyödyntämään tekoälyä) merkitsemään ongelmat automaattisesti, kun tietyt raja-arvot ylittyvät:

• Estä käyttöönotot, kun syklomaattinen kompleksisuus saavuttaa arvon 15
• Merkitse testit epävakaiksi kolmen satunnaisen epäonnistumisen jälkeen
• Keskeytä koontiversiot, jos testisarjojen suoritus kestää yli 10 minuuttia
• Estä yhdistämispyynnöt, kun yhdistettäväksi tarjotaan luokkia, joissa on vähintään 500 riviä 

Riippuvuuksien osalta suorita mukautettuja komentosarjoja, jotka estävät käyttöönotot riskialttiiden riippuvuuksien yhteydessä ja estävät ristiriitaisten versioiden yhdistämisen. Voit esimerkiksi yhdistää komentosarjasi CSV-muotoiseen tietoturvatietokantaan, jotta haavoittuvia paketteja sisältävät käyttöönotot estetään automaattisesti. Voit myös kirjoittaa komentosarjoja, jotka estävät yhdistämispyyntöjen yhdistämisen, jos ne luovat ristiriitaisia riippuvuuksia tai käyttävät vanhentuneita kirjastoja. 

5. Nykyaikaista vanha infrastruktuurisi 

Monilla yrityksillä on vaikeuksia nykyaikaistaa järjestelmiään, koska ne ovat juuttuneet monoliittisiin arkkitehtuureihin, jotka hidastavat ketterää kehitystä ja julkaisuja. Riley ehdottaa kuristajamallin (eli vaiheittaisen korvaamisen mallin) käyttöä teknisen velan ratkaisemiseksi vähitellen sen sijaan, että kaikkea yritettäisiin kirjoittaa uudelleen kerralla.

Korkean riskin kertasiirtymän sijaan vanhaa teknologiaa nykyaikaistetaan vaiheittain, ominaisuus tai käyttäjäryhmä kerrallaan, häiriöiden vähentämiseksi ja palautteen keräämiseksi prosessin aikana.

Jotkin suuret tiimit käyttävät rinnakkaisen käytön lähestymistapaa, kuten Spotify teki musiikkisoittimensa kanssa. Ne pitivät verkko- ja työpöytäversiot käynnissä samalla käyttöliittymällä tietojen synkronoimiseksi ja uuden järjestelmän testaamiseksi ennen täydellistä siirtymää.

Selätä tekninen velka ennen kuin se pysäyttää edistymisesi

Tekninen velka ei ole aina huono asia– se on itse asiassa merkki siitä, että suunnittelutiimisi kasvaa. Parempi kysymys on: hallitsetko sitä vai hallitseeko se sinua? Kuten Delaney asian ilmaisee, “Lopulta tiimin on joka tapauksessa käsiteltävä tekninen velka. Olennaista on tehdä se omilla ehdoillasi harkitun suunnittelun avulla sen sijaan, että joutuisit myöhemmin kiirehtimään kriisitilanteessa.” 

Johdon on lopetettava ongelmien räjähdysmäistä kasvua odottaminen ja alettava investoida tehokkuuteen, toteutukseen ja kustannusten optimointiin jo nyt.

Haluatko pysyä ajan tasalla kaikesta tekniseen velkaan ja johtamiseen liittyvästä? Tilaa The CTO Clubin uutiskirje jo tänään.