Nyårslöften…

Ett nytt år ligger nästan orört framför oss. Kanske är det lite ute att ge nyårslöften, men någonstans under ytan brukar man ändå uttala lite förhoppningar om det nya året. Vi som arbetar med kravhantering grunnar säkert på hur vi ska kunna bli bättre på att lägga grunden för framgångsrika projekt och ta fram rätt produkter. Inventerar jag mitt 2015 hittar jag ett par riktigt grundläggande ”low hanging fruits” att polera lite på, som kanske du också känner igen…

2016 tänker jag nämligen bli ännu bättre på … att dokumentera motivering och källa till ett krav.

I större utvecklingsprojekt går det inte att komma ifrån att du förr eller senare inte kommer ihåg varför kravet kom till eller varför det formulerades som det gjorde. Inte sällan är det du som kravanalytiker som får frågan varför kravet ser ut som det gör, down the road, några månader senare. Har du då inte dokumenterat enligt konstens regler står du där med skägget i brevlådan och får påbörja ett mödosamt efterforskningsarbete. Kanske tvingas du till omformulering men sitter kvar med en gnagande känsla att det var något viktigt som gjorde att vi landade i den ursprungliga formuleringen.

Jag tror de flesta lätt håller med om nyttan att dokumentera motiv och källa till krav, och oftast också gör det i sitt dagliga arbete. Men det är lätt att skjuta upp detta eller beskriva alltför summariskt för att man ska förstå senare. Kravet kanske känns så självklart att motivet och källan känns oviktig att uttrycka ordentligt i stunden. Eller så tror man att man inte glömmer varifrån kravet kommer och tänker återkomma senare och lägga till motiv och källa. Man vill vara effektiv och snabbt gå vidare till nästa krav istället för att lägga ned dyrbar projekttid på att dokumentera helt färdigt. En annan vanlig anledning är säkert att mötesanteckningarna från den långa workshopen är lite för diffusa (särskilt från andra halvan av mötet…) för att kunna uttyda varifrån tanken kom eller så har det gått för lång tid mellan mötesanteckningar och vidareförädling till krav.

Men lockelsen att av en eller annan anledning hasta över motiv och källa straffar sig. Den tid du sparade förloras snabbt när kedjan användare/behov/krav måste tas upp igen, den lindring du kände i stunden ger frustration längre fram.

En bra motivering till ett krav ger däremot en mängd mervärden redan från start. Det ger en stadga och stabilitet åt kravspecifikation. Genom att tydligt motivera ett krav gör man samtidigt behovet tydligt för läsaren. Stake-holders, utvecklare, testare – you name it – förstår kravet bättre och behöver ställa färre frågor. Onödiga diskussioner undviks och tid sparas.  Men framförallt undviker man en del onödiga omtag, när hälften av gänget glömt varför kravet formulerades som det en gång gjorde.

Källan till kravet är också guld värd i ett projekt den dag kravet blir ifrågasatt eller behöver ändras. Källan till kravet har förmodligen kunskap eller behov som är essentiellt för kravet och kan därför vara viktig att inkludera vid en diskussion om kravändring. Man ska inte heller underskatta att en vettig källhänvisning kan bidra till att legitimera kravet, det blir en slags garant för att kravet inte är taget ur luften utan äger sin giltighet. Kravet kan ”låna” lite av den auktoritet som källan besitter.

Nyttan av motivering och källa tenderar också att bli större ju längre tiden går efter att kravet formulerades – minnet är kort, och bemanning av projekten ständigt skiftande. Kommande produkter baseras gärna på tidigare produkter, krav ärvs vidare. Tappar man motiv och källa riskerar man antingen att rensa bort krav som faktiskt behövs genom att man inte förstår bättre, eller ha onödiga krav kvar som inte bidrar till något annat än onödigt arbete.

Så 2016 får mitt löfte bli att se till att motiv och källa kommer med ordentligt, varje gång. Vilket blir ditt löfte?

Johan Eckerdal, Require AB

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *

Följande HTML-taggar och attribut är tillåtna: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>