Kravhantering – kontraproduktivt?

Kravhantering, så som den bedrivs i IT-projekt idag, är slöseri med tid och resurser. Med tanke på hur många, särskilt inom användbarhetsområdet, som arbetar med kravhantering är det förstås en provokativ tanke.

Kraven finns där för att det är en stor lucka mellan affärs- och verksamhetskonsulternas abstrakta rapporter och den faktiska systemimplementationen de ibland förordar. Så långt allt väl. Men vad är kraven egentligen bra för? Vad försöker de beskriva?

Jag hävdar bestämt att krav är en artefakt av ett alltför ingenjörsorienterat arbetssätt. Ett arbetssätt där man trots allt uppmärksammat att man på något sätt måste definiera och specificera vad det är som ska göras, visst. Problemet är att så fort kraven är formulerade glömmer man varenda ord om vad, varför och för vem. Du kan ha kartlagt och skrivit personas, definierat scenarios, vad som helst, men när kraven finns där är det dom som styr. Obevekligt. Och i 9 fall av 10 levereras ett system som uppfyller tillräckligt många av kraven för att leveransen ska vara godkänd men som inte går att använda och som inte fyller nån affärsnytta.

Pengar i sjön.

Och det värsta är inte att jag säger dethär utan att det faktiskt händer. Igen och igen och igen. Och beställarna svarar med att försöka bli bättre och bättre på att skriva krav. Blir det det?

Inte så vitt jag vet.

Snarare har kraven förvandlats från generella ”bilen ska vara bränslesnål” till specifika ”bränsleinsprutningen måste vara kalibrerad till 0,00001% marginal”. Kontraproduktivt.

Därför har jag börjat prata om att krav är föråldrat. Vill man verkligen uppnå affärsnytta kartlägger man behov och förväntningar och matchar dem mot verksamhetens strategier och visioner.

Detdär är ju inget nytt för de flesta av oss. Men nästan alla arbetar fortfarande med krav och kravhantering – det är till och med en särskild yrkesroll och i linjeverksamhet har man ofta kravhanterare anställda; först tar man fram behoven, målen och konceptet. Sen simsalabim gör man krav.

Och där någonstans tappar man bort hela nyttan med investeringen.

Som en konsekvens av detta provar jag just nu med att strunta i krav. Det enda (sic!) som behövs är ju egentligen att kartlägga, prioritera och balansera alla intressenters behov och förväntningar, inklusive affärsstrategierna och målen. Sen dokumenterar man det i koncept, design rationale, lösningsarkitektur och interaktionsdesign. Hur exakt man går till väga beror ju på om man implementerar standardsystem, om man gör en app till en padda, eller vad det nu är, men i grunden är det ju inga konstigheter.

Självklart måste man ha koll på informationsarkitektur och verksamhetsregler och en massa andra saker. Men så fort man gör krav av dem blir det de som styr, inte nyttan eller meningen med hela investeringen.

Och hela meningen med det vi gör är ju att det ska bli nytta, nytta och ändamålsenligt!

7 reaktioner på ”Kravhantering – kontraproduktivt?

  1. Mycket bra skrivet! Jobbade i ett tidigare liv med att samla in krav från en utvecklingsorganisation. Att be kravställarna att förklara den verkliga bakgrunden till ett krav (m a o varför) var en omöjlighet. I bästa fall kunde man få ”för att kunden kräver det” eller ”för att konkurrenterna har det”. Men vad är ett ”krav” värt om det inte finns ett verkligt behov som skall tillfredsställas och hur kan man vara säker på att just det ”kravet” är det bästa sättet att lösa det verkliga behovet på om man inte har klart för sig vad det verkliga behovet är!!??

  2. Bra inlägg! Hade inte kunnat skriva det bättre själv – summerar precis min erfarenhet kring kravarbete.

    Det vore intressant att se hur vi kan ersätta krav och dokumentation som kostar mer än vad den används. Jag har länge försökt hitta rätt typ av dokument istället för detaljerade dokument som aldrig stämmer….

  3. Tack. Jag kommer återvända till ämnet för det finns mycket man kan fundera över men som inte fick plats här… Kan inte lova något specifikt datum för det, bara. Håll utkik!

  4. Bra!
    Men vad är krav egentligen? Textuella beskrivningar av en produkts egenskaper? Man skulle ju också kunna se krav som något större, en avgränsad del av hela designen. Som inkluderar bilder, textbeskrivningar, kanske scenarios. Lite som Scrums ”user stories” där man försöker få in användaren och kontexten i kravet. Fast ännu bättre.
    Det är ju lättare för en utvecklare som inte har hela bilden att jobba med en del i taget, på så sätt fyller ändå krav en funktion.

  5. Ja, det här är inte nån helt enkel fråga. Senast igår hamnade jag i ett möte där en av parterna hävdade att kraven behövdes i den form de finns (”H34.4 Det ska gå att arbeta med flera samtidiga uppdrag”) av juridiska skäl, dvs att beställaren ska ha laglig grund att skjuta leverantören om man är missnöjd.

    Och som du skriver – utvecklare vill gärna ha tydliga avgränsade krav, losskopplade från helheten, så att de kan få hanterliga arbetsuppgifter.

    Min personliga erfarenhet är att båda dessa situationer motverkar en god slutleverans. Visst behöver utvecklarna något definierat att lösa MEN då inte som krav utan som scenarios och lösningsbeskrivningar. Och i den juridiska situationen… att skriva in kraven i avtalet anser jag är självmord. Detta eftersom kraven är så långt ifrån nyttan och effekten man kan komma. I avtalet ska man istället skriva in tydliga mätbara mål, mål som mäter om man lyckats eller inte. Exempelvis ”50% av supportsamtalen ska kunna hanteras via den externa webbplatsen”. Då strävar man efter lösningar som möter det målet, och sannolikheten att lyckas ökar astronomiskt.

    Jag kommer med all sannolikhet återkomma till detta!

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s