Hypoteser istället för kravinsamling?

I den här artikeln beskriver författaren en alternativ metod till "traditionell" kravinsamling. "Traditionell" kravinsamling hänvisar här till en kort, fristående aktivitet i början av ett projekt som resulterar i en dåligt underbygg kravspec som sedan inte ändras eller knappt används i projektet. Jag håller med om att en sådan kravinsamling är helt fel och i princip håller jag med om författarens alternativa metodbeskrivning.

Däremot är det som vanligt i de allra flesta IT-projekt enbart fokus på funktioner, eller egentligen inte ens funktioner. Det exempel som beskrivs är ju en direkt lösning på ett problem. Författarens metod löser detta delvis genom att beskriva ett sätt att effektivt och iterativt testa att den lösning man håller på att ta fram genererar värde för intressenterna.

Det är givetvis mycket bra, men jag menar att man skulle få en betydligt bättre träffsäkerhet i sina hypoteser/experiment om man började med att analysera vad grundproblemet är.

För att bygga på det aktuella exemplet:

Artikeln tar som exempel kravet (lösningen!) "The home page should contain links to today’s most commonly visited pages". Sedan analyserar de vilka antaganden detta bygger på och formulerar om det som "We believe having links to the most commonly visited pages is the best way to serve the user. Let’s find out if that’s true."

Detta är bra mycket bättre men säger ingenting om vilket problem man försöker lösa. På vilket sätt ska de "serva sina användare"? Vad är det användarna har för problem som de tror att de kan lösa genom att ha länkar till de mest besökta sidorna på sin startsida?

Istället borde vi ställa frågan "varför?" en gång till. "Varför tror ni att ni behöver länkar till de mest besökta sidorna på startsidan?" Svaret skulle kunna vara (och det här är endast ett exempel) "Därför att vi vill att våra användare snabbt ska få tillgång till den information som är relevant för dem". Vi är nu fria att formulera kravet som en produktkvalitet (tidigare "icke-funktionellt krav") istället för en lösning eller hypotes på en lösning, till exempel: "En användare utan tidigare erfarenhet av vårt system ska inom 120 sekunder kunna hitta en relevant artikel utan instruktion".

Denna formulering öppnar upp för oändligt mycket fler möjliga lösningar, t.ex. sökfunktionalitet eller trädorganiserad data, som alla kan formuleras som hypoteser som kan testas. En erfaren ingenjör kan då förmodligen avgöra vilken lösning som troligtvis bäst löser problemet. På så sätt kan man driva kreativitet och lättare prioritera bland alternativa lösningar som man vill testa.

/Alexander von Essen, Require AB