Gebouwd, opgeleverd, en toch niet gebruikt

Waarom werkt geslaagde software soms niet?

Software die technisch werkt maar niet gebruikt wordt, is niet half geslaagd — die is mislukt. De meest voorkomende oorzaak is dat er precies gebouwd is wat er gevraagd werd. Dat klinkt als een compliment en het is de kern van het probleem.

Softwarebedrijven vertellen graag hoe strak hun proces is. Wij vertellen liever wat er misgaat, want daar hebt u meer aan.

Hoe zoiets eruitziet

Er ligt een opdracht. Er wordt drie weken gebouwd. De demo gaat goed, er zijn een paar kleine opmerkingen, en het gaat live.

Twee maanden later blijkt het oude Excel-bestand nog steeds bijgewerkt te worden.

Niemand heeft geklaagd. Er is niets kapot. Het scherm doet wat er was afgesproken. Het wordt alleen niet gebruikt, en dat is een stiller soort mislukking dan een fout — want een fout wordt gemeld.

Waarom “we hebben gebouwd wat er gevraagd was” geen verdediging is

Omdat degene die de vraag stelde, meestal niet degene is die ermee moet werken.

De vraag komt van iemand die het proces van bovenaf ziet: de directeur, de manager, degene die het budget heeft. Die weet wat er zou moeten gebeuren. Wat er in de praktijk gebeurt — inclusief de vier handigheidjes die iemand in de loop der jaren heeft bedacht — zit bij een ander.

Bouw je dan wat er gevraagd is, dan bouw je de bedoeling. En de bedoeling is niet het werk.

De vier redenen die wij het vaakst tegenkomen

Het nieuwe kost meer handelingen dan het oude. In het Excel-bestand typte iemand één regel. In het nieuwe scherm moet hij inloggen, zoeken, een klant kiezen en drie velden invullen. Netter, traceerbaarder, en langzamer — dus gaat de Excel gewoon door.

De uitzondering kan er niet in. Het systeem doet het gewone geval prima. Bij het eerste afwijkende geval loopt iemand vast, doet het dan maar even naast het systeem, en komt daarna niet meer terug.

Er is niet gevraagd wie het gaat gebruiken. Soms zit degene die ermee moet werken niet één keer aan tafel gedurende het hele traject.

Het vertrouwen ontbreekt. Daarover gaat software die niemand vertrouwt apart, want dat is een eigen probleem met een eigen oplossing.

Wat wij nu anders doen

Wij vragen naar de laatste keer, niet naar het proces. “Hoe werkt dit bij jullie” levert de bedoeling op. “Wat deed je gisteren toen die order binnenkwam” levert het werk op.

Wij bouwen eerst het kleinste stuk dat echt gebruikt kan worden. Niet een demo maar iets dat vanaf dag één in het echte werk meedraait, ook al doet het maar een derde. Wat daarna gevraagd wordt, is bruikbare informatie; wat in een demo gevraagd wordt, is een mening.

Wij kijken na twee weken of het gebruikt wordt. Niet of het werkt — of het gebruikt wordt. Dat is een andere vraag en het is de enige die ertoe doet.

En wij gooien weg wat blijft liggen. Een scherm dat na twee maanden niemand opent, halen wij eruit. Het kost onderhoud, het staat in de weg, en het houdt de illusie in stand dat het traject af is.

Dat laatste is ongemakkelijk, want het is werk waar voor betaald is. Het alternatief is erger: software die groeit terwijl het gebruik krimpt.

Waarom dit bij ons anders ligt dan bij een bureau

Wij bouwen niet op afstand. Iemand van ons zit bij het werk, ziet wat er gebeurt en merkt dat een scherm wordt overgeslagen voordat iemand dat meldt.

Dat is wat een forward deployed engineer doet, en het klinkt duurder dan het is: de dagen die het kost, zijn de weken die het scheelt aan bouwen wat niemand gebruikt.

Wordt het eigenlijk gebruikt?

Zoek een systeem dat u ooit hebt laten bouwen en kijk wie het gisteren geopend heeft.

Kunt u dat niet zien, dan is dat het eerste dat u wilt weten. Ziet u dat het niemand was, dan is de vraag niet of er iets bijgebouwd moet worden — dan is de vraag wat er in plaats daarvan gebruikt wordt, en waarom dat beter bevalt.