Teknisen velan hallinta DX:n ja AI:n avulla

Jokainen yritys, iso tai pieni, huolehtii teknisestä velasta. Gartnerin arvioiden mukaan noin 40 % infrastruktuurijärjestelmistä kärsii tästä ongelmasta. McKinsey-nimisen yrityksen tekemässä CIO-tutkimuksessa lähes kolmasosa vastaajista koki, että yli 20 % uuden tuotteen budjetista meni teknisen velan ratkaisemiseen. Mutta toisin kuin moni uskoo, tämä ei ole pelkästään koodausongelma, vaan myös kehittäjän kokemuksen (DX) ongelma. Kun kehittäjien on työskenneltävä riittämättömän arkkitehtuurin, vanhentuneiden työkalujen ja alaisten kehitystyökalujen kanssa, tuottavuus, suorituskyky ja moraali kärsivät.

Teknisen velan priorisointi kehittäjän näkökulmasta, keskittyen siihen, miten he lähestyvät työtään, mitä työkaluja he käyttävät ja mitä urakehitystä he voivat saavuttaa, auttaa tiimejä keskittymään ja toimittamaan nopeammin. Tämän vuoksi yritysten tapa hallita teknistä velkaa muuttuu, ja siihen vaikuttavat DX ja AI-pohjaiset työkalut.

DX:n edistäminen

Kehittäjien perehdytysprosessi jättää usein toivomisen varaa. Uuden kehittäjän perehdyttäminen voi kestää useita viikkoja, ennen kuin hän pääsee osallistumaan projektiin. Kun hän lopulta pääsee lisäämään pieniä ominaisuuksia tai korjauksia, ei ole epätavallista, että jatkuva integraatio (CI) palvelu epäonnistuu jonkin muun asian vuoksi, joka ei liity kehittäjän tekemiin muutoksiin. Tämä on periaatteessa testaussarjan epäonnistuminen laadun vuoksi, eikä kehittäjä ole tehnyt muutoksia, jotka aiheuttavat testaussarjan epäonnistumisen. On olemassa heikko, huonosti kirjoitettu testi, joka toimii vain 90 % ajasta. Olemassa oleva tiimi on luultavasti tyytyväinen siihen, mutta se hidastaa prosesseja, ja työkalut voivat olla vanhentuneita ja demoralisoivia ulkopuolisille.

Tämä on yksi esimerkki monista, jotka haittaavat oikean DX:n. Yksi tapa estää tämä on nimittää erityinen edustaja ohjelmistokehitys- ja kehittäjätiimiin. Monet pienet organisaatiot eivät ole DX-johtajia, mutta suuret, menestyvät yritykset ovat. Nämä asiantuntijat seuraavat asioita, kuten kuinka kauan kestää uuden kehittäjän pääsy projektiin. Jos kaksi viikkoa on liian pitkä, he keksivät, miten lyhentää aikaa puoleen.

On olemassa työkaluja, jotka auttavat, kuten CircleCI, jossa on ominaisuus, joka seuraa testaussarjan epävakautta. Mitä tarvitaan, on joku, joka ottaa johtajan roolin ja pysähtyy jokaisen sprintin jälkeen osoittamaan muutoksia, jotka tekevät koodin helpommin ylläpidettäväksi ja työskenneltäväksi tulevaisuudessa. Se tulee johtajan kiinnostuksesta tehdä DX:stä paremman. Sen toteuttamiseksi etsi senior-tason insinööri, jota seuraa suhteellisen uusi henkilöstö, joka voi antaa palautetta mahdollisista aukkoista.

Myös IDC odottaa, että AI-pohjaisen ohjelmistotestauksen automaatio markkinat jatkavat kasvamistaan 31,2 %:n vuosivauhtia vuoteen 2027, joten varmista, että hyödytät tästä teknologiasta täysimääräisesti.

Mittarit ja varoitusmerkit

On olemassa monia mittareita, joita voit seurata arvioitaessa, miten tekninen velka vaikuttaa tiimiisi. Jotkut perusmittarit ovat “korjausaika” tai “ominaisuusaika”. Oletetaan, että huomaat virheen ja tiedät, miten se korjataan. Jotkut työkalut voivat seurata aikaa koodin kirjoittamisesta tuotantoon. Esimerkiksi voit nähdä, että pieni korjaus vei kaksi liiketoimintapäivää, vaikka tiimisi tarvitsisi pystyä tekemään sen muutamassa tunnissa. Voit myös seurata suhteita, kuten virheiden määrää suhteessa valmiiden ominaisuuksien määrään.

On myös keinoja tunnistaa, kun moraali vaikuttaa tiimisi suorituskykyyn. DX-johtajat voivat suorittaa kyselyjä neljännesvuosittain määrittääkseen, kuinka tyytyväisiä kehittäjät ovat työskentelemään projekteissa tai niiden osissa. He voivat tarkastella tiettyjä alueita, kuten CI-prosessia. Voit myös seurata tiimisi vaihtuvuutta. Jos huomaat, että ihmiset jättävät tiimin usein, he saattavat tuntea, että heidän huolenaiheitaan ei kuulla.

Työskenteleminen AI:n kanssa

AI-työkalujen nousu on tarkoitus tehdä kehittäjistä ja insinööreistä tuottavampia ja tuotteiden toimitus nopeammin, mutta tekninen velka hidastaa tätä. Oletetaan, että käytät työkalua, kuten GitHubia tai Copilotia, auttamaan koodin muutoksissa, sitten lähettäät pull-pyynnön, ja CI vie muutaman tunnin palataksesi sinulle. Sillä aikaa kehittäjä työskenteleekö jossain muussa? Tarkasteleeko sähköposteja? Se on kontekstin vaihto ja tuottavuuden tappaja.

Kehittäjät haluavat työskennellä tuotteissa, joissa he voivat vain keskittyä koodiin. Työkalut ovat siellä auttamaan heitä saamaan sen tuotantoon, eivätkä ne ole jatkuva este. AI voi säästää aikaa, mutta se on insinööritiimien tehtävä määritellä omat standardinsa hyväksyttävälle monimutkaisuudelle. Sen toteuttamiseksi varmista, että kaikki koodi, joka lisätään päähaaraan, on hyväksyttävän teknisen velan tasolla. Ennen sitä, pidä avoin keskustelu ja saa insinööritiimin hyväksyntä hyväksyttävälle teknisen velan ja koodin laadun rajalle. Varmista, että kaikki tietävät, että ylittäminen merkitsee välitöntä korjaamista. Kun olet määritellyt ne standardit, AI tulee mukaan.

On tapaus AI-agenteille, joissa insinöörit toimivat orkestraattoreina. Capgemini-tutkimuksessa 1 100:sta johtajasta suurissa yrityksissä paljastui, että 82 % aikoo integroida AI-agenteja seuraavien kolmen vuoden aikana, ja ne vaikuttavat jo tulevaisuuden työhön. Voit tarkastella virheilmoitusta ja nähdä, että se on tarpeeksi pieni AI-agentin käsiteltäväksi alusta loppuun, mikä säästää tiimisi aikaa ja vapauttaa heidät hoitamaan monimutkaisempaa työtä. Kuitenkin joskus, kun seuraamme näitä työkaluja sokeasti, on kompromisseja, joita AI ei pysty huomioimaan.

Se on silloin, kun ihmisen mielipide muodostuu ratkaisevaksi tekijäksi.

Teknisen velan kohdistaminen tavoitteisiin

Miten kohdistat teknisen velan vähentämistä tavoitteisiin, joita yrität saavuttaa tai mitattaviin tuloksiin? Se palaa hyväksyttävään tekniseen velkaan, ja joskus liiketoiminnassa on pakko toimittaa nopeasti. Voit tehdä sen tietäen, että tuote ei skaalaa, ja siinä voi olla suorituskykyongelmia myöhemmin. Usein kehittäjä tekee muistiinpanon tulla takaisin myöhemmin, kun on aikaa osoittaa näihin asioihin, mutta se harvoin tapahtuu. Ja kun tämä huono kulttuuri ottaa vallan, jossa on pakko toimittaa huomenna, teknisen velan vaikutus tulee selväksi.

Tämä on ymmärrettävää startup-yritykselle, mutta ei yritykselle, joka on toiminut kymmenen vuoden ajan. Sinun on aloitettava kulttuurin muuttaminen aikaisin ja aktiivisesti hallitaksesi teknistä velkaa; muuten sinun on vietävä paljon rahaa korjaamaan tuotannon virheitä tai huolehtimaan turvallisuudesta ja säädöksistä.

Lopulta on olemassa mittareita, joilla voidaan viestiä teknisen velan korjaamisen tai maksamisen arvoa sidosryhmille. Aika voi olla yksi, koodin kirjoittamisesta tuotantoon tai avatusta pull-pyynnöstä tuotantoon. Toinen on keskimääräinen korjausaika (MTTR). Tässä tapauksessa voit löytää virheen tai rikkinäisen rakennuksen ja mitata, kuinka kauan kestää tiimisi korjaaminen. Voit myös seurata virheiden määrää tuotannossa. Jos näet, että määrä kasvaa, siinä voi olla ongelma, joka liittyy tekniseen velkaan.

Tekninen velka korolla

Jokainen organisaatio voi omistaa muutaman tunnin viikossa parantamaan DX:äänsä vähentääkseen teknistä velkaa. Jos ei, sinun on maksettava siitä myöhemmin, luultavasti hitaalla suorituskyvyllä, kehitysnopeuden merkittävällä hidastumisella tai turvallisuusongelmilla. Esimerkiksi sinun tiimisi insinöörit ja kehittäjät olisivat voineet lykätä Ruby on Rails -päivityksiä kymmenen vuoden ajan. Yhtäkkiä projekti maksoi puoli miljoonaa dollaria enemmän, koska Ruby-versio oli neljä sukupolvea jäljessä, jättäen sinut massan koodin ja vanhentuneiden riippuvuuksien kanssa.

Jos olisit päivittänyt asteittain, et olisi tässä tilanteessa. Tuen sinun ohjelmistokehitystiimiäsi ja maksat mennessäsi. Muuten se tekninen velka tulee takaisin ja vaatii koron.