Explore - Represent - Validate

Idag pratar alla om att vara agila. Fräcka nya processer skapas av nya heta gurus. Nya begrepp ersätter allt gammalt. Jag vill påstå att det vi kallar ”agilt idag” i själva verket är essensen av vad varje effektivt projektteam och varje insiktsfull krav-/processingenjör strävat efter (och förhoppningsvis upplevt) inom Unified Processes, iterativ utveckling, Rapid Prototyping och Rapid Application Development, etc.

Vad som är viktigt att inse är att ”snabbhet” inte i sig är essensen i utvecklingen, utan snarare en effekt av ett medvetet tänkande och ett effektivt praktiskt genomförande. Det hjälper inte att vi springer snabbt och hinner med tåget, om tåget går åt fel håll. Agilitet kan aldrig utesluta en medveten upptäcksresa bland intressenter för att förstå kraven och att man tar smarta beslut om hur man representerar, förvaltar, validerar och verifierar dem.

Den mest atomära grundprocessen sker tillsammans med alla involverade intressenter (men oftast inte alla på en gång!) och innehåller ett vetenskapligt förhållningssätt till inhämtning av kunskap och förståelse.

Det kollaborativa upptäckandet är kreativt och spännande (Explore!). Alla upptäckter leder till eftertanke och reflektion och till ett slutligt medvetet beslut om hur man skall representera det man kommit fram till (Represent!) Att dokumentera saker med enbart text är oftast ett dåligt alternativ i dagens komplexa miljöer: bilder, visualiseringar, diagram och modeller TILLSAMMANS med eventuell nödvändig text, är ett mycket smartare sätt att representera kunskap på. Representationen måste valideras med relevanta intressenter (Validate!) har vi förstått saken rätt så att vi senare ”bygger rätt grej”? Valideringsaktiveteten av en medveten representation, är i sig ett effektivt sätt för att fördjupa själva upptäckandet.

ERV är det minsta atomära iterativa aktivitetsflöde som snurrar i varje effektiv agil utvecklingsprocess.

I varje stund och varje situation kan du ha ”Explore – Represent – Validate” som ett mantra i bakhuvudet. Det kommer garanterat förbättra dig i din roll som kravingenjör, och projektet som helhet.

 

Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten. 

Kravingenjörens och kunskapsupptäckarens tre viktigaste hörnpelare

Jack Lange var kultur- och utbildningsminister i Frankrike i flera omgångar från början av 80-talet fram till 2002. På sitt kontor i Paris hade han en specialdesignad fåtölj med en häpnadsväckande imposant front. Den lyxiga framsidan med två tjocka pelarliknande ben kontrasterades av ett avsmalnande bakparti som slutade i ett enda spetsigt konformat ben av kromad metall. Han ville skapa en fysisk metafor för kulturen som vanligen har ett lockande yttre men där den inre strukturen "bakom fasaden" ofta balanserar på enskilda beslut där allt "ställs på sin spets"

Faktum är att tre stödjepunkter ger en naturligt stabil konstruktion.

Tre punkter skapar ett plan i rummet vilket innebär att en yta alltid kan ha kontakt med tre punkter, men inte helt säkert med fyra eller fler! Om inte längderna på ett fyrbent bord är exakt lika långa, så kommer det att växla mellan fyra möjliga 3-punkts-plan, och upplevas som instabilt!

 

Vilka är då kravingenjörens och kunskapsupptäckarens tre viktigaste hörnpelare?

Jag tänker enligt följande:

1.  Vetenskaplighet

Som kravingenjör är du ansvarig för att följa utvecklingen av vad som sker inom den akademiska sfären med avseende på krav. Läsa böcker och papers, följa bloggar, delta på konferenser och frukostmöten, gå på kurser och göra certifieringar. Exempelvis så finns IREB och Certified Professional for Requirements Engineering certifiering (CPRE) till för de som på ett effektivt sätt vill vidga sina vyer. 

Framförallt så gäller det att vara öppen och mottaglig för forskningsresultat. Att ta sig tid att förstå vad som händer utanför den egna arbetsdomänen.

2. Praktisk erfarenhet

Varje dag vi jobbar, varje nytt projekt som vi påbörjar, varje framgång, och framför allt, varje motgång, leder till att vi bygger upp vår användbara kunskap. Den praktiska erfarenheten behöver mogna, struktureras genom eftertanke och belysas av egen återkoppling utan rädsla för att se och lära av både rosad framgång som "misslyckanden" och mindre lyckade resultat. Vi lär oss ofta bäst av våra motgångar och icke-fungerande strategier. 

Man lär sig aldrig att åka skidor utan att ramla, utan att våga vara utanför sin "bekvämlighetszon".

3. Sunt förnuft

Det handlar om dig som person: det du TÄNKTE igår är vad du ÄR idag. Dina egna intressen, din familj, dina relationer och det du lärt dig av dina personliga upplevelser, framgångar, motgångar och konflikter. 

Som kravingenjör har du som uppgift att bygga broar mellan olika intressenter och skingra dimman av olika uppfattningar och behov. Då behöver du skinn på näsan och en livserfarenhet som inte enbart vetenskap eller ett antal år på arbetsgolvet kan ge. 

Sunt förnuft kan knäcka de svåraste nötterna och är en del av lösningen av de "mjuka problemen", som handlar om hur vi fungerar tillsammans, hur vi kommunicerar och är kreativa som en enhet som drar åt samma håll.

I varje situation försöker jag som kravingenjör tänka på att hitta en balans mellan triangelns hörn:

Vetenskaplighet - Praktisk Erfarenhet - Sunt Förnuft

Att bara göra det som man brukar göra på det sätt som man alltid gjort, är helt enkelt inte Good Enough. Att även öppna ögonen för nya tankar och att passionerat engagera sig som person är viktiga komponenter för att skapa en grogrund till ständig och nödvändig förbättring och utveckling för både projektet och för dig som kravingenjör!

Ett riktigt stabilt kunskapsbord har tre ben! 

Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten. 

Ser kravmängden ut som en inköpslista?

Även om man är helt säker på att kravet är verifierbart som ett element i ett kontrakt, är det OMÖJLIGT att skriva ett ”korrekt krav” utan att känna till och dokumentera (representera) ett antal grundläggande kravelement som är direkt relaterade till själva kravtexten. Är det möjligt att göra ett bra kravarbete utan vetskap om alla intressenter (stakeholders), deras mål och drivkrafter (goals) i den specifika situationen?

Ett flertal undersökningar visar på återkommande och olösta problem inom kravområdet, som en direkt orsak till ett oacceptabelt antal misslyckade projekt1. Jag tror personligen att en möjlig grundorsak (Root Cause) till denna problematik är att alltför många tror att man kan fånga kravens alla aspekter i en lista av korta, mer eller mindre välformulerade, fraser.

Om vi byter vår interna metafor från ”lista” till ”nätverk”, kommer vi att se ett krav som en del av ett nätverk av sammanlänkade kravelement, som vi måste UPPTÄCKA och REPRESENTERA som en helhet, istället för enkla enskilda fraser. Nedan visas en enkel modell över de mest grundläggande kravelementen i ett sådant nätverk.

Diagramberättelsen (diagram narrative/story) är enligt följande:

Ett krav uppfyller ett MÅL som ägs och definieras av en eller flera (diagrammet visar inte på kardinalitet) intressenter. Kravtexten byggs upp av termer som definieras på ett sätt så att termen används med samma betydelse inom projektet. Krav ordnas utefter hur viktiga de anses vara genom prioritering och varje krav är definierat mätbart och intressenternas förväntan på kravet och vad som ska gälla för att intressenterna ska tycka att kravet är uppfyllt. Varje krav är en del av något möjligt scenario där användare eller aktörer interagerar. Alla krav kan delas in i tre olika typer:

• Begränsningar på den verklighet vi kravställer (Constraints)
• Funktionella krav och kvalitetsattribut på aktuella funktioner
• Komponenter (Kvalitetskrav).

Olika projekt har olika behov av att fokusera på olika delar av modellen. Varje projekt är UNIKT och det finns ingen ”one size fits all”-teknik som passar allt och alla situationer. Försöken att få med ALLT i checklistor och templates gör de flesta till ”template zombies”; vi slutar tänka själva och kan inte se och förstå vad projektet VERKLIGEN behöver. Om en organisation redan har en välkänd och verifierat korrekt intressent-karta, behöver exempelvis inte en djuplodad intressentanalys genomföras.

Ett sätt att kommunicera kring anpassning av kravbehovet för specifika situationer, är att införa begreppet ”kravmognad”. Hur moget är kravet? Är det tillräckligt moget och väldefinierat för det specifika projektet utifrån de ovan angivna aspekterna?

Mer om kravmognad i en kommande bloggpost, men det viktiga är att vi börjar tänka på krav som ett nätverk av sammanlänkad information och att det är den aktuella situationen som avgör vad som är viktigt att upptäcka och representera!

1CHAOS report från the Standish Group är inte tillförlitlig med avseende på exakta siffror, eftersom deras metoder och analyser inte är offentliga, men de (tillsammans med flera andra liknande undersökningar) visar på kontinuerliga problem inom kravområdet som har en direkt eller indirekt påverkan på hur bra projekt utförs och hur nöjda kunderna blev efter leveransen av produkten eller tjänsten.

Om författaren
Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.

Har du plockat några krav idag?

Att arbeta med krav innebär ofta att man brottas med förutfattade meningar och förenklade världsuppfattningar. "Hur svårt kan det va, det är väl bara att skriva ner vad de vill ha"? Har du hört den förut?

Det är få arbetsområden som omger sig med så många felaktiga metaforer och odefinierade begrepp som kravdisciplinen. Bara själva ordet KRAV förekommer i allt från högtflygande visioner ner till begränsningar på detaljerna i realiseringen av en specifik komponent.

Uttrycken "Samla in", "fånga in" eller "skriva ner" krav skapar alla en illusion av att "kraven" lever ett eget liv likt en fjäril, fisk eller som ett bär i skogen, det är bara att samla och fånga, sen är det klart.

Men verkligheten är den att även om du hittar och besöker alla intressenter till det aktuella projektet, så kommer du inte att finna några högar med krav och features redo att tas om hand.

Kravarbete handlar om att UPPTÄCKA och REPRESENTERA verkliga behov, önskemål, idéer och "det man måste göra" tillsammans med intressenterna.

Och när jag säger "upptäcka" så menar jag givetvis inte att vi råkar snubbla över en upptäckt, utan ett vetenskapligt baserat utforskande som leder till tydliga resultat möjliga att validera och verifiera. Allt enligt det vetenskapliga mantrat: definiera och avgränsa ett problem (upptäcka), formulera en teori (representera och validera) och testa att den verkligen funkar (verifiera).

Som kravanalytiker har vi alltså inte bara "tur när vi tänker och skriver" eller att "det blev det det blev", utan vi drivs av vetenskaplighet, praktisk erfarenhet och sunt förnuft.

Frågan är om "kraven" existerar överhuvud taget innan samarbetet mellan de olika intressenterna och den "gemensamma upptäcksresan" påbörjats. Krav kan knappast existera utan ett sammanhang med visioner, mål och beroenden.

Kravarbetet är oftast en del av ett tidsbegränsat projekt vars syfte är att förändra nuläget genom att skapa och tillföra en produkt eller en tjänst. Är då ett påstått behov som saknar förankring till den givna förändringen verkligen ett krav. Om du hittar ett löv på marken, har du då hittat en del av ett träd?

Kravarbete handlar således om att förstå helheten och att tillsammans med intressenter representera, precisera och bryta ner informationen till en hanterbar mängd som ger önskat resultat för förändringen i stort. Det är ett i högsta grad kreativt arbete med hantering av "mjuka frågor" som kommunikation, gruppdynamik och konflikter. Att vara öppen för nya idéer, att behärska ett stort antal olika tekniker för att anpassa sig och använda det som fungerar bäst i den gällande situationen, att veta vad man letar efter och att kunna känna igen vad man hittar och få det att passa in i helheten.

På mitt visitkort påstår jag att krav är en akronym (K.R.A.V.) och brukar fråga mottagaren om de vet vad den står för.

Jag kan avslöja att jag själv tänker mig formuleringen "Kreativa Representationer och Arbete med Visioner".

... och jag skulle aldrig kalla mig för "kravskrivare", lova mig att du inte gör det du heller!

Om författaren
Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.

Effektiv workshop

En workshop är per definition ett fokuserat möte med ett begränsat antal deltagare vilka besitter nyckelkompetens avseende mötets tema. Det finns många metoder för att genomföra effektiva workshops. Gemensamt för dem är man vill uppnå bästa möjliga resultat på kortast möjliga tid. 

Vår metod baseras på Michele Jacksons forskning inom gruppdynamik som identifierar fyra fallgroppar som gör att projekt misslyckas:

• Man förstår inte uppgiften
• Man saknar kompetens för att lösa uppgiften
• Man är inte överens om hur man ska lösa uppgiften
• Det färdiga resultatet motsvarar inte mottagarens förväntningar

För att stimulera kreativiteten så använder vi oss av fördefinierade problemsymptom vilka av deltagarna antingen identifieras som direkt relevanta för projektet, relevanta efter omformulering eller irrelevanta. Symptomen sätts i relation dels till den uppgift projektet ska lösa och dels till projektets position i organisationen.

Därefter grupperas symptomen och det övergripande problemet formuleras för respektive grupp. Relationer mellan problem identifieras och påverkan och påverkare beskrivs. Det innebär att om man känner till ett problems följdproblemen så kan många problem lösas med i ett slag.

Ett ytterligare steg är att bena ut vilka fysiska personer som ansvarar för respektive problem, dvs vem har möjligheten att lösa eller hantera problemet - vem ska man prata med?

En sådan här workshop resulterar och i mängder med intressant data. Datat kan i sig analyseras med statistiska metoder och en specifik problemprofil för just det specifika projektet kan visualiseras och jämföras med andra projekt.

Genomförandet ger ofta upphov till aha-upplevelser och intressanta insikter om sig själva och inte sällan så blir slutresultatet värdefullt men inte helt vad man hade förväntat sig.

Om författaren
Mats Wessberg är VD och medgrundare av Inceptive. Han har verkat i IT-branschen sedan 1995 och mestadels som konsult. Hans huvudsakliga expertis är inom Quality Management och utvecklingsmetodik.