Hoe u een technical improvement backlog aanmaakt

Elk bedrijfssysteem dat langer dan een jaar bestaat, verzamelt een tweede, onzichtbare to-dolijst: de workarounds die niemand heeft opgelost, het rapport dat veertig seconden te lang duurt, de integratie die stilzwijgend drie keer opnieuw probeert voordat het werkt. De meeste teams praten alleen over deze lijst wanneer iets breekt. Dan is het al een noodgeval, geen plan.

Een backlog voor technische verbeteringen zet die onzichtbare lijst om in een zichtbare, geprioriteerde, begrote onderdeel van hoe je je software runt — op dezelfde manier als je roadmap voor functies zichtbaar is. Dit artikel beschrijft hoe je er daadwerkelijk een bouwt, wat erin thuishoort, en hoe je het in leven houdt in plaats van het te laten rotten in een spreadsheet die niemand opent.

Wat is een backlog voor technische verbeteringen, precies?

Het is een onderhouden, geprioriteerde lijst van bekende zwaktes in je bedrijfssoftware die niet vandaag moeten worden opgelost, maar je hoe langer ze worden genegeerd des te meer kosten. Beschouw het als gescheiden van je feature backlog (nieuwe dingen die het bedrijf wil) en je bug tracker (dingen die nu actief kapot zijn).

Typische items zien er als volgt uit:

• "De nachtelijke synchronisatie tussen FileMaker en Exact Online heeft geen foutregistratie — wanneer het mislukt, merkt niemand het totdat een klant klaagt over een ontbrekende factuur."
• "Het script voor factuurgoedkeuring was geschreven voor 3 goedkeuringsniveaus; verkoop gebruikt nu 6, en de workaround is gekopieerde logica op vier plaatsen."
• "Klai-gebaseerde AI-lookups in de supportmodule roepen de OpenAI API rechtstreeks aan vanuit de client zonder caching of rate limiting — dit wordt duur en traag naarmate het ticketvolume groeit."
• "De FmBetterforms weblayout voor het klantportaal is sinds het redesign van 2021 niet meer aangeraakt en werkt niet op nieuwere mobiele browsers."

Geen van deze situaties is kritiek. Ze verzamelen allemaal rente op schuld.

Waarom kun je dingen niet gewoon repareren zodra je ze opmerkt?

Omdat "repareer het wanneer we het zien" altijd verliest van "ship de volgende functie die het verkoopteam vraagt." Dat is geen disciplinekwestie — het is een incentivekwestie. Feature-werk heeft een zichtbare business case eraan gekoppeld (een klant, een deal, een deadline). Technische schuld doet dat zelden, totdat het wel zo is — meestal in de vorm van een storing, een beveiligingsincident, of een ontwikkelaar die je vertelt dat een taak van twee dagen nu twee weken duurt vanwege wat eronder zit.

Een backlog lost het incentiveprobleem op door de schuld zichtbaar, omvangrijk en planbaar te maken, zodat het kan concurreren om dezelfde aandacht in de planning als features in plaats van standaard te verliezen.

Wat hoort eigenlijk in de backlog?

Niet alles wat een ontwikkelaar annouk valt hoort hier. Gebruik deze categorieën als filter:

1. Structurele schuld — schema-snelkoppelingen, gedupliceerde bedrijfslogica, tabellen of scripts die organisch zijn gegroeid zonder herstructurering. Voorbeeld: een FileMaker-oplossing waarbij "klanttype"-logica wordt gecontroleerd met If-statements verspreid over 12 scripts in plaats van één centrale functie.
2. Integratiebreekbaarheid — connectors en API-aanroepen die vandaag werken maar geen monitoring, retry-logica, of versioneringsstrategie hebben. Voorbeeld: een API-connector naar een verzendprovider die stilzwijgend breekt op de dag dat de provider het v1-eindpunt afkeurt.
3. Prestatieverval — dingen die snel waren met 500 records en traag zijn met 50.000. Voorbeeld: een dashboardsamenvattingsveld dat bij elke layoutlading opnieuw wordt berekend in plaats van in cache te worden opgeslagen.
4. Beveiliging- en toegangsgaten — accounts met meer privileges dan nodig, onversleutelde exports, hardcoded credentials in een script.
5. Tooling- en afhankelijkheidsrisico — afhankelijkheid van een plugin, bibliotheek, of AI-service (zoals een onbeheerde Klai-integratie) zonder fallback als deze van prijs verandert, breekt, of wordt stopgezet.
6. Documentatiegaten — de ene aangepaste module die alleen één ontwikkelaar begrijpt, zonder opmerkingen en geen specificatie.

Als een item niet in een van deze categorieën past, is het waarschijnlijk een featureverzoek of een bug — stuur het naar de juiste lijst.

[[IMAGE:left|een trechter die issues sorteert in feature backlog, bug tracker, technische schuld backlog]]

Hoe vind je wat op de lijst thuishoort?

Je vindt de meeste technische schuld niet door te vragen "heeft iemand technische schuld te melden?" Het komt naar boven via specifieke triggers:

• Code review: elke pull request of scriptwijziging is een kans om een item "opgemerkt maar niet opgelost" vast te leggen.
• Supporttickets: terugkerende klachten over hetzelfde trage rapport of verwarrende scherm zijn schuldsingalen in vermomming.
• Een nieuwe ontwikkelaar inwerken: wat zij verwarrend vinden of waarvoor ze vragen "waarom is het op deze manier gebouwd?" is precies wat zou moeten worden gedocumenteerd en in de backlog opgenomen.
• Evaluaties na incidenten: na enig storing of datakwestie, vraag wat onderliggende zwakte het toeliet, niet alleen wat de onmiddellijke oplossing was.
• Geplande technische audits: een driemaandelijks doorloop van kernscripts, integraties, en layouts specifiek op zoek naar breekbaarheid, zelfs als niets momenteel broken is.

Hoe prioriteer je een technische backlog?

In tegenstelling tot featureverzoeken hebben technische items geen duidelijke zakengesprekspartner die erom duwt, dus je hebt een expliciete scoringsbenadering nodig. Een eenvoudig, werkbaar model:

Impact × Waarschijnlijkheid × Vertraging-kosten, elk ruwweg op een 1-3 schaal gescoord:

• Impact: hoe erg is het als dit misgaat, of hoeveel tijd verspilt het per week?
• Waarschijnlijkheid: hoe waarschijnlijk is het dat dit in de volgende 6-12 maanden daadwerkelijk een probleem veroorzaakt?
• Vertraging-kosten: wordt dit duurder om op te lossen naarmate je langer wacht (bijv. meer code gebouwd bovenop de snelkoppeling), of blijft het vlak?

Vermenigvuldig de drie, en je krijgt een ruwe prioriteringsvolgorde. Het zal niet perfect zijn, maar het is veel beter dan "wie het hardst klaagt krijgt eerst opgelost."

Hoe schrijf je een goed technisch backlog-item?

Een vaag item als "maak de factureringsmodule schoon" zal nooit worden ingepland, omdat niemand de omvang kan bepalen. Schrijf elk item als een mini-brief:

1. Wat is het, concreet? — noem het script, de tabel, de layout, of integratie.
2. Wat breekt of degradeert als het niet wordt opgelost? — een echt scenario, geen algemeenheid.
3. Ruwe schatting van inspanning — uren of dagen, zelfs als het een gok is.
4. Voorgestelde oplossing of richting — zelfs een regel ideeen bespaart later helemaal opnieuw nadenken.
5. Wie het heeft gemarkeerd en wanneer — voor context en om "is dit nog relevant?" debatten zes maanden later te vermijden.

Voorbeeld van een goed geschreven item:

Item: Foutafhandeling order-synchronisatie. Wat: Het FileMaker → ERP order-exportscript heeft geen logboekregistratie wanneer de API-aanroep mislukt; het slaat de record stilzwijgend over. Risico: Orders zijn in het afgelopen kwartaal twee keer verloren gegaan zonder dat iemand het dagenlang opmerkte. Inspanning: ~1 dag. Oplosrichting: Fouten registreren in een fouttabel en een Slack/e-mailwaarschuwing activeren. Gemarkeerd door: supportteam, na het incident in maart.

Hoeveel tijd zou je er eigenlijk aan moeten besteden?

Een veel voorkomende en werkbare regel: reserveer 15-20% van de ontwikkelingscapaciteit elke sprint of maand specifiek voor items uit de technische backlog, gescheiden van feature-werk. Behandel het als vaste kosten, niet als "als er tijd over is" bucket — omdat er nooit tijd over is.

Sommige teams doen het in blokken: één week van elke zes of acht uitsluitend toegewijd aan backlog-afbraak. Elk model werkt; wat telt is dat het wordt ingepland, niet geïmproviseerd.

[[IMAGE:right|een kalender met een terugkerend gereserveerd blok voor technische schuld-werk]]

Wie zou eigenaar van de backlog moeten zijn?

Iemand specifieks — meestal de leidende ontwikkelaar of IT-manager — zou eigenaar moeten zijn van het onderhoud: nieuwe items beoordelen, oude items sluiten, prioriteiten driemaandelijks opnieuw scoren. Zonder eigenaar groeit de backlog onbeheerd (alles wordt toegevoegd, niets wordt verwijderd) of sterft van verwaarlozing (niemand werkt het bij na de eerste maand).

Zakengesprekspartners en CEO's hoeven niet elke regel in te zien, maar zouden een korte driemaandelijkse samenvatting moeten zien: wat werd opgelost, wat staat nog open, en wat is het enkele riskantste wat nog op de lijst staat. Dat houdt technische schuld zichtbaar op het niveau waar budgetbeslissingen daadwerkelijk worden genomen.

Welke tools zou je gebruiken om het bij te houden?

Je hebt geen gespecialiseerde software nodig. Goede opties, ruwweg in volgorde van formaliteit:

• Een gedeelde spreadsheet met de bovenstaande velden — prima voor kleine teams.
• Een speciale lijst of board in het projecttool dat je al gebruikt voor features (Trello, Asana, Jira, Monday), duidelijk getagd als "technische schuld" zodat het gescheiden wordt gefilterd van feature-werk.
• Een lichtgewicht op maat gemaakte tracker in je eigen FileMaker-systeem — wat het voordeel heeft dat het direct naast het systeem leeft dat het bijhoudt, en kan zelfs backlog-items rechtstreeks aan de scripts, layouts, of tabellen koppelen die ze beschrijven.

Het tool maakt veel minder uit dan de gewoonte het daadwerkelijk te beoordelen.

Hoe hangt dit samen met het behoud van software op lange termijn?

Een backlog voor technische verbeteringen is eigenlijk het operationele mechanisme achter een groter idee: dat onderhoudbaarheid niet iets is wat je eenmalig bereikt tijdens een wederopbouw, het is iets wat je actief elke maand beheert naarmate het systeem blijft groeien. Onze gerelateerde gids over hoe je bedrijfssoftware onderhoudbaar houdt naarmate het groeit behandelt de bredere strategie die deze backlog ondersteunt — dit artikel is het concrete "hoe" voor een onderdeel van die strategie.

Snelle checklist: werkt je technische backlog eigenlijk?

• Bestaat het ergens anders dan in het hoofd van één ontwikkelaar?
• Is elk item concreet geschreven, met een echt risico en ruwe inspanning eraan gekoppeld?
• Is er een benoemde eigenaar die het regelmatig onderhoudt?
• Wordt er tijd voor gereserveerd in elke planningscyclus, niet alleen "als er ruimte is"?
• Zien zakengesprekspartners minstens driemaandelijks een samenvatting ervan?
• Zijn integratie- en AI-tool-afhankelijkheden (API's, connectors, services zoals Klai) opgenomen, niet alleen interne scripts?
• Worden oude items ooit gesloten als niet langer relevant, of groeit de lijst alleen maar?

Veelgestelde vragen

Is dit niet gewoon een ander naam voor een buglijst? Nee. Bugs zijn nu kapot. Items uit technische schuld werken nu maar degraderen, zijn breekbaar, of kostbaar om uit te breiden — ze zijn een weddenschap tegen toekomstige problemen, geen rapport van een huidigen.

Zal een zichtbare schuldlijst onze software slecht gebouwd doen lijken voor zakengesprekspartners? Meestal is het tegendeel waar. Een team dat naar een beheerde, geprioriteerde lijst van bekende risico's kan wijzen ziet er veel meer in control uit dan een dat beweert dat alles prima is totdat een storing het tegendeel bewijst.

Hoe groot is te groot voor een backlog? Als het meer dan 50-60 openstaande items heeft, is dat een teken dat items niet worden gesloten of voldoende genadeloos worden geprioriteerd. Een gezonde backlog krimpt actief op de goed begrepen items en groeit langzaam op echt nieuwe ontdekkingen — niet alleen groeiend.

Geldt dit voor systemen die we niet zelf hebben gebouwd? Zeker voor die. Erfde of verouderde systemen (inclusief oudere FileMaker-oplossingen gebouwd door een vorige ontwikkelaar) dragen bijna altijd meer verborgen schuld dan een jonge, actief ontwikkelde — ze erin auditeren is vaak de eerste nuttige stap voordat je enige code aanraakt.

Als je je eigen systeem in deze voorbeelden herkent — een synchronisatietaak zonder foutzichtbaarheid, een script vier keer herschreven door vier ontwikkelaars, een AI-integratie die niemand controleert — dat is meestal een teken dat het tijd is voor een gestructureerde blik, niet nog een snelle patch. Loggix helpt teams dat soort verborgen risico om te zetten in een concreet, geprioriteerd plan, of dat nu betekent dat je een bestaande FileMaker-oplossing auditeert, een API-connector hardent, monitoring rond een AI-tool als Klai toevoegt, of gewoon samen gaat zitten om in kaart te brengen wat eerst zou moeten worden opgelost en wat kan wachten.