Måste vi BÖRJA med VARFÖR?

Tobbe: Jag vill ha en syltbulle!

Robban: Va?

Tobbe: Jag vill ha en SYLTbulle!

Robban: Är du hungrig??

Tobbe: Mmmm… kan inte du SNÄLLA gå och köpa en på Fabrique? Jag swishar!

Fortsätt läsa Måste vi BÖRJA med VARFÖR?

Vad kan vi lära oss från matlagning?

Vad kan vi lära oss från matlagning? Precis som vid kravhantering och programutveckling kan man tillämpa olika tekniker och ”best practices”.

Fortsätt läsa Vad kan vi lära oss från matlagning?

Nudging

Nudging är ju hett i dessa Nobel-dagar. Börjar man läsa om det yttrar det sig i många olika former och situationer. Nudging är en gren inom beteendeekonomi som handlar om hur man kan påverka människors beteende genom att arrangera en valsituation. Och vi som är verksamhets- och  kravanalytiker är inte undantagna enligt mig.

Sällan är vår enda uppgift att bara dokumenterar ner vad andra tycker och tänker. Ofta handlar det också att på ett pedagogiskt sätt presentera argument till olika beslut; det kan vara allt från ett business case, en plan, alternativa lösningsförslag, mockuper, etc.

Oavsett så finns det definitivt en dos av nudging. För beroende på hur vi presenterar det vi vill få fram så kommer mottagaren skapa sig en uppfattning baserat på just formatet och dispositionen. Det är viktigt för oss att vara medvetna om detta beteende då vår roll ibland ska vara neutral och ibland vill vi rikta vårt budskap i en given riktning.

Fortsätt läsa Nudging

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

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.
Fortsätt läsa Experten vs Kravhanteraren

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?
Fortsätt läsa Lyssna inte på vad användarna säger!

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.

Fortsätt läsa Att ställa krav är att bry sig

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?

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!