Hoe pak je support aan zonder dat je team focus verliest?
Focus
Elke CTO kent het probleem: je team is dapper nieuwe features aan het bouwen. Iedereen zit in the zone, en het gaat vlot vooruit.
Weg focus, weg planning
Dan krijgt Customer Support een dringende oproep: een klant is tegen een fout in je product aangelopen, en wil die fout snel opgelost zien.
Customer Support stormt het kantoor* van het development team binnen, en roept "er is een fout! Wie kan die oplossen?" Iedereen van de development team kijkt op... en iedereen is zijn/haar focus kwijt.
Het probleem gaat nog verder. Tijdens je sprintplanning had je immers geen rekening gehouden met dit soort onverwachte bugs. De developer die het probleem oplost, is al gauw een halve dag kwijt. Als dat één keer gebeurt in een sprint is dat meestal wel op te vangen. Maar als dit een paar keer gebeurt, zit die developer op den duur 's avonds door te werken om toch maar "zijn/haar werk gedaan te krijgen".
En nu?
Welke strategie kan je gebruiken om dit probleem te ondervangen? Je wil niet dat iedereen gestoord wordt bij een bug, én je wil tijd vrijmaken om bugs op te lossen. Tegelijk weet je dat het moeilijk is om iemand te vinden die fulltime bugs wil oplossen én zich ook zo goed in de code kan verdiepen dat-ie ook in staat is om die bugs op te lossen.
Tada-dada-tada-dada-tada-data-BATMAN!
Een mooie oplossing hiervoor is om de rol van bug-fixer elke week toe te kennen aan een andere developer. Geef die rol een coole naam - wij noemden die De Batman. Elke niet-developer weet: als er een probleem is, bel ik De Batman.
De Batman is in staat om een aantal bugs zelf op te lossen. Als-ie ze zelf niet kan oplossen, weet ie goed wie het wel kan oplossen. Hij/zij moet dan maar één developer gaan storen, en niet het hele team.
Een heel mooie bijwerking is dat elke developer wel eens met elk onderdeel van je product in aanraking komt. Ik hoor regelmatig developers vertellen dat ze altijd in één hoekje van de code zitten, en eigenlijk niet weten wat er in een ander hoekje gebeurt. Dat is geen gezonde situatie; als CTO heb je graag mensen die wat overzicht hebben.
In je sprintplanning voorzie je tijd voor De Batman om zijn/haar rol uit te oefenen. Je gaat na verloop van tijd leren hoeveel tijd dat is. Je kan bijvoorbeeld bij 50% beginnen, en dat later aanpassen. Houd er wel rekening mee dat support geen constante stroom is; de ene week is De Batman misschien 75% van de tijd support aan het leveren, en de volgende week slechts 25%.
En ja, je mag die rol ook Thor of Hulk noemen als Marvel meer je ding is.
* Toen ik dit schreef was het februari 2021. Op dit moment stormt Customer Support eerder de Slackroom "Development" binnen met een "@channel", maar het effect is hetzelfde.