För inte så länge sedan hade jag en intressant diskussion där vi pratade krav. Kraven, kan man ofta använda som ett mått på vilken verksamhet som bedrivs hos ett företag. Väldigt strukturerat, ja då är det ofta ett företag som har funnits länge och hunnit sätta sin process, knappt inga krav, ja då är det ofta ett mer nystartat som tror att det inte krävs ordnade krav för att klara sig.
Men, oavsett vilket, och oavsett formen så är det ofta ingen större upphetsande läsning att läsa krav för mjukvara. Dyra verktyg såsom Doors, ReqPro mfl erbjuder ganska basala funktioner att sprida information. Text, med formatteringsmöjligheter och viss användning av bilder är det som erbjuds.
Tänk istället om vi utgick ifrån behoven, så att krav som är så svårt att få till på ett bra sätt använde fler dimensioner för att kommunicera. Varför finns det inga verktyg som har stöd för mindmaps, tal, video, skisser, 3d-modeller och flowcharts för att ta några exempel?
Varför har inte fler verktyg som har stöd för chat och diskussionsmöjligheter?
Några säger, vissa verktyg har ju möjlighet att lägga till t.ex. flowcharts m.m. Men det finns inget vad jag känner till som ens i närheten av det som ligger på min önskelista. Istället försöker man föra över en ide, tanke via ord mestadels. Ett mycket svårt konststycke som mer eller mindre alltid misslyckas. Speciellt när det gäller personer som inte finns i den organisation som kravet är skrivit i. Eftersom det är en viss del av kultur som finns inskrivit i textmassan och därmed inte.
När det sedan gäller att få processen att fungera, även med de dyra verktyg som återfinns, så verkar det minst sagt vara ett svår process. I vissa fall har jag hört företag som har köpt t.e.x. Doors, försökt ett par år och gett upp medans i andra fall har man lyckats, men till en mycket större kostnad i resurser, tid och ångest än planerat.
Så, det är dags att vi börjar kräva en helt ny typ av kravverktyg som verkligen hjälper oss att utveckla projekt med rätt kvalitet, funktionalitet och tid.
Jag håller helt med. Det finns en aspekt till som jag är lite förundrad över. Med tanke på hur centralt krav är i ett projekt så är det konstigt att tröskeln för att ta till sig dessa är så hög. Behöver kravverktygen verkligen vara så komplexa att man behöver en eller ett par veckors utbildning för att kunna komma åt informationen?
Det är ju precis samma problem som med de flesta testverktyg. Det bygger ju på det förlegade tankesättet att målet med kravhantering eller test är att dokumentera så mycket som möjligt på ett så standardiserat sätt som möjligt så att man kan göra helt missvisande mätningar på ett standardiserat sätt. Antal testfall som är klara, misslyckade etc och om kraven är täckta eller ej. Jag har försökt, många gånger, att försöka få med allt i verktygen och det slutar alltid med att vi skapar tabeller för regelverken, flödes eller tillståndsgrafer för att beskriva systemkartan, enradingar för att beskriva demoidéer för user stories. Det intressanta är att vi då samtidigt dokumenterar och analyserar kraven och reder ut mängder av oklarheter! Så enligt mig är ofta testmodeller = krav och dessutom väldigt bra sätt att beskriva dem på. Ofta kan man både planera utvecklingen och testa utifrån modellerna. Steget till att skriva ner krav eller testfall i ett verktyg är ett onödigt extra arbete som dessutom gör att man tappar överblicken. Om vi använder kravverktygen/testverktygen så är det som hållare till andra dokument för att administrera för det är ju ADMINISTRATIVA verktyg vi pratar om – sällan något mer.
Bra tankar!
Visst är det primitivt att reducera ner behov till ord.
Men hur vi än gör, så kommer massvis med saker att missas, och även upptäckas under tiden produkten utvecklas.
Ett problem är att krav ofta ses som ett kontrakt, kontra att se dem som ett hjälpmedel för att ta fram något bra.
Det handlar om att skapa tillräckligt med förståelse för alla parter.
Lite synd att requirements översätts med “krav”, hade det hetat “behov” hade det kanske sett lite bättre ut!