Creofant.se

Kravpolitik och omnipotens

Det är med modeller för kravhantering som med politiska system: inga är perfekta. En tilltalande enkel modell är den rent diktatoriska. En kravställare äger rätten att på egen hand och efter egen godtycke definiera lösningen. Fördelen är att ansvar och befogenheter är kristallklara för alla inblandade. Ju mer upplyst despoten är, desto bättre är chanserna att lösningen blir vettig. Nackdelen är att modellen i det närmaste kräver en omnipotent kravställare, med förmågor som är snäppet bortom de rent allmänmänskliga. Det blir också lätt problem med legitimiteten i användarnas ögon. En viktig del av kravarbete är att få användare att känna sig delaktiga och därmed underlätta införsäljning och minska de mer eller mindre obligatoriska lanseringsvåndorna.

Det är därmed lätt att lockas att i stället anamma diktaturens rena antites: den direkta demokratin. Här har varje kravställare en egen kanal in i teamet med utvecklare, och påverkar lösningen högst konkret. Tyvärr sker det ofta på bekostnad av både planeringsbarhet och ett konsekvent förhållningssätt över tiden. Lösningar riskerar att kastas mellan olika särintressen, och vibrerar i värsta fall fram och tillbaka mellan tillstånd som tas bort, läggs till och tas bort igen. Den direkta demokratin har inga legitimitetsproblem, men modellen är naturligtvis både rasade ineffektiv och frustrerande otydlig. Vem som fattar beslut, när saker kan vara klara och vad målen är riskerar att bli rena spådomar.

Det gör att många lockas att satsa på den naturliga syntesen mellan dessa båda ytterligheter: en sorts representativ demokrati där en kravgrupp representerar användare i att föra fram behov och förankra lösningsförslag. Modellen är tillräckligt tydlig för att förstås och tillräckligt inbjudande för att användare ska känna sig delaktiga.

På papperet ser det ut att fungera. I praktiken har modellen ett antal problem som riskerar att göra den minst lika usel som de båda andra.

När väl kraven är insamlade och lösningen är färdigutvecklad kommer så lanseringen. I det ögonblicket börjar av naturliga skäl användare höra av sig och berätta vad som är fel, vilka undantag som måste stöttas och vilka hårda kanter som måste filas bort.

Alla dessa synpunkter ska naturligtvis tas på allvar, men här har kravgruppen ett särskilt stort ansvar – att stå för den lösning de har arbetat fram. Att delta i lanseringsarbetet och utbilda de kollegor som inte själva haft ett direkt inflytande över arbetet. Att tålmodigt förklara och försvara den valda lösningen.

Risken med modellen är just att detta ansvarstagande är så svårt. När kritiken från kollegor kommer är det alltför enkelt att vika undan, banga ansvaret och skylla på leverantören.

Konststycket ligger därmed i bygga en kravgrupp av kunniga, obekymrade och självständiga hårdingar som lyhört och i rätt tid tar till sig kollegor behov. Hur jag än vänder och vrider på problemet landar jag i samma deprimerande slutsats: en duktig kravställare måste vara omnipotent.