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).

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

Varför då då?

Har du barn? Eller har du varit ett barn? Eller du kanske fortfarande är ett barn?

Någon av dessa frågor bör du ha svarat ”ja” på och då har du kvalificerat dig för att läsa vidare i texten nedanför. Om du svarade ”ja” på alla tre frågorna, så har du allra störst förutsättningar för att snart kunna glänsa på jobbet nästa du gång du ställs inför ett knivigt problem.

Fortsätt läsa Varför då då?

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.

Fortsätt läsa Att skapa samsyn med hjälp av processer

Dags att överge begreppet ”överlämning” i kravarbetet!

Arbetet med att ta fram en lösning på ett behov eller problem involverar ofta många personer, alla med olika ansvarsområden, kompetenser och uppgifter. I en processorienterad verksamhet samverkar dessa för att uppnå ett resultat, där var och en bidrar med sin del utifrån hur behov, krav och lösning ser ut.

Likväl talar vi ofta när det kommer till krav om överlämning av dessa mellan olika roller i initiativet. Detta är något som skapar ett problem eftersom det i begreppet överlämning lätt tolkas, medvetet eller omedvetet, som att man överlåter ansvaret för dessa till någon annan. Risken blir att man som kravansvarig tar ett steg tillbaka och väntar på att en lösning skall presenteras eller få ett kvitto på att beställaren är nöjd. Inget kan vara mer fel! Fortsätt läsa Dags att överge begreppet ”överlämning” i kravarbetet!

Att vara iterativ utan att vara agil

Det finns inget ord som både brukas och missbrukas så mycket i vår bransch just nu som ordet Agile. Alla ska vara agila. Vad det innebär exakt är inte så viktigt, bara vi blir agila. Det är det senaste, det bästa och det löser alla våra problem. Att många företag har svårt med en agil transformation är ett faktum och det kanske inte är så konstigt när man inte tar sig tiden att förstå vad en sådan faktiskt innebär. Man blir inte agil över en natt.

Fortsätt läsa Att vara iterativ utan att vara agil

Var går gränsen mellan process och produkt?

Sketches

Jag börjar med att sticka ut hakan genom att generalisera rörande hur man är organiserad på större företag:

  • Den verkliga beställarsidan på företag är processorienterade, detta medför i det flesta fall att deras IT-stöd består av fler än ett verktyg.
  • Många gånger är IT-sidan på företag orienterade efter verktyg, åtminstone när det kommer till verklig implementering och exekvering.

Moderna utvecklingsmetoder förespråkar att man som beställare ska jobba nära implementationsteamet. Detta betyder, tillsammans med ovanstående generalisering, att en beställare kan ha fler än en motpart när det kommer till att realisera sina behov.

De senaste åren har jag jobbat både som kravställare och som kravhanterare. Jag har därmed erfarenhet av både egen och andras frustration kring när produkt/projekt krockar med process.

Fortsätt läsa Var går gränsen mellan process och produkt?

Gästinlägg: The user story considered harmful

Då drar vi igång Kravbloggen igen efter semestern och vi börjar med ett gästinlägg av inga mindre än Suzanne och James Robertson. Suzanne kommer till Stockholm och håller kurs den 27-29 september. Se mer här

The User story considered harmful

Agile techniques have brought us many advantages and good ideas – unfortunately, the user story is not one of them.

The user story is a “placeholder for a conversation”, or a “placeholder for requirements”, either definition is acceptable. However, if the story is a placeholder, then it must hold the right place, and must guide the conversation in the right direction. Many stories don’t.

What’s wrong with the user story?

The most fundamental problem facing software development today is that the single greatest cause of project failure is a failure of requirements. This “failure of requirements” covers the full gamut: failure to discover the needed functionality; failure to understand the nuances of the needed usability; failure to adequately convey the requirements to the developers; and frequently, failure to uncover the real problem to be solved. Sadly, the user story often directly contributes to the requirements problem.

So why are user stories poor in the requirements arena?

Fortsätt läsa Gästinlägg: The user story considered harmful

Dags att reflektera!

reflektera2

Ofta när man diskuterar kommunikation så handlar det om hur man ska förmedla något som ”avsändare” av information. Men eftersom kommunikation oftast handlar om en dialog så behöver vi erkänna att vi har två sändare och två mottagare. Det kan var en obalans av aktivitet mellan parterna men det är en dialog även om den ena pratar och den andra bara hummar jakande.

Det finns en term som jag tycker man kan använda sig av för att beskriva detta ”feedbackande” och det är att reflektera. Normal pratar man om att man reflekterar och summerar i samtal, men det är ett koncept som kan användas i mycket mer än samtal. Det belyser en otroligt viktig egenskap i kedjan att realisera ett krav. Det är inte en envägskommunikation som möjliggör att man träffar rätt – att behovet som kommunicerats initialt, faktiskt resulterar i just den ”feature” som faktiskt efterfrågades. Det kräver att man kontinuerligt återkopplar och säkerställer att det man hört faktiskt överensstämmer med det som var tanken hos avsändaren. Vi kan minimera risker genom att minska antalet led och överlämningar, men så länge inte idén föds och implementeras av samma person så behövs feedbackloopen (= reflektion). Det handlar ju inte bara om att bara putta information nedströms. Både avsändare och mottagare vill ha kvitto på förståelse, då information filtreras efter mottagarens hjärna och inte sändarens. Fortsätt läsa Dags att reflektera!

Att involvera användaren

Låt mig presentera ett dilemma som jag då och då brottats med och även hört kollegor/vänner i branschen prata om. Ett dilemma som består av följande komponenter:

  • Ett projekt vars huvudsyfte är att ersätta befintlig lösning med en ny. Samma funktionalitet men baserat på ny, modern hårdvara och utvecklat i ett nytt och modernt programmeringsspråk.
  • En beställare och styrgrupp som med ett tydligt statement sagt att eftersom det är samma funktionalitet, så behöver vi inte kommunicera i onödan med slutanvändarna. Ingen idé att röra upp damm och skapa oro.

Någon som känner igen sig? Någon som anar i vilken riktning detta blogginlägg är på väg åt?

Fortsätt läsa Att involvera användaren

Hur få kvalitet i kravgranskning?

Jag tror att alla är överens om att det är viktigt att kvalitetssäkra kravspecifikationer. En felaktig eller inkomplett kravspecifikation kan få katastrofala följder. Som kravansvarig har man gjort sin kravplan och punkten ”kravgranskning” låter ju tämligen enkel att genomföra. Men är det så i verkligheten? I många fall inte tyvärr. Fortsätt läsa Hur få kvalitet i kravgranskning?