Teknisk skuld förklarad för icke-tekniska grundare
Av CodexierPublicerad 5 min läsning
Förr eller senare får varje grundare höra att produkten har teknisk skuld, oftast som förklaring till varför en liten funktion tar veckor. Uttrycket låter som en anklagelse men beskriver en helt normal avvägning: ni kom ut snabbare genom att ta genvägar, och de genvägarna bromsar er nu. Den här guiden förklarar skulden i affärstermer, visar hur räntan syns i era siffror och ger er ett sätt att avgöra vad som ska betalas av, utan att läsa en rad kod.
Vad teknisk skuld egentligen är
Skulden kommer från tre håll. Medvetna genvägar för att hinna till en lansering, vilket är helt i sin ordning om någon noterade dem. Kunskap som kom senare, där lösningen var rätt för det ni visste då men fel för det ni vet nu. Och vanligt förfall: bibliotek åldras, plattformar ändras och säkerhetsuppdateringar hopar sig även om ingen rör koden. Bara den första är ett val. De andra två drabbar varje produkt.
Bra och dålig skuld
| Aspekt | Bra skuld | Dålig skuld |
|---|---|---|
| Varför den togs | För att testa en hypotes eller hinna till en verklig deadline | Av brådska, vana eller utan granskning |
| Är den nedskriven | Ja, med skäl och plan | Nej, upptäcks när något går sönder |
| Var den sitter | I delar som kanske slängs | I kärnan: betalningar, inloggning, datamodell |
| Kostnad att betala av | Känd och avgränsad | Okänd och växande |
Skuld i datamodellen och i säkerheten är dyrast, eftersom allt annat vilar på den och åtgärden ofta kräver att riktiga kunddata flyttas.
En MVP ska bära en viss skuld. Att bygga varje del för stora volymer innan ni har kunder är också slöseri, eftersom mycket av det ni bygger kommer att ändras när folk börjar använda det. Konsten är att ta genvägarna i produktens utkanter, som administrationsvyer och rapporter, och hålla kärnan ren: hur data lagras, vem som får se vad och hur pengar rör sig.
Så syns räntan
Ni ser inte skulden direkt, men ni ser räntan i affärstermer. Håll utkik efter de här symtomen och fråga teamet var de kommer ifrån.
- Uppskattningarna växer för ändringar som låter små, och de slår ofta fel.
- Samma sorts buggar kommer tillbaka efter att ha rättats.
- Nya utvecklare behöver veckor innan de vågar ändra något.
- Releaser är sällsynta och stressiga, görs sent på kvällen med alla i beredskap.
- Bara en person förstår en kritisk del av systemet.
- Beroenden är flera år gamla och uppgraderingen skjuts alltid upp.
Mät den utan att läsa kod
Ni kan följa skulden med några siffror som teamet kan ge er varje månad. Hur lång tid tar en vanlig ändring från idé till produktion? Hur många buggar når kunderna? Hur ofta släpper ni nya versioner? Hur gamla är de viktigaste ramverken och biblioteken? Finns automatiska tester för de delar som hanterar pengar och inloggning? Trenderna betyder mer än värdena: växer ledtiden medan teamet är lika stort ökar räntan. Be också om ett skuldregister, en enkel lista över kända genvägar med område, risk och ungefärlig kostnad att åtgärda.
En budget för avbetalning
Det som fungerar är ett jämnt och riktat arbete. Avsätt en fast del av varje sprint eller månad för avbetalning, överenskommen i förväg, så att den inte förhandlas bort varje gång en funktion är bråttom. Lägg den där produkten ändras mest och där risken är störst: säkerhet, betalningar och data först, sedan de moduler som färdplanen berör härnäst. Para ihop avbetalning med en funktion när det går, eftersom det är billigare att städa området ni ändå ska ändra än att städa det separat.
Betala av nu
Säkerhetsluckor, gamla beroenden med kända sårbarheter, skör kod för betalning och inloggning.
Betala av med nästa funktion
Moduler som finns i färdplanen de kommande månaderna.
Lev med det
Stabila delar som ingen ändrar, interna verktyg och sådant ni kanske avvecklar.
När ni inte behöver extern hjälp: för ert team ett skuldregister, släpper ofta och har stabila uppskattningar hanterar ni skulden bra. Känner ni igen symtomen ovan och ingen kan säga var skulden sitter börjar vår uppgradering för skalning och optimering med en genomgång och en prioriterad plan för avbetalning. Läs bygga om eller refaktorera innan någon föreslår en omskrivning, se prissidan eller boka ett samtal.
Vanliga frågor
Ska vi skriva om produkten från grunden?
Sällan. En omskrivning stoppar funktionsarbetet i månader och återskapar ofta gamla problem i ny kod. De flesta produkter mår bättre av att skulden betalas av modul för modul medan man fortsätter att leverera. En omskrivning är motiverad när själva plattformen inte längre stöds eller datamodellen inte bär verksamheten.
Hur mycket tid ska gå till teknisk skuld?
Det finns ingen universell siffra. Kom överens med teamet om en fast och synlig del av varje cykel, skydda den och justera den efter trenderna i ledtid och buggar. Noll är nästan alltid fel.
Är teknisk skuld ett tecken på att våra utvecklare är dåliga?
Nej. Alla produkter samlar på sig skuld, även de som byggs av utmärkta team. Varningssignalen är skuld som ingen följer upp eller pratar om, inte att skulden finns.
Påverkar teknisk skuld bolagets värdering?
Det kan den. Investerare och köpare som gör en due diligence tittar på kodkvalitet, säkerhet och hur beroende produkten är av enskilda personer. Dokumenterad och hanterad skuld oroar betydligt mindre än okänd skuld.
Ta reda på var produktens skuld sitter
Boka ett kort samtal och beskriv symtomen ni ser. Vi berättar vad en genomgång skulle titta på och om det är värt att göra nu.
Boka ett kostnadsfritt 15-minuterssamtal