De complete workflow voor softwarebureaus: ticket, sprint, development, testing en facturatie

De keten in één overzicht

Tien fasen. De meeste bureaus doorlopen ze alle tien. Het verschil tussen een rustige en een chaotische maand zit vrijwel nooit in de kwaliteit van één fase, maar in hoeveel informatie de grenzen ertussen overleeft.

Fase 1 en 2: melding en intake

Alles verderop erft de kwaliteit van deze stap. Een ticket dat binnenkomt met klant, project, reproductiestappen en acceptatiecriteria kan worden geschat, ingepland en gebouwd door iemand die niet bij het oorspronkelijke gesprek zat. Een ticket dat binnenkomt als "het is weer stuk" vereist dat degene die de mail las er voor altijd bij betrokken blijft.

Faalpatroon: intake is van niemand, dus het gebeurt als iemand toevallig tijd heeft, meestal nadat de klant al heeft gerappelleerd. Signaal: developers vragen regelmatig in de stand-up wat een ticket eigenlijk betekent. De aanpak staat in van klantmail naar developer-ready ticket.

Fase 3: SLA en prioriteit

De prioriteit is geen gevoel, het is het contract. Elk niveau heeft een reactietijd en een oplostijd nodig, gekoppeld aan het ticket in plaats van aan een getekende pdf die niemand opent. Het systeem hoort te waarschuwen vóór een termijn, want een melding van overschrijding is een rapport over iets dat je had kunnen voorkomen.

Faalpatroon: alles is P2, en daarmee niets. Signaal: er wordt gewerkt aan het ticket waarvan de klant het laatst klaagde, niet aan het ticket met de dichtstbijzijnde termijn. Meer daarover in voorkomen dat klanttickets blijven liggen.

Fase 4 en 5: schatten en sprint

Er zijn twee eenheden in het spel, en die door elkaar halen is de meestgemaakte planningsfout bij bureaus. Story points geven de omvang van werk ten opzichte van ander werk. Capaciteit wordt gemeten in dagen, en alleen dagen concurreren met dagen.

Capaciteit hoort afgeleid te worden, niet ingetypt: werkdagen in de periode, minus contractuele parttimedagen, minus feestdagen, minus goedgekeurd verlof, minus een supportreserve op basis van je eigen historie. Als iemand verlof opneemt, hoort de sprint kleiner te worden zonder dat iemand daaraan moet denken.

Faalpatroon: de sprint wordt op koppen gepland en zit voor de start al 30 tot 40 procent overvol. Signaal: dezelfde drie tickets rollen elke sprint door en het team denkt dat het traag is. De volledige berekening staat in sprintcapaciteit plannen.

Fase 6: bouwen, in alle repositories van het project

Functionaliteit die de klant ziet, zit zelden in één repository. Het is een wijziging in de API, een beheerscherm, soms een mobiele app. Behandel je dat als drie tickets, dan krijg je drie schattingen, drie reviews en één integratieverrassing. Behandel je het als één wijziging met een pull request per repository, dan blijft de bedoeling op één plek staan.

Dit is ook de fase waarin AI-agents echt gewicht kunnen dragen: een planner die de codebase leest en zijn aanpak op het ticket schrijft voordat er code is, en een code-agent die de wijziging in de gekoppelde repositories doorvoert. Wat dat veilig maakt, is dat de run eindigt bij een openstaande pull request en nooit bij een merge. Zie AI coding agents voor softwareteams.

Faalpatroon: het ticket weet niet om welke repositories het gaat, dus niemand kan een uitgerolde wijziging terugleiden naar de melding. Signaal: "in welke release zat die fix?" kost meer dan een minuut.

Fase 7 en 8: verifiëren en review

Verifiëren beantwoordt een smalle vraag: doet de wijziging wat het ticket zei, zonder te breken wat al werkte. Goedkope controles eerst — linting, unittests — want een build die daarop faalt hoort niemands aandacht te kosten, mens noch model. Daarna wordt de applicatie echt gestart, en waar de wijziging dat verdient in een browser bediend.

Faalpatroon: review is een formaliteit, uitgevoerd door wie toevallig tijd heeft. Signaal: pull requests worden sneller goedgekeurd dan ze te lezen zijn. Dit patroon wordt erger, niet beter, zodra agents de code schrijven: een stempel op een door een agent geschreven wijziging voegt de schijn van review toe aan iets dat niemand bekeek.

Fase 9 en 10: uren, facturatie en de klantupdate

Uren op het ticket weten al bij welke klant en welk project ze horen, en daardoor is factureren nakijken in plaats van uitzoeken. Twee onafhankelijke factuurstatussen — één voor wat je de klant in rekening brengt en één voor wat een zzp'er jou factureert — voorkomen de twee meestgemaakte factuurfouten bij bureaus.

Deden AI-agents een deel van het werk, dan horen hun kosten op dezelfde plek: per fase geboekt, opgeteld per klant en project, met jouw opslag als het contract dat toelaat. Beide getallen, uren en machinekosten, op dezelfde klantregel. Zie urenregistratie per klant en AI-ontwikkelkosten per klant beheersen.

De laatste fase slaan bureaus het vaakst over: de klant vertellen wat er is gebeurd. Een automatische wekelijkse samenvatting per klantorganisatie — afgerond, nieuw, bijgewerkt, nog open, per project gegroepeerd — kost niemand tijd en haalt de meeste statusmails op maandag weg.

De vier koppelingen die de keten bijeenhouden

Tools samenvoegen is niet het doel. Het doel is dat deze vier relaties feiten zijn in plaats van gewoonten.

Kloppen die vier, dan maakt het aantal tools nauwelijks uit. Kloppen ze niet, dan houdt geen enkele integratie het afstemwerk tegen. Dat argument staat volledig uitgewerkt in meerdere klanten beheren zonder wildgroei aan tools.

Waar je als eerste ingrijpt

Je kunt geen tien fasen tegelijk aanpakken, en dat hoeft ook niet. In onze ervaring is de volgorde van rendement redelijk constant:

1. 1Intake. Het goedkoopst om te veranderen, en het verbetert elke volgende fase zonder extra kosten.
2. 2Uren schrijven op het ticket. Het snelst meetbare financiële effect, meestal zichtbaar binnen één factuurcyclus.
3. 3Eerlijke sprintcapaciteit. Verandert chronisch te veel toezeggen in een planningsgesprek in plaats van een moraalprobleem.
4. 4Signaleren van stille tickets. Haalt de meeste klantescalaties weg, en daarmee de meeste ongeplande onderbrekingen.
5. 5Herleidbaarheid van ticket naar repository. Maakt oplevering controleerbaar en is een voorwaarde om agents verstandig in te zetten.
6. 6AI-agents, met een budget en een mens bij de merge. Als laatste, want het loont pas als de vijf hierboven staan.

Die volgorde is niet theoretisch. Het is ongeveer de weg die ons eigen bureau heeft afgelegd, en elke stap werd pas de moeite waard doordat de vorige de kosten ervan zichtbaar had gemaakt.