Tehnički dug rijetko stiže s računom. Pojavljuje se kao „privremeno” zaobilazno rješenje koje postaje trajno, izdanje koje zahtijeva da određena osoba bude dostupna ili procjena funkcionalnosti koja se stalno povećava jer nitko nema povjerenja u okolni kod.

Opasnost nije u tome što tehnički dug postoji. Svaki ga proizvod akumulira. Opasnost je u tome da ga se tretira kao tuđi problem: inženjerski problem za poslije, produktni problem za neko drugo tromjesečje ili upravljački problem tek kada se isporuka dovoljno uspori da to postane vidljivo.

Snažno tehničko vodstvo počinje jednostavnijim stajalištem: ako kompromis danas pomaže isporučiti vrijednost, netko sutra mora preuzeti odgovornost za njegove posljedice.

Tehnički dug je produktna odluka

Timovi tehnički dug često opisuju kao neuredan kod, zastarjele ovisnosti ili testove koji nedostaju. To su stvarni oblici duga, ali definicija je šira. Tehnički dug je svaki prečac koji stvara budući trošak u zamjenu za sadašnju korist.

Zbog toga je on produktna odluka jednako kao i inženjerska. Odluka da se pokrene ručni radni tijek prije njegove automatizacije može biti potpuno ispravna. Isporuka ograničene integracije radi provjere potražnje može biti mudra. Odgađanje redizajna može zaštititi ključni rok.

Problem počinje kada je kompromis skriven. Prečac bez imenovanog vlasnika, razloga i točke preispitivanja nije promišljena odluka. To je jednostavno buduće iznenađenje.

Produktni lideri ne trebaju propisivati arhitekturu. Trebaju razumjeti operativni učinak nakupljenog duga: sporije eksperimentiranje, veći rizik od nedostataka, krhko uvođenje novih članova i plan razvoja koji sve više oblikuje ono što će sustav tolerirati, a ne ono što kupci trebaju.

Učinite dug dovoljno vidljivim da njime možete upravljati

Ne možete dati prioritet nevidljivom zaostatku posla. Koristan registar duga trebao bi biti jednostavan, konkretan i povezan sa stvarnim produktnim ishodima. Izbjegavajte neodređene stavke poput „počistiti backend” ili „poboljšati kvalitetu”. Preširoke su da bi se o njima iskreno raspravljalo i previše ih je lako odgađati unedogled.

Umjesto toga, opišite kompromis, njegovu posljedicu i okidač za njegovo rješavanje. Na primjer: „Izvoz podataka za naplatu izvršava se kao ručni posao; ovisi o jednom stroju s kontroliranim pristupom i odgađa odgovore korisničke podrške. Automatizirati ga prije dodavanja drugog formata izvoza.”

Takvo uokviravanje pretvara apstraktan inženjerski zahtjev u odluku koju ljudi mogu procijeniti.

• Što smo odgodili? Jasno imenujte komponentu, radni tijek ili odluku.
• Zašto je prečac bio razuman? Sačuvajte kontekst; sprječava naknadno okrivljavanje.
• Koji je trenutačni trošak? Uključite kašnjenja, operativni trud, rizik ili blokiran produktni rad.
• Tko je vlasnik sljedeće odluke? Vlasništvo može biti zajedničko, ali nikada ne bi smjelo biti anonimno.
• Što će pokrenuti akciju? Povežite rad s datumom, obvezom prema kupcu, pragom opsega ili nadolazećom funkcionalnošću.

Ovo nije administracija radi administracije. To je način da promišljeni kompromisi ostanu promišljeni.

Razlikujte dug od nelagode

Ne zahtijeva svaki nesavršen sustav trenutačnu pozornost. Razvojni inženjeri prirodno će primijetiti grube rubove, duplicirani kod, nespretna imenovanja i alate koje više ne bi odabrali. Neki od tih problema važni su; neki su jednostavno nelagoda.

Test je povećava li problem opetovano trošak ili rizik smislenog rada. Usporava li promjene? Stvara li neizvjesnost u produkciji? Ograničava li tko može doprinositi? Prisiljava li tim da izbjegne vrijednu produktnu odluku?

Ako je odgovor ne, možda pripada na osobni popis poboljšanja, a ne na plan razvoja. Ako je odgovor da, zaslužuje izričit produktni razgovor.

Ova razlika štiti timove u oba smjera. Sprječava beskrajno dotjerivanje prerušeno u strategiju, a liderima sprječava da važan inženjerski rad odbace kao stvar preferencije.

Ugradite otplatu u redovitu isporuku

Otplata duga najbolje funkcionira kada je dio planiranja, a ne hitan slučaj koji se natječe sa svakom funkcionalnošću. Održiv tim ne čeka da kodna baza postane neizdrživa prije ulaganja. On radi mala, redovita poboljšanja dok isporučuje vrijednost kupcima.

Jedan praktičan pristup jest povezati tehnički rad s funkcionalnošću koja otkriva slabost. Ako novi model korisničkih dozvola zahtijeva izmjene u krhkom sloju autorizacije, poboljšajte taj sloj kao dio funkcionalnosti. Tim već plaća trošak promjene konteksta, a produktni je razlog lako objasniti.

Neki dug zahtijeva posvećen rad, osobito kada utječe na pouzdanost, sigurnost, implementaciju ili brzinu razvoja kroz mnoge funkcionalnosti. U tim slučajevima navedite očekivani ishod operativnim izrazima. „Smanjiti vrijeme izgradnje” manje je korisno od „učiniti uobičajeno pokretanje provjere dovoljno brzim da ga suradnici koriste prije traženja pregleda.”

Jasni ishodi potiču bolje kompromise. Također omogućuju odluku kada je predloženo čišćenje preveliko za svoju vrijednost.

Koristite male granice za smanjenje rizika

Velika prepisivanja često su privlačna jer obećavaju čist početak. Također ih je lako podcijeniti. Dok tim iznova gradi interni sustav, potrebe kupaca nastavljaju se mijenjati, stari i novi putevi možda će morati postojati istodobno, a prepisana verzija može naslijediti iste nejasne pretpostavke.

Kada je moguće, radije odaberite niz reverzibilnih poboljšanja:

1. Zaštitite trenutačno ponašanje ciljanim testovima, nadzorom ili dokumentiranim provjerama.
2. Odvojite jednu nestabilnu granicu, poput integracije treće strane ili poslovnog pravila s mnogo pozivatelja.
3. Premještajte po jedan slučaj upotrebe na novi put.
4. Uklonite stari put tek nakon što se zamjena dokazala u redovitom radu.

Ovaj je pristup manje dramatičan, ali stvara napredak koji proizvod može podnijeti. Također udaljenim timovima daje jasnije kontrolne točke: zajedničku definiciju onoga što se promijenilo, kako je provjereno i što je namjerno ostalo odgođeno.

Vlasništvo je važnije u udaljenim timovima

U zajedničkom uredu nedokumentirano znanje može preživjeti dulje nego što bi trebalo. Netko načuje problem s implementacijom, prepozna naziv usluge ili zna koga treba pitati. Distribuirani timovi imaju manje slučajnih predaja. Nejasnoća brže postaje skupa.

Zato bi vlasništvo nad tehničkim dugom trebalo biti vidljivo na istim mjestima na kojima se rad planira i raspravlja. Kratka pisana odluka može uštedjeti sate ponavljanih objašnjenja: što je odabrano, zašto je tada bilo dovoljno sigurno, koji bi signali promijenili odluku i tko će je ponovno razmotriti.

Ova je praksa osobito vrijedna za razvoj inženjera. Mlađi inženjeri uče da kvaliteta nije perfekcionizam. Stariji inženjeri pokazuju prosudbu objašnjavajući kompromise, a ne tiho preuzimajući svu složenost. Produktni partneri uče uključiti inženjere u odluke rano, prije nego što se opseg učvrsti oko pretpostavke koju sustav ne može sigurno podržati.

Mjerite prave znakove upozorenja

Ne trebate složen rezultat da biste znali postaje li dug opasan. Obratite pozornost na ponavljajuće signale: procjenama dominiraju „nepoznanice”, izdanja zahtijevaju herojsko usklađivanje, incidenti se stalno vraćaju na isto područje ili tim izbjegava mijenjati komponentu za koju svi znaju da je važna.

Ti bi signali trebali potaknuti pitanje: koju konkretnu sposobnost gubimo? Odgovor može biti sposobnost sigurne isporuke, brze podrške kupcima, učinkovitog zapošljavanja ili testiranja novih ideja. Ta je sposobnost poslovni razlog za djelovanje.

Ostavite budućim timovima bolju odluku

Tehnički dug nije moralni neuspjeh. On je zapis odluka donesenih pod stvarnim ograničenjima. Standard nije ukloniti svaki kompromis. Standard je učiniti kompromise vidljivima, ograničenima i otplativima prije nego što tiho postanu arhitektura poslovanja.

Preuzmite odgovornost za prečac kada ga stvorite. Objasnite njegovu vrijednost i njegov trošak. Dajte mu mjesto, okidač i osobu odgovornu za njegovo ponovno razmatranje. Ta disciplina čini više od poboljšanja koda: održava vaš proizvod prilagodljivim, vaš tim vjerodostojnim, a vaše buduće mogućnosti očuvanima.