Kravbloggen

Bloggen för alla som är intresserade av kravhantering. Vi tror på kravhantering som förknippas med kreativitet, enkelhet och innovation. Läs gärna mer om våra tankar här!

Missa inte nästa inlägg!

Prenumerera på vårt nyhetsbrev

Ämne: kravinsamling

KRAVINSAMLING, KRAVSPECIFIKATION, REFLEKTIONER

Beskriv dina behov och inte en lösning …. snälla

”Beskriv dina behov och inte en lösning! Det är vi som ska komma på lösningen” är något som man kan höra rätt ofta från en frustrerad kravhanterare eller systemarkitekt.

Det finns nog ett par olika anledningar till att man enkelt hamnar i den situationen när IT och verksamhet diskuterar framtida initiativ. En är att det oftast är enklare att uttrycka sina behov via en lösning eftersom man också har idéer på hur lösningen ska se ut. Att sedan öppna upp för en annan lösning än den man sett framför sig kan både kännas riskfyllt, skrämmande, och framförallt blir ju lösningen då någon annans.  Detta skapar ofta ganska mycket friktion. Att envist basunera ut att man ska hålla sig borta från lösningen är kanske inte de pedagogiska knepet att ta till i dessa lägen och det är heller inte helt rätt (enligt mig).


INTRESSENTER, KRAVINSAMLING, REFLEKTIONER

Experten vs Kravhanteraren

Har ni hört talas om "filterbubblan" när det kommer till sociala medier och sökningar på internet? Kort sammanfattat kan man säga att det som presenteras i form av sökresultat och nyhetsflöde numera alltid har filtrerats och personifierats utefter dina (outtalade) preferenser. På det personliga planet har vi motsvarande mekanismer, där hjärnan kortsluter och försöker hitta enkla sammanhang som styrker redan tillskansad kunskap.

För några år sedan sa en kollega till mig att "en expert som bara förlitar sig på sin expertis, förlorar i det långa loppet mot en novis som drar nytta av sin omgivning".

Jag har burit med mig detta och försökt att omvandla det till ett förhållningssätt rörande både min och andras kunskap - även när man tror att man vet allt så gör man inte det.


INTRESSENTER, KRAVANALYS, KRAVINSAMLING

Lyssna inte på vad användarna säger!

Det går inte att fråga en användare vad hen vill ha när det kommer till IT stöd för verksamhetsprocesser.

Varför inte?

  • Ofta får man inte de stora penseldragen och de mer strategiska perspektiven från en slutanvändare. Det blir lätt att man cementerar dagens sätt att arbeta då man har svårt att lyfta blicken.
  • Det kan lätt bli lite för mycket "läppstift på grisen" alternativt att man suboptimerar outputen utefter specifika behoven. Man tar helt enkelt inte in helheten i beräkningen när man tittar på var man ska lägga sitt krut. Vad är affärsvärdet för att implementera en viss feature kontra en annan?
  • En slutanvändare kan också ha svårt att artikulera vad det är man vill ha. För att ta ett klassiskt T-Ford exempel: Om du hade frågat vad folk ville ha så hade de sagt "snabbare hästar", när deras egentliga behov var snabbare transporter.

Självklart menar jag inte att man ska stänga ute slutanvändaren, men ibland blir jag lite provocerad av bilden att de sitter på hela sanningen. De ska vara med och forma lösningen men på ett balanserat sätt.

Så vilka kompetenser behöver vara med för att vi ska göra rätt saker och få ut rätt output?


KRAVINSAMLING, FRAMGÅNGSFAKTORER, MODERN KRAVHANTERING

Att skapa samsyn med hjälp av processer

Det är alltid en utmaning som kravanalytiker att säkra att man fångar alla aspekter nödvändiga för den lösning som skall tas fram eller att inte förlora momentum i kravarbetet.

Elicitering, eller kravinhämtning som det också heter, handlar just om den del av kravarbetet som syftar till att få fram olika intressenters krav, väga dessa gentemot varandra, för att till sist kunna presentera en sammanhållande kravbild. Den som arbetar med krav har dock många gånger fått erfara att de involverade kan ha skilda uppfattningar kring det område i verksamheten som är föremål för en förändring.

Det är också viktigt att som kravanalytiker hålla engagemanget uppe bland de som deltar i kravarbetet. Haltar de inledande diskussionerna och tiden drar ut utan att man lyckas uppnå något resultat, riskerar man att förlora intresse och fokus bland dem man är beroende av.

Att skapa en samsyn är därför A-O för att få igång arbetet på ett smidigt och smärtfritt sätt. Processer är då ett bra sätt att skapa en gemensam bild av verksamheten utifrån vilken kommande diskussioner kan ta sin utgångspunkt.


INTRESSENTER, KRAVINSAMLING, REFLEKTIONER

Att ställa krav är att bry sig

Under en av våra AWs på Require pratade Tobias Nilsson om möten och problemen med att få folk att gå på dem. Han lekte då med titeln på anförandet "Ingen kommer på mina möten" som med en bokstavsändring blev "Ingen kommer på sina möten".

Inför arbetet med Kravdagen 2017 satt jag och bollade uppslag till tal med en av anförarna och fick följande förslag "Att ställa krav är att bry sig".

Båda dessa uppslag pekar på något man ganska ofta hamnar i som kravhanterare, verksamhetsanalytiker, eller processledare - folk tror att man jobbar efter egen agenda. När man i själva fallet jobbar för någon annan och där denna någon i många fall är den som ska ställa kraven och komma på möten.


KRAVINSAMLING, KRAVSPECIFIKATION, REFLEKTIONER

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.


KRAVINSAMLING, REFLEKTIONER, BUSINESS ANALYSIS

Developers Vs Business Analysts

As Business analysts or analysts working with requirements, we often think that in most organisations and projects, there is a business analyst working between the business and IT to collect the requirements, document them and communicate them to the developers. In ideal world this should be the case but it’s unfortunately not always the case.


KRAVINSAMLING, MÖTEN, WORKSHOPS

"Utreda krav? Jaha, då ska det vara workshops!"

För några år sedan gjorde jag en oväntad upptäckt: Utvecklarna på företaget jag arbetade för var mycket bättre på workshopteknik än projektledarna och kravhanterarna. Detta trots att det var vi som satt i flest workshops. Hur kunde det bli så?


KRAVINSAMLING, REFLEKTIONER, MODERN KRAVHANTERING

Att vara hemmablind

Spotify kommer att få konkurrens av Apple och deras nya musiktjänst Apple Music som har premiär i slutet av juni (under hösten för Android-lurarna). Priset ska enligt uppgift hamna på samma nivå som Spotifys tjänst. Dock ingen gratisvariant utan enbart tre månader gratis try-out, men då med full funktionalitet.

Spotify har ca 20 miljoner betalande kunder. Under de tre sista månaderna år 2014, vilket också är de tre första månaderna i Apples räkenskapsår för 2015, sålde Apple 74,5 miljoner iPhones. 34.000 telefoner i timmen. 34.000 potentiella användare av den nya musiktjänsten. Per timme. Och i höst får alla med Android också möjlighet att testa den nya streamingtjänsten.


VERKTYG, KRAVINSAMLING, REFLEKTIONER

Kan en riskanalys ge bättre krav?

Kravhantering är ju en central och självklar del av all produkt- och tjänsteutveckling. Gedigna analyser av kundbehov och kundbeteenden är a och o för att kunna kravställa och utveckla rätt produkt som fyller ett behov. Det finns många olika verktyg och metoder för att vaska fram kravbilden. Men i det här inlägget tänkte vi specifikt se lite närmare på riskanalysen som ett sätt att säkerställa kravspecificeringen.


KOMMUNIKATION, TIPS OCH TRICKS, INTRESSENTER

4 avslutande frågor att ställa till intressenter

Efter att ha tipsat om inledande och förtydligande frågor att ställa till intressenter så avslutar vi med fyra avslutande frågor att ställa vid intressentintervjuer eller andra insamlings- och analyssituationer.


INTRESSENTER, KRAVANALYS, KRAVINSAMLING

Kravhantering med en negativ approach

Ett stort problem vid kravinsamling är att väldigt många intressenter gärna pratar lösningar istället för att definiera problemen de har.

Ber man en intressent att säga vad de skulle vilja ha får man oftast svar som ”samma fast lite snabbare/lättare/bättre”. De utgår från den produkt de har idag och lägger gärna till lite funktionalitet. Av någon anledning är det väldigt svårt att se vad som bör förbättras när man ställer en positivt formulerad fråga. ”Säg vad som går att göra så säger jag om det är bra” är ganska vanligt att höra, trots att man idag kan lösa i stort sett vilket problem som helst.


TIPS OCH TRICKS, KRAVINSAMLING, KRAVSPECIFIKATION

5 förtydligande frågor att ställa till intressenter

I mitt förra inlägg tog jag upp några frågor som är bra att ställa när man kommer in i ett projekt. I det här inlägget tar jag upp exempel på frågor som man kan ställa för att få ut mer eller ny information från de intressenter man jobbar med. Ofta handlar det om varianter på samma frågor, men det kan ändå vara bra att ha några i bakhuvudet.


TIPS OCH TRICKS, KRAVINSAMLING, FRAMGÅNGSFAKTORER

5 inledande frågor att ställa till intressenter

När man jobbar med att ta fram kraven i ett projekt så försöker man ofta få fram så mycket information som möjligt från intressenterna. Vilka frågor man ska ställa är givetvis beroende på när man kommer in i projektet, vilken roll man har, vem man intervjuar m.m. Några frågor är däremot alltid bra att ställa, för att få ut så mycket relevant information som möjligt om kraven, problemet och lösningen.

I det här inlägget tar jag upp några frågor som är bra att ställa i inledningsfasen när man kommer in och ska jobba med kraven eller verksamhetsanalys i ett projekt.


KRAVINSAMLING, MODERN KRAVHANTERING

Krav och kommunikation

Wikipedias artikel om kommunikation inleds med meningen "Kommunikation är en process för att överföra information från en punkt till en annan". Jag menar att kravhantering kan fylla en liknande funktion, en stor anledning att jobba med kraven i sina projekt eller organisationer är just för att säkerställa överföringen av information.

När människor kommunicerar med varandra så utgör de faktiska orden en del av kommunikationen, kroppsspråk och tonfall påverkar utöver orden*, och det finns en mängd andra faktorer som påverkar (Kravexperten har ett inlägg om muntlig och skriftlig kommunikation).


KRAVINSAMLING, FRAMGÅNGSFAKTORER, MODELLER OCH METODER

Använd modeller!

En sak jag märkt är att många företag vid både kravinsamling och utveckling är alldeles för dåliga på att använda modeller. Istället produceras alldeles för långa kravspecifikationer med mer text än någon skulle vilja läsa och definitivt mer än vad som är lätt att förstå.

Jag tänker inte ens gå in på hur fel jag tycker det är med tusensidiga kravspecifikationer, det är ett helt annat blogginlägg. Däremot vill jag slå ett slag för att använda modeller oftare för att förtydliga krav. Vi människor har ett väldigt högt visuellt lärande och det borde utnyttjas för att lättare komma överens om krav med projektets intressenter.


ANVÄNDBARHET, KRAVINSAMLING, KRAVSPECIFIKATION

Hur många krav är för många?

Många gånger får jag frågan om hur få/många krav man bör ha i sitt projekt. Det är en fråga som är väldigt svår att svara på. Alternativt blir svaret något så luddigt som ”precis lagom många”. Jag är dock av den bestämda åsikten att alldeles för många projekt specificerar på en alltför detaljerad nivå. Det går inte att styra efter hur mycket som helst. För många krav gör att det blir omöjligt att vara effektiv. Konsten är att kunna skapa en modell av vad som ska utvecklas med precis sån detaljnivå att alla förstår. Det får varken bli så mycket att alla drunknar i krav i onödan och det får inte bli en så förenklad bild att den inte är användbar.


KRAVINSAMLING, SKRIVET OM KRAV, MODERN KRAVHANTERING

Hypoteser istället för kravinsamling?

I den här artikeln beskriver författaren en alternativ metod till "traditionell" kravinsamling. "Traditionell" kravinsamling hänvisar här till en kort, fristående aktivitet i början av ett projekt som resulterar i en dåligt underbygg kravspec som sedan inte ändras eller knappt används i projektet. Jag håller med om att en sådan kravinsamling är helt fel och i princip håller jag med om författarens alternativa metodbeskrivning.

Däremot är det som vanligt i de allra flesta IT-projekt enbart fokus på funktioner, eller egentligen inte ens funktioner. Det exempel som beskrivs är ju en direkt lösning på ett problem. Författarens metod löser detta delvis genom att beskriva ett sätt att effektivt och iterativt testa att den lösning man håller på att ta fram genererar värde för intressenterna.