Det går att återvinna information genom produktens/tjänstens livscykel. Ändå lägger jag märke till att det inte sker i den utsträckning som det borde. Här finns flera vinster att hämta: Lär av varandra och slipp dubbelarbete. Detta kan organisationer vinna på. Och individen.
I kravarbetet använder jag gärna användningsfall, eller user scenarios och use cases som de också kallas. Och jag är långt ifrån ensam. Vi som jobbar i rollen som kravanalytiker (oavsett titeln på rollen) brukar om och om igen upprepa nästan som ett mantra: Börja med att kommunicera den stora bilden av behoven, vad som ska göras och målet med det, därefter detaljera kraven.
Som jag skrev i ett tidigare blogginlägg är den svåra utmaningen för en produktägare (och kravanalytiker) att kommunicera en vision så att alla inblandade får samma bild av behovet och vad som behöver göras:
> Skapa förståelse för helheten först i kravarbetet
OK, låt oss vända lite på resonemanget.
Har du någonsin tänkt tanken att skriva användningsinstruktioner / User Guides innan produkten/tjänsten ens finns på marknaden eller internt inom organisationen? Därför att det är möjligt.
Har du dessutom tänkt tanken att produkten/tjänsten går att testa innan alla kraven är klara? Därför att det också är möjligt, i alla fall hypotetiskt.
Ett sätt att skapa ett bra samarbete över olika discipliner (och kanske även avdelningar inom organisationen) är att involvera personer som jobbar med dokumentation och test på ett tidigt stadium i systemutvecklingsprocessen.
I ett av mina senaste uppdrag så blev jag så glatt överraskad av att flera personer var inne på samma tanke i att just använda användningsfall som bas för testfall. Och detsamma går att tillämpa för användningsinstruktioner.
I en stor organisation är det inte helt enkelt att hitta rätt person att samarbeta med. Börja prata med någon person så får du säkert en hänvisning till en annan person som kan vara rätt pusselbit i det hela.
Om kravanalytiker, testare, utvecklare och tekniska kommunikatörer och kanske fler bokar möte/workshop för att skapa användningsfall, så händer troligen följande:
De involverade får samma bild av vad som behöver göras. Skapar förståelse för användaren, och alla i gruppen lär av varandra.
De involverade samarbetar istället för att skapa enskilt var för sig.
De involverade får nya perspektiv på en situation eller scenario när användaren använder produkten/tjänsten. (Var helst specifik vilken användare det gäller, skriv inte bara ”användaren” eller ”the user”.)
OK, men vad ska det här vara bra för, menar du kanske.
Jo, helt enkelt att människor och människors kompetens är mer än resurser. Det finns en tradition att involvera personer i olika lägen i ett projekt eller faser i en systemutveckling.
Tyvärr är det fortfarande vanligt att dokumentation och test kommer in först på slutet. Men i vår komplexa och föränderliga värld så krävs det så många egenskaper för att lyckas. Och organisationer idag är beroende av att människor känner sammanhang och mening i det de gör.
Tur att det finns så många driftiga människor inom test och dokumentation som ändå förverkligar målet med produkten/tjänsten under ibland ganska dåliga förutsättningar (läs nästan ”trollar med knäna”). Men tänk om de fick bättre förutsättningar?
När jag som kravanalytiker vill involvera människor inom test och dokumentation så möter jag ofta motstånd, tyvärr. ”Det är inte deras jobb / It’s not their job” är en vanlig kommentar.
Mitt råd är: Skapa förståelse för sammanhang utifrån ett användarperspektiv + Återvinn information + Skapa förutsättningar för att också människor ska lyckas i sin roll.
Skapa ett bättre flöde och minska slöseri
Att återvinna informationen är ett sätt att minska slöseriet i form av dubbelarbete och fel. Lean är en japansk ledningsfilosofi som handlar om respekt för människan, ständiga förbättringar och den lärande organisationen. Lean är även ett arbetssätt genom att se över flöden, minska slöseri och fokusera på det som är värdeskapande i verksamheten.
Ett av verktygen i Lean är 5S-metoden som handlar om att skapa och behålla ordning & reda:
1. Seiri = Sortera
2. Seiton = Strukturera
3. Seiso = Städa
4. Seiketsu = Standardisera
5. Shitsuke = Skapa en vana
Därför är det så viktigt att involvera test och dokumentation tidigt i processen för en ny produkt/tjänst.
Författare: Helén Alseby, agil produktägare samt krav- och verksamhetsanalytiker
Tyckte du om denna artikel? Dela gärna! > Läs fler artiklar
Vill du ställa en fråga eller tipsa om något du vill läsa om? > Välkommen att höra av dig