Det är skillnad på krav och behov

På Agile Swedens mejllista har det pågått en liten diskussion om ordet “krav”. Är det något vi vill använda? Om inte, vad kan vi ersätta det med? Ordet “behov”? Här är min syn på saken.

Idé: Ersätta “krav” med “behov”

Ordet “krav” har sina rötter i upphandling efter fix kravspecifikation och är alltså ett ord som vi snabbt förknippar med systemutveckling enligt vattenfallsmodellen. Eftersom vi vet att namn på saker och ting är oerhört viktiga och detta ord är behäftat med ett ansenligt och missledande arv kan det vara värt att undersöka alternativa sätt att formulera sig.

Det jag personligen har landat i, vilket även diskussionen på mejllistan landade i, var ordet “behov”. Det vi egentligen försöker göra är att uppfylla ett behov. Behov sätter associationen klockrent till användarna av systemet och därmed nyttan eller värdet med en eventuell lösning för att uppfylla behovet. Behov lider inte heller av det obehagliga arv som “krav” gör. Därför bör “behov” ersätta “krav” i agila sammanhang.

Varför “behov” inte (alltid) fungerar

Problemet är att det inte riktigt fungerar. Om man konsekvent försöker ersätta “krav” med “behov” är det något som inte riktigt känns rätt i magen. Lyssna på följande meningar. Låter de bra?

  • Detaljeringen av behov sker parallellt med utvecklingen. (Njae, vi detaljerar väl inte precis behoven…)
  • Vad har du, kära produktägare, för behov angående funktion X? (Eh, vi vill nog veta mer detaljer om behovet.)
  • Acceptanstesterna verifierar att kundens behov är uppfyllda. (Gör de verkligen det?)

Problemet som uppstår, i alla fall för mig, är att behov och krav redan har tydliga betydelser som visserligen är överlappande, men inte synonyma. Jag hade en givande konversation med Sara Manding om detta och vi kunde snabbt identifiera tre tydliga skillnader mellan behov och krav:

  1. Behov är ofta specifika för en användarroll medan krav vanligen inte är det. Meningen “Journalister kan hitta telefonnummer till anställda” uttrycker ett behov hos en av våra användarroller medan “Det ska gå att söka telefonnummer till anställda” inte gör det.
  2. Krav implicerar ofta en tänkt lösning. Meningen “Journalister kan hitta telefonnummer till anställda” är helt lösningsneutralt medan “Det ska gå att söka telefonnummer till anställda” implicerar att vi ska utveckla någon slags sökbaserat lösning.
  3. Behov kan finnas på en marknad eller hos en användargrupp utan att vi känner till dem. Marknaden kanske inte själv kände till den. Tror någon på allvar att iPhone utvecklades genom att några användare sa att “de kände ett starkt behov av en ny typ av digital manick med en massa grymma appar men som också gick att ringa med och med innovativa designlösningar i användargränssnittet”? Likväl känner folk ett starkt behov av att vilja äga en. Krav innebär oftast att vi redan tror oss ha identifierat något som beskriver hur vi vill utforma vår lösning.

Ett reviderat förslag

Mitt (reviderade) förslag för hur vi kan säga:

  1. Använd ordet “behov” för arbete som bereder iterationsplanering och för det som ligger i en produktrestlista (“product backlog”). Då är det verkligen behov vi arbetar med. Dels när vi med användarworkshops, intervjuer, enkäter, användbarhetstester och annat försöker identifiera och formulera behov hos våra målgrupper. Dels när vi masserar och prioriterar bland dessa behov som kandidater för vilka vi ska utveckla lösningar i kommande iteration.
  2. För arbetet som pågår i iterationen och som utgår från behoven skulle jag föreslå “acceptanskriteria”. Det är ju det vi kallar de punkter som våra produktägare ska uttrycka för att vi ska veta att vi är klara med en story. Det är de punkter som vi skriver specificerande tester (exempel) för. Det är de som är startpunkten för TDD/BDD.

Till skillnad från “behov” fungerar detta ord utmärkt i våra tidigare meningar:

  • Detaljeringen av acceptanskriteria sker parallellt med utvecklingen.
  • Vad har du, kära produktägare, för acceptanskriteria angående funktion X?
  • Acceptanstesterna verifierar att kundens acceptanskriteria är uppfyllda.

Ett alternativ till “acceptanskriteria” som jag vill ta upp, är “mål”, som Joakim Ohlrogge föreslog på mejllistan. Mål ska ju vara specifika, mätbara och realistiska precis som acceptanskriteria. Det har också fördelen av att det är enklare. Möjligen låter det lite för generellt för våra syften.

En nygammal användning av “krav”

Men “krav” då? Är det ett meningslöst ord som bör relegeras till det förflutna. Det tycker jag inte. Jag föreslår i stället att vi låter ordets betydelse återgå till den ursprungliga, den som vi alltid har menat tidigare: Något som måste vara oåterkallerligt uppfyllt. Det finns alltså behov som är krav (men inte så många som vi tror). Krav är behov som måste vara uppfyllda för att vårt system ska ha en mening. Dessa behov delas ofta bland alla användarroller. I en digital telefonbok är det ett behov och ett krav att kunna hitta telefonnummer. Systemet saknar mening annars. Att även kunna hitta information om e-postadress är troligen ett behov men säkert inget krav.

Det här kanske låter självklart, men jag tror att vi är förvirrade angående krav. Och jag tror att det är vår envisa strävan att kalla allt i en kravspecifikation för “krav” som gör oss förvirrade. Att ha ord som “bör-krav” är en självmotsägelse. Det kanske inte är så konstigt att vi blir förvirrade.

8 thoughts on “Det är skillnad på krav och behov

  1. Bra skrivet! Jag tycker att det är viktigt att man hittar en vokabulär som påminner om att det är ett samarbete som äger rum. “Behov” gillar jag men, kanske skulle jag därför föredra “förväntningar” istället för “acceptanskriteria”. Acceptanskriteria låter som att de syftar till att godkänna eller avvisa en leverans. Jag tror att en leverans alltid är av godo (eftersom den möjliggör återkoppling) och bör därför aldrig avvisas. Däremot kanske den inte lever upp till ställda förväntningar.

  2. Tänkvärt! Jag tycker ordet “behov” skiljer sig från “krav” och “mål” främst genom att “behov” är något svårgripbart som finns ute i verkligheten, medans “krav” och “mål” är försök att konkretisera och formalisera behoven.

    Jag håller med Måns om att “förväntningar” låter bättre än “acceptanskriteria”. Också för att “förväntningar”, “krav” och “mål” kan finnas på flera nivåer, medans “acceptanskriteria” känns som att det mest handlar om detaljer (även om det kanske inte borde göra det).

  3. Jag tror inte att det är en bra idé att bara ersätta ordet krav med behov. Vi måste prata som om vi verkligen menar behov:

    Kanske förska med:
    – Hur tifredställer vi behovet Y?
    – Vi utvecklar funktion X
    – Kan du kära produktägare förklara lite mer om funktion X så att den på bästa sätt uppfyller behovet Y?
    – Är det verkligen en aspekt funktion X måste ta hänsyn till för att leva tillfredställa behovet Y? Håller vi på att identifiera ett nytt behov, hur viktigt är behovet Z i förhållande till de behov vi redan identifierat?

    Acceptanstester är intressant. Om man tittar på den första av de tolv principerna i manifestot:

    “Our highest priority is to satisfy the customer
    through early and continuous delivery
    of valuable software.”

    Jag gillar ordet satisfy – tilfredställa. Det vore trevligt att kunna mäta tillfredställdhet med tillfredställdhetstester. Men det involverar ju lite en åsikt från den vi önskar tillfredställa och det visar väl lite på begränsningen med automatiska acceptanstester. Jag har haft ett litet problem med termen acceptanstest av den anledningen att det låter lite som ett automatiskt kontrakt “vi har green bar så när är det som vi sa”.
    Förväntningar kanske är bättre, då kan vi prata om uppfyllnadsgraden av våra uttalade förväntningar (de som inte testas är outtalade förväntningar).

    Vad gäller iPhone så tror jag att många har känt ett starkt behov av att släpa på färre prylar. Hur tillfredställer apple det? Jo man stoppar in en mobiltelefon i iphone touch som man ändå släpar på.

    Jag ser inget problem med att behov kan vara fåfänga. Vi kan behöva hårstylingprodukter för att känna oss bekväma att vistas bland folk. Vi kan behöva en stor TV för att vi värderar den tid vi har framför TV:n (eller för att det är svårt att läsa texten och man av möbleringtekniska skäl inte kan flytta den närmare). Vi kan behöva en mp3-spelare för att vi gillar att lyssna på mysik och cd-spelare funkar dåligt på joggingturen.

    Jag tycker också att det finns krav, allt är inte behov. För att få sälja läkemedel i USA finns det FDA-krav på GxP, läkemedlen funkar lika bra utan GxP, kraven kommer från ett upplevt behov av att kunna spåra fel i kedjan och GxP blir en implementation av den spårningen. Som någon sa så kommer krav utifrån. Krav borde vara sådant som vi inte kan påverka?

    Tack för ett tänkvärt inlägg i en tänkvärd debatt!

  4. Nej, ord kan inte bara översättas rakt av, som krav -> behov. De har olika semantik och är inte direkt utbytbare. Krav är något man ställer, behov är något man upplever. Så det är naturligt att uttrycka sig lite olika i olika sammanhang, som du föreslår.

    Om “product backlog” t.ex. är en behovslista håller jag också med om att “sprint backlog” mer är en mycket mer konkret och beslutad målförteckning. Och varje enskilt mål kan vara nått eller inte. Om kriteriet för det heter “Done”, acceptanskriterium, testuppfyllelse eller något annat tror jag går till sig, bara man slutar kalla allt onyanserat för krav.

  5. “Förväntningar”, “mål”, “tillfredsställelse”, många bra ord. Tack för era inlägg! Jag tycker att alla dessa ord är bra.

    Ibland har man produktledare som inte förstår hur man arbetar med åtaganden, som alltid vill ha mer. I det läget tror jag att acceptanstester kan vara bra. Det tvingar dem att acceptera (del)leveransen efter en iteration om kriterierna är uppfyllda. Vi vill ju att teamen ska lyckas med sina åtaganden och inte vara helt i händerna på kunderna slumpmässiga humör.

    I mer mogna team kanske “mål” eller “förväntningar” eller “nöjdhetskriteria” fungerar bättre. Det tar bort känslan av leverans.

  6. Nisse behöver någonting (av vilken anledning som helst, Nisse vet ju det).
    Nisse kräver att mamma skaffar det åt honom.

    Så blir ett behov till ett krav.

    Jag anser att krav är ett rimligt ord att använda i sammanhanget du beskriver här, trots att det kanske har en negativ klang.

    Konceptet bakom ordet innehåller ett visst värde som överfördes till just “krav” genom dettas upprepande användning.

    Det går kanske att en del människor sätter sig och bestämmer att från och med idag säger vi “behov” istället för “krav”, för att “behov” föreställer konceptet bakom det på ett bättre sätt än “krav”, men det är svårt, och kanske helt onödigt.

    Om vi ändå gör så, förblir konceptet oförändrat, trots omdöpandet, och det är kanske det som var problematiskt från början, inte just ordet “krav”.

  7. Många bra synpunkter och idéer. Själv har jag länge försökt använda “behov” hellre än krav, men som du Jocke antyder insett att det inte fungerar i alla sammanhang.

    Jag tror att en sammanfattning, som också stämmer med min uppfattning, vore att inget av orden kan täcka alla användningar. Det finns behov som vi kan tillfredsställa genom att utveckla funktionalitet i ett system, det finns behov som vi bara kan ana och där acceptanstesterna är enda sättet att förstå om vi närmar oss en tillfredsställande av det. Och det finns krav.

    Om vi skall finna ett ord för alla dessa chatteringar kan vi inte använda ett ord som vi alla har tydliga (eller otydliga) semantiska tolkningar av.

    Vi måste då ha ett “nytt” ord, och tills någon “uppfinner” detta ord kommer jag nog att fortsätta använda “behov” för det mesta, men blanda upp det med t.ex “krav” när jag tror att det belyser karaktären bäst.

  8. Kan det vara såhär: om man frekvent tycker att ordet “krav” passar bättre än ordet “behov” i de meningar man använder då man kommunicerar runt uppgiften så kan det vara värt att reflektera över varför det är så.

    Precis som det inte hjälper att kalla sina krav för userstories, döpa om sina inkrement till sprintar och kalla sina statusrapporteringsmöten för daily scrum så kommer det inte hjälpa att döpa om sina krav till behov. Man måste ändra sin kultur så att man kommunicerar sina behov oftare än man ställer krav.

    Ordet krav är bara symptom på ett djupare problem med hur vi utvecklar mjukvara i allmänhet. Jag tror att det är mycket vunnet med att kommunicera på ett sådant sätt att ordet behov oftast känns naturligare att använda än ordet krav.

Comments are closed.