Kan du skilja på vad och hur?

En av de främsta orsakerna till problematiska projekt med missnöjda kunder är det som kallas ”Scope Creep” – de rörliga kraven, eller den ”dynamiska kravmängden”. Många tror att det beror på att produktkraven inte är tillräckligt tydligt definierade eller att de inte är testbara. Jag vill påstå att roten till problemet ligger tidigare i upptäckskedjan, jag pratar om Business Requirements, de riktiga verksamhetskraven. Om produktkraven inte hänger ihop med verksamhetskraven, spelar det ingen roll hur tydliga, välskrivna och testbara produktkraven är. Som vanligt är det så lätt att rusa fram till tåget som håller på att gå, utan att stanna upp och kontrollera att det verkligen går till den tänkta destinationen.

Första steget är att lära sig skilja på VAD och HUR, och att inse att inom varje HUR så finns det även mer detaljerade VAD som i sin tur kan brytas ner och bli mer specifika HUR. Det är skillnad på den abstrakta beskrivningen av en lösning och den mer detaljerade lösningsbeskrivningen.

Varje VAD innehåller HUR och Varje HUR innehåller VAD…

Att bara se Business Requirements som något ”vagt och luddigt” kryddat med lite syfte, mål och massor av personligt tyckande, är en säker väg till projektkatastrof. Det finns ingen magisk formel som bryter ner otydliga och ofullständiga verksamhetskrav till detaljerade produktkrav*.

Nedan visas en enkel informationsmodell som kan underlätta förståelsen av relationen mellan Business Requirements och Product Requirements kan se ut. Vi pratar om att förstå verksamhetens syfte och mål (Business Objectives) och dess regler (Business Rules). Affärseglerna är en typ av CONSTRAINTS (det finns andra begränsningar som styr lösningsvalet, mer om det i en annan artikel.)
Genom att förstå de VERKLIGA behoven i verksamheten kan man representera verksamhetskraven i verksamhetsanvändarnas eget språk (eventuellt turboladdat med enkla effektiva visualiseringar). När de uppfylls, möts och levereras, tillför de verkligt värde i verksamheten, löser verkliga problem, möter nya utmaningar med kraft och öppnar nya möjligheter. Verksamhetskraven är i grunden konceptuella och måste därför UPPTÄCKAS, KOMMUNICERAS, UPPLEVAS och KREATIVT FRAMLOCKAS, de kan aldrig bara skrivas ner.

Bland alla de möjliga lösningarna (det finns ALLTID flera möjliga lösningar på verksamhetens kravmängd) görs sedan ett aktivt val av de som är bäst lämpade att förstå de verkliga verksamhetskraven och lösningsförslagens möjligheter. Vi pratar om en grupp bestående av kravingenjören, arkitekten och andra relevanta intressenter.
Den valda lösningen kommer sedan att brytas ner, detaljeras, utvecklas och beskrivas både funktionellt (Product Functional Requirements) och med avseende på kvaliteter som själva produkten måste ha och de kvalitetsegenskaper som funktionerna måste uppvisa (Product Quality Requirements).


Produktkraven (både de funktionella och kvalitetsattributen) representeras utifrån produktens perspektiv och ett språk som reflekterar den lösningsdomän vi valt att gå vidare med. 
Produktkraven beskriver designen på den aktuella lösningen på en nivå som gör det möjligt att realisera den i ett automatiskt system med en specifik konfiguration, ofta redan beslutad via existerande begränsningar på hela den ursprungliga lösningsmängden.

Det är här den stora risken gömmer sig. Det är så ”enkelt” att tänka på produktkraven som ”de riktiga kraven” och att fokusera enbart på utvecklingen av produkten utan att relatera till verksamhetens verkliga behov. Utan en kontinuerlig återkoppling (VALIDERING), att vi verkligen utvecklar rätt produkt för kundens specifika behov, önskemål och förväntningar, så kommer produktens kravmängd att glida. Ofrånkomligt ont och pinsamt fel.
Så skilj på verksamhetskrav och produktkrav och se till att de hela tiden hänger ihop.



*) Däremot så funkar Rapid Prototyping ofta ganska bra eftersom det är lättare att peka på vad man INTE vill ha än att fundera på VAD man egentligen behöver. Risken är givetvis att man i stunden lockas till onödiga features som man kan få på köpet och som känns spännande i stunden när de presenteras, men som ibland inte har någon egentligen koppling till verksamhetens verkliga behov.

Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.