Ze vroegen een pdf-export. Die werd opgeleverd. Ze stopten toch met de tool te gebruiken.
Dit verhaal komt vaak genoeg voor om uitleg te verdienen, want het zegt iets over hoe software gespecificeerd hoort te worden.
Een gebruiker weet waar het pijn doet
De mensen die een tool elke dag gebruiken, zijn de beste bron die er is over wat er misloopt. Ze zijn zelden de beste bron over hoe het opgelost moet worden, en dat is geen kritiek: het is hun vak niet.
Een gevraagde functie is een symptoom dat zichzelf voor een voorschrift houdt. “Ik wil een pdf-export” betekent “ik verlies mijn maandagochtend aan het samenstellen van een rapport voor mijn leidinggevende”. De behoefte was nooit een knop. Het was de maandag terugkrijgen.
Bouw de knop, en de maandag is nog altijd verloren: het rapport moet nog steeds samengesteld worden, alleen de laatste stap gaat sneller. Begrijp de reden, en u ontdekt misschien dat het rapport zichzelf kan opmaken en versturen.
De echte redenen staan nooit op papier
Niemand vult een feedbackformulier in met “deze tool maakt mij moe”. Mensen denken het, ze werken om de tool heen, en op een dag zitten ze weer in hun spreadsheet.
Een tool wordt zelden opgegeven om wat eraan ontbreekt. Hij wordt opgegeven om wat het kost om hem te blijven gebruiken: de extra klikken, de dubbele invoer, het scherm dat niemand begrijpt.
De vraag die wij stellen
Voor wij bouwen wat gevraagd wordt, vragen wij één ding: “Wat probeerde u te doen, net voor u dit nodig had?”
Het antwoord verandert het project. Soms is de functie precies juist. Vaak wordt ze iets eenvoudigers. Af en toe verdwijnt ze, omdat de stap die ze moest versnellen geen reden van bestaan had.
Wat dat voor u betekent
Een lijst met functies die bij uw teams verzameld is, is een kostbaar vertrekpunt, en wij lezen er elke regel van. Maar een roadmap moet geen vragen beantwoorden. Hij moet redenen beantwoorden. Zo komt u uit bij minder schermen, een kleiner budget en een tool die mensen echt blijven gebruiken.