„Het is maar een momentje”
Iedereen die werkt aan het bouwen of onderhouden van een website, applicatie of systeem kent deze opmerking.
„Kunnen jullie alleen even die knop veranderen?”
„Het is echt maar een kleine aanpassing.”
„Zou je dat element even kunnen schuiven?”
„Kunnen jullie dat snel doen?”
„Dat is vast vijf minuten werk, toch?”
En soms is dat inderdaad zo.
Soms kost het wijzigen van de kleur van een knop slechts enkele minuten. Soms verhelpt één klik een typefout. Soms opent de ontwikkelaar de code, ziet het, past één regel aan en is het klaar.
Het probleem is dat niet elke wijziging die vanuit gebruikersperspectief klein lijkt, ook klein is vanuit het systeem.
En een nog groter probleem ontstaat wanneer er tientallen of honderden van zulke „kleine wijzigingen” per maand zijn. Dan gebeurt er iets interessants.
Het bedrijf kan het gevoel hebben dat er eigenlijk niets groots wordt besteld. Tegelijk besteedt het IT-team veel van zijn tijd aan precies die kleine taken.
En hier rijst de vraag: Wat kost één knop 'Maak dit snel goed' echt?
Laten we beginnen met een eenvoudig voorbeeld
Stel je voor dat de marketingafdeling een bericht naar het softwarebureau stuurt:
„Hé, we moeten alleen de tekst op een knop veranderen. In plaats van ‘Bekijk aanbod’ moet het ‘Ontdek ons aanbod’ zijn. Het is een kleine zaak, graag snel gedaan.”
Klinkt banaal. Maar vanaf technisch oogpunt kan het er heel anders uitzien.
De ontwikkelaar moet:
1. Het verzoek analyseren
Waar staat die knop?
Staat hij maar op één plek?
Komt hij in meerdere versies van de site voor?
Is de tekst direct in de code ingegeven?
Wordt het beheerd via een CMS?
Gaat de wijziging over desktop- en mobiele versies?
Is de knop onderdeel van een component dat op andere plekken gebruikt wordt?
2. De wijziging doorvoeren
Tekst aanpassen.
Component herstructureren.
Inhoud in het CMS bijwerken.
Of code wijzigen.
3. Het resultaat controleren
Ziet de knop er nog correct uit?
Komt de tekst niet buiten het knopgebied?
Werkt alles op de telefoon?
Heeft de wijziging geen effect op andere plekken?
4. Testen
Is de knop klikbaar?
Leidt de link naar de juiste bestemming?
Is er geen fout ontstaan?
5. De wijziging uitrollen
Als de wijziging een deploy vereist, moet die naar productie worden gebracht.
En plots blijkt: „Alleen tekst wijzigen”
betekent niet per se: „Slechts 5 minuten werk”.
Wat kan één kleine wijziging kosten?
Laten we een heel conservatief scenario aannemen.
De ontwikkelaar besteedt:
- 15 minuten aan analyse,
- 20 minuten aan implementatie,
- 15 minuten aan testen,
- 10 minuten aan voorbereiding en uitrol.
Totaal: 60 minuten werk.
En hier komen we bij een belangrijk punt. Als het uurtarief van het team bijvoorbeeld 200 zł netto is, kost één ogenschijnlijk kleine wijziging ongeveer: 200 zł netto.
Maar dat is nog niet alles. In het echte proces kan er extra tijd bijkomen door:
- overdracht van de taak,
- nauwkeuriger scopebepaling,
- vragen aan de klant,
- wachten op een antwoord,
- controle door de aanvragende persoon,
- aanpassingen na feedback,
- hernieuwde uitrol.
Een uur kan dus heel gemakkelijk twee worden. En één kleine wijziging kan enkele uren van het hele team vergen.
Het duurste is niet het uitvoeren van de wijziging
Dit klinkt misschien paradoxaal. Soms kost de uitvoering zelf 10 minuten. Maar de voorbereiding kost nog eens 20. Daarna volgen tests, uitrol, communicatie en het terugbrengen van de context.
En juist dat laatste element wordt vaak onderschat.
Context switching - de verborgen kosten van kleine taken
Een ontwikkelaar werkt aan een grote functie. De code is open. Hij analyseert het probleem. Hij is gefocust.
Plotseling verschijnt er een bericht: „Hé, alleen een klein dingetje. Kun je even die knop aanpassen?”
De ontwikkelaar stopt zijn werk. Opent het ticket. Bekijkt de site. Zoekt de plek in de code. Voert de wijziging door. Test. Rolt uit. Keert terug naar de vorige taak...
En dan moet hij zich herinneren: „Waar was ik ook alweer mee bezig?”
Dat is precies context switching, het wisselen van context. En het kan erg kostbaar zijn. Niet omdat elke afzonderlijke wijziging veel werk kost, maar omdat elke wijziging het denkproces onderbreekt.
Hoe complexer de taak, hoe groter de kosten om weer op gang te komen. Daarom betekent 10 micro-taken niet altijd 10 × 10 minuten. In de praktijk kan het veel meer zijn.
Één knop is niets. Honderd knoppen is een proces.
Stel dat een bedrijf het technische team maandelijks:
- 20 kleine wijzigingen laat doen,
- elk gemiddeld 45 minuten kost.
Dat geeft: 15 uur werk per maand.
Bij een tarief van 200 zł netto: 3000 zł netto per maand.
Per jaar: 36.000 zł netto.
En we hebben het slechts over 20 kleine taken per maand. Zonder grote functionaliteiten. Zonder productontwikkeling. Zonder nieuwe modules. Zonder integraties. Zonder design.
Alleen: „verander”, „corrigeer”, „verplaats”, „voeg toe”, „verwijder”.
Stel je nu een organisatie voor met 50 taken per maand. Of 100.
Schaal ziet er dan heel anders uit...
Micro-taken hebben nog een kostenpost - ze blokkeren ontwikkeling
Dit is een van de belangrijkste onderdelen van het geheel.
Als een ontwikkelteam 20% van de tijd besteedt aan kleine correcties, kan het die 20% niet aan productontwikkeling besteden. Dat klinkt evident. Maar in de praktijk zie je het vaak niet direct.
Het bedrijf vraagt: „Waarom is die nieuwe functie nog niet af?”
De ontwikkelaar antwoordt: „Omdat we veel lopende zaken hadden.”
„Welke dan?”
„Correcties, kleine wijzigingen, updates, kleine taken.”
Elk daarvan was klein. Maar samen vormden ze een enorme blokkade. Het lijkt een beetje op meldingen op je telefoon. Één notificatie stoort niet. Tien al wel. Honderd? Plots blijkt dat je de hele dag bezig bent met reageren.
Met micro-taken is het hetzelfde.
„Kleine taak” is niet altijd een kleine taak
Belangrijk om te begrijpen is dat niet elke wijziging hetzelfde is. Tekst aanpassen in een CMS kan echt een paar minuten zijn.
Maar tekst aanpassen in een applicatie kan vereisen:
- het vinden van het component,
- code aanpassing,
- updaten van vertalingen,
- testen,
- herbuild van de applicatie,
- uitrol.
Het aanpassen van één veld kan wijzigingen vergen in:
- frontend,
- backend,
- database,
- API.
Het wijzigen van één element in het systeem kan andere onderdelen beïnvloeden.
Daarom is de vraag: „Hoe lang duurt het om die knop te veranderen?”
zonder kennis van de systeemarchitectuur vaak niet goed te beantwoorden.
Eerst moet je controleren. Pas daarna kun je inschatten.
Waarom zegt een ontwikkelaar soms: „Ik moet het even checken”?
Dat is geen ontwijking. Het is vaak een teken van professionaliteit.
Een goede ontwikkelaar zou niet moeten beloven: „Ja, natuurlijk, vijf minuten”,
als hij niet weet wat er onder de motorkap zit.
Hij zou moeten zeggen: „Ik kijk waar dat element gebruikt wordt en geef je daarna een terugkoppeling.”
Dat kan 10 minuten duren. Maar die 10 minuten kunnen uren aan problemen besparen. Want de duurste wijziging is vaak niet degene die een uur kost.
De duurste is degene die:
- een andere functie kapot maakt,
- een fout in productie veroorzaakt,
- een urgente rollback vereist,
- veel nieuwe tickets genereert,
- interventie van meerdere mensen nodig maakt.
Daarom is analyse vóór de wijziging onderdeel van het werk, geen tijdverspilling.
Hoe kan de klant de kosten van micro-taken verlagen?
Het gaat niet om stoppen met het melden van kleine wijzigingen. Kleine wijzigingen horen bij productontwikkeling. Het gaat erom ze goed te managen.
1. Groepeer kleine taken
In plaats van te sturen:
„Verander die knop.”
„Pas nog even de koptekst aan.”
„En voeg deze link toe.”
„En verplaats dat element.”
is het beter ze in één pakket te bundelen.
Het team kan dan meerdere wijzigingen in één werkcyclus doorvoeren.
Minder context switching.
Minder communicatie.
Minder deploys.
Lagere kosten.
2. Stel prioriteiten
Niet alles is urgent.
Als alles de status:
DRINGEND
heeft, is niets echt urgent.
Het is nuttig taken in te delen in:
- kritisch,
- belangrijk,
- gepland,
- cosmetisch.
Zo kan het team effectiever werken.
3. Denk na of je een codewijziging echt nodig hebt
Als een bedrijf regelmatig teksten, foto’s, banners, links of meldingen wijzigt, is het misschien geen probleem van ontwikkelaarsnelheid.
Het kan een architectuurprobleem zijn.
Als elke inhoudswijziging een ontwikkelaar vereist, is het de moeite waard na te denken over een CMS of een adminpaneel.
Een goed ontworpen systeem stelt zakelijke gebruikers in staat zelf te beheren wat geen programmeerinmenging behoeft.
Een goed systeem beantwoordt de vraag: wie moet deze wijziging uitvoeren?
Dit is een belangrijk ontwerprincipe. Niet elke wijziging moet bij een ontwikkelaar terechtkomen.
Als marketing zelf kan:
- tekst wijzigen,
- foto vervangen,
- een artikel toevoegen,
- de volgorde van secties veranderen,
dan heeft het geen zin een ontwikkelaar erbij te betrekken.
Ontwikkelaars moeten zich bezighouden met wat hun expertise vereist.
Dus onder andere:
- nieuwe functies bouwen,
- het systeem verder ontwikkelen,
- integraties,
- optimalisatie,
- veiligheid,
- architectuur,
- technische problemen oplossen.
Anders betaalt het bedrijf een ontwikkelaar voor werk dat een systeemgebruiker zelf had kunnen doen.
Het is een beetje alsof je een automonteur huurt om je auto vol te tanken. Ja, hij kan het. Maar heb je dat echt nodig?
Wanneer is het tijd om te zeggen: „Laten we het anders doen”?
Als dezelfde verzoeken regelmatig terugkeren, is het goed stil te staan en de vraag te stellen:
Waarom moeten we dit telkens handmatig doen?
Als we wekelijks om wijziging van hetzelfde element vragen, moeten we misschien:
- een instelling in het CMS maken,
- configuratie aanbieden,
- een beheerderspaneel bouwen,
- automatiseren,
- self-service mechanismen inrichten.
De eenmalige kosten voor het bouwen van zo’n oplossing kunnen hoger zijn. Maar daarna kan elke volgende wijziging seconden in plaats van uren kosten.
Dat is het verschil tussen: betaald worden per wijziging en investeren in een systeem dat wijzigingen zelfstandig mogelijk maakt.
Micro-taken en het samenwerkingsmodel met een softwarebureau
Dit is ook belangrijk voor klanten.
Als samenwerking met een softwarebureau uitsluitend volgens het model „melden - schatten - goedkeuren - uitvoeren” verloopt, kan elke kleine wijziging extra organisatorische lasten veroorzaken.
Daarom werken bij langdurige samenwerking vaak beter:
- uurtijdpakketten,
- onderhoudsabonnementen,
- een vast team,
- een takenbacklog,
- regelmatige sprints,
- afgesproken uitrolvensters.
Dat betekent niet dat elke klant hetzelfde model moet kiezen. Het gaat om het afstemmen van de manier van samenwerken op het project.
Als een bedrijf één wijziging per maand nodig heeft, kan een uitgebreid proces overbodig zijn. Als een bedrijf 50 taken per maand stuurt, kan het ontbreken van proces erg duur zijn.
Moet elke wijziging worden doorberekend?
Dat hangt ervan af.
In sommige projecten is het zinvol exacte tijdregistratie per minuut te doen. In andere projecten veroorzaakt dat meer administratie dan besparing.
Daarom is het belangrijk de samenwerking breder te bekijken.
De belangrijkste vraag is niet: „Wat kostte die ene wijziging?”
Een betere vraag is: „Wat kost de manier waarop we al onze wijzigingen beheren?”
Als een bedrijf 200 zł per wijziging betaalt maar daardoor fouten vermijdt en zekerheid heeft dat alles correct werkt, kan dat een redelijke investering zijn.
Als een bedrijf daarentegen elke maand enkele duizenden zł betaalt voor tientallen vergelijkbare micro-taken, is het de moeite waard te onderzoeken of het probleem niet systemisch opgelost kan worden.
De duurste woorden in IT?
Misschien zijn het: „Het is maar een kleine wijziging.”
Niet omdat kleine wijzigingen slecht zijn. Ze zijn nodig.
Een digitaal product leeft. Klantbehoeften veranderen. De markt verandert. Marketing verandert. Technologie verandert. Wijzigingen zijn natuurlijk.
Het probleem ontstaat wanneer een organisatie de cumulatieve kosten niet ziet.
Eén kleine wijziging? - Niets bijzonders.
Tien? - Nog steeds weinig.
Honderd? - Dat is al een proces.
En als er tientallen van zulke processen zijn? Dan blijkt dat het bedrijf niet in productontwikkeling investeert, maar continu betaalt voor het repareren van kleinigheden.
In plaats van knopjes te tellen, tel je tijd
Goed beheer van digitale productontwikkeling betekent niet dat je de klant verbiedt kleine wijzigingen te melden.
Het betekent weten:
- welke wijzigingen echt een ontwikkelaar nodig hebben,
- welke zelfstandig kunnen worden uitgevoerd,
- welke geautomatiseerd moeten worden,
- welke gebundeld moeten worden,
- welke echt urgent zijn,
- welke gepland kunnen worden,
- welke systemisch opgelost moeten worden.
Omdat het beste antwoord op: „Maak dit snel goed.”
niet altijd is: „Oké, we doen het.”
maar: „Laten we bedenken waarom we het over een maand weer moeten aanpassen.”
Daarom wordt het softwarebureau niet alleen een uitvoerder van taken, maar een technologische partner. Een goede partner voert niet alleen tickets uit.
Hij helpt ook te zien dat soms de goedkoopste wijziging niet degene is die we sneller uitvoeren, maar degene die we niet steeds opnieuw hoeven te doen.
En daarom kan één knop 'Maak dit snel goed' een uur kosten.
Maar een goed ontworpen systeem kan ervoor zorgen dat de volgende honderd van zulke wijzigingen je zelf binnen enkele minuten lukken.
Dat is geen bezuiniging op ontwikkelaars. Het is een investering in een beter proces, betere architectuur en slimmer gebruik van de tijd van het hele team.
