Produktägarskap handlar om relationer

När man tänker på produktägare och produktägarskap, så hör jag ofta att man tänker på marknads- och trendanalys, arbete med användarbehov och affärsnytta, arbete i utvecklingsteam och kanske acceptanstest. Att strukturera och grooma backlogen, sätta visioner och mål, följa upp och kommunicera dessa med teamen. Skriva user stories och klarkriterier kanske.

I teorin var det nog så Scrum-skaparna tänkte.

Efter att i många år ha arbetat både med och som produktägare så har jag insett att de delarna är bara en mindre del av rollen och uppgiften.

En produktägares viktigaste uppgift är att skapa och underhålla relationer. Relationer med kunder, intressenter, slutanvändare, leverantörer och utvecklingsteam. Om du som produktägare undrar vad du ska prioritera idag, så ställ frågan – vem är viktigast att jag träffar idag? (alternativt ringer upp eller kontaktar på annat sätt). För att höra hur de mår, hur det går, ge information om läget eller bara småprat.

Den andra viktigaste uppgiften är att kunna berätta en historia. Som produktägare hinner du sällan med att genomföra allt, leverera allt enligt plan eller förväntan. Men om du kan berätta din historia så är det mindre viktigt vad som faktiskt levererats. Mer viktigt är berättelsen om planen framåt, även när den är ytterst oklar, och om läget i teamet, även när det är kaos. En berättelse kan ha många hål, men det är produktägarens vardag. Du kommer inte ha koll på allt, alla siffror, alla detaljer jämnt. Men kan du berätta din historia på ett trovärdigt sätt så sköter du jobbet utmärkt.

Det kan räcka med en snygg powerpoint-presentation som lyfter fram små men ändå viktiga delleveranser så att det ser proffsigt ut. Eller att du använder ett språk som omgivningen gillar. Eller att du bara valt en bild som illustrerar något som är viktigt för mottagaren.

Framgång som produktägare handlar om att gå och ta den där after worken trots att du inte alls har tid eller har en enorm förkylning. Att du går och tränar ihop med någon chef som du kanske inte alls skulle umgås med annars. Att du åker till andra sidan stan för att luncha med den där leverantören då och då.

Detta leder till framgång för produktägare.

Backlog, user stories, produktvision, demos och allt annat metodiskt kan du delegera eller avsätta en dag i veckan för. Trots att det kanske var det du trodde att jobbet skulle handla om.

Stämmer det med dina erfarenheter?

Tips för att närma sig intressenters visioner och mål: Nuläge

Fick en fråga från nybliven produktägare som undrade om bra tips på hur man närmar sig intressenters visioner och mål. Här är några av mina tankar, även om det kan göras på 1000 olika sätt. Hoppas gladeligen på kommentarer och länkar till andra idéer och bra artiklar.

Vision
Kortsiktig eller långsiktig vision?  Beroende på det gör jag lite olika men gemensamt för dem båda är att jag vill bilda mig en konkret uppfattning om NUET först.  Genom att förstå och beskriva hur en produkt, tjänst, feature eller något annat fungerar just nu så uppstår visioner, det är iaf min erfarenhet.

En affärsstrateg föreslog just detta. Lägg 80% av tiden på att förstå nuet, och 20% av tiden på att förstå och beskriva framtiden så är du hemma. Det stämmer med min uppfattning.

Att beskriva nuet

Generellt gillar ju de flesta att visionera, brainstorma, tänka trender och fantastiska framtider. Att lägga tid på att undersöka nuet är inte lika populärt alla gånger. ”Har du verkligen tid med det här” är en vanlig fråga. Genom att timeboxa och återkomma till argumentet ”Om vi inte vet var vi är nånstans på kartan, hur ska vi då veta vilken riktning vi ska ta för att komma fram?”  så brukar jag få/ta mig tiden att beskriva.

Några verktyg och metoder:

1. Observationer

Hitta möjligheter att på plats observera hur dina användare, intressenter, målgrupp använder din produkt/tjänst just nu. Genom t.ex studiebesök eller att bjuda in en grupp som du ber genomföra en del uppgifter och titta på hur de gör. Detta går också virtuellt. Be din kund visa hur det ser ut på hans skärm på distans, att dema hur han jobbar, eller sätt upp user test miljöer genom t.ex http://www.usertesting.com/.  och liknande.

2. Inspelningar

Med hjälp av verktyg som t.ex http://www.clicktale.com/ och http://www.sessioncam.com/
 eller In product analysis kan du följa hur användaren rör sig genom applikationen. Ibland känns det långt borta att få köpa, installera ett sådant verktyg, men genom gratis trials och visa de som har pengarna hur bra det är så brukar acceptansen komma med tiden.

3. Enkäter & intervjuer

Lite annan sorts information får du genom att sätta upp enkäter på din webbplats, eller genom andra forum. Bästa insikten vid enkäter är generellt citaten snarare än vad man kryssat i för alternativ. Citat säger ibland mer än tusen ord om hur de uppfattar och använder din tjänst.  Se till att designa enkäten så att fria kommentarer blir naturligt. Vid intervjuer brukar jag försöka få dem att berätta snarare än beskriva. Berättelser från verkligheten snarare än ”vad tycker du”-frågor.  Nedan beskrivs närmare vad jag menar 🙂

http://incontextdesign.com/articles/dont-ask-your-customer-comic/

4. Sammanfatta genom scenarios

Beskriv det du lärt dig om NUET genom scenarios – visuella eller textuella.  Nedan är ett fiktivt exempel från verkligt projekt som kanske inte säger just dig så mycket, men visar hur ett scenario kan se ut. Hade jag varit designer hade det naturligtvis varit mycket snyggare, men jag har insett att bättre rita fult än inte alls..

Nu-scenario email 

Ett textuellt scenario kryddat med känslor kan se ut så här:

Tack @soapui @readyapi för den emotionella insynen av viss del av målgruppen 🙂

Och så kan man göra långa mer eller mindre dramatiska berättelser som beskriver just din kunds upplevelse.

Det finns massor av exempel om du googlar på ”CX” som är det nya begreppet, eller ”customer scenarios” eller ”customer journey” mm.

Min poäng är att det behöver inte vara så proffsigt, snyggt eller ens strukturerat så länge som du beskriver din förståelse av nuet i form av scenarios med hjälp av bilder eller text, eller både och.

5. Value Prop Canvas

Mycket trevligt verktyg för att beskriva nuet. Genom att förstå och beskriva din produkts Value proposition blir det betydligt lättare att identifera vision. Vad är din produkts kärnvärde? Vad gör att dina kunder köper den och dina användare använder den? Vad är deras Gains och Pains när de använder produkten?  Läs mer och prova själv med dina intressenter.

Det finns ju många fler verktyg, detta var några av mina favoriter.

När du beskrivit nuet kan du fundera på framtiden, visionen. Och det får bli i nästa inlägg..

Produktägaren – domänexpert eller processguru?

Efter ett samtal häromdagen om produktägarrollen på en organisation så började jag fundera igen över detta.
Vad är det för slags produktägare man ska tillsätta, om man nu som beställare, chef, processägare eller något annat vill ha en sådan roll i sin utvecklingsorganisation?

Är det den person som kan bäst om domänen man verkar i – försäkringar, marknadsföring, administration, kundservice etc? (kan ibland vara superanvändare).
Eller är det någon som är proffs på utvecklingsmetoder, systemutveckling, processer, användbarhet etc i allmänhet? Någon som levt och verkat i utvecklingsmiljöer.
Eller är det affärsägaren – den som faktiskt ansvarar för att affären eller verksamhetsnyttan går hem? Ofta en linjechef av något slag.

Jag har sett olika varianter på detta och naturligtvis finns inget rätt svar. Min slutsats är att oavsett vilken av dem man väljer så:

1. kommer den personen behöva ordentilgt avsatt TID – dvs bli av med andra uppgifter.

2. personen kommer behöva lära sig ordentligt något utanför hens normala zon. Är man domänexpert/superanvändare behöver man t.ex lära sig utvecklingsmetodik på riktigt. Är man process-proffs behöver man lära sig domänen och marknad. Är man affärsägare behöver man lära sig UX-metoder etc. Tid behöver ägnas åt detta och ibland investering i utbildning och liknande.

3. personen kommer behöva stöd av någon av de andra rollerna för att lyckas i sin produktägarroll. Processproffset kommer behöva enkel tillgång till superanvändare och domänexperter som kan vara med i designdiskussioner och delta i acceptanstest, dvs kunna ägna tid åt utvecklingen. Affärsägaren kommer behöva ett processproffs som kan fokusera på behov & kravställning, domänexperten kommer behöva en tillgänglig affärsägare för att kunna fatta affärsmässiga beslut etc.

4. personen behöver ett tydligt mandat – mer eller mindre, bara det är tydligt.

För den som sett en produktägarorganisation riggad på detta sätt, har troligen också sett de resultat man vill åstadkomma med agila metoder – dvs bättre time to market & bättre värde till kund

Tyvärr behandlas produktägarrollen i de flesta organisationer slarvigt. Man tillsätter någon som känns rätt, utan att ge den det stöd eller framför allt den TID som krävs för att få full nytta av rollen. Sedan säger man att man jobbar ”agilt” fast utvecklingsteamen och leverantörerna fortfarande inte har någon riktigt närvarande att kommunicera med utan kör sitt race som vanligt. Alternativt en alltför teknisk produktägare som inte uppmuntras till att kunna och faktiskt få ta ett större affärsansvar.

Om den ideale produktägaren, t.ex en affärsägare, helt enkelt inte KAN flyttas från sina ordinarie uppgifter, kanske är det bättre att hon medverkar som aktivt affärsstöd istället till någon annan utsedd produktägare – t.ex en superanvändare eller processexpert?

När jag sett produktägarrollen fungera så har det inte spelat någon roll vilken av ovanstående som varit produktägare, utan skillnaden har bestått i NÄRVARO, TID samt ordentlig backup på det område hen inte är expert i.

I den gamla metoden XP – Extreme Programming, föreslog man ration 1-1 av kodnära utvecklare och andra roller i teamet  t.ex som nedan:

Process-stödet (t.ex en Scrum-master, teamcoach och liknande) finns inte i XP om jag minns rätt, men ofta behövs också en sådan roll något beroende på teamets storlek, uppgift och mognad.

Testaren har jag lagt till som en egen roll, beroende på teamets uppdrag och kvalitetsmognad behövs också en sådan. Testaren har jag också sett vara ett ovärdeligt stöd till produktägaren i fråga om både kravställning, acceptans, användningstest mm.

Detta är motsvarande heltidare. Dvs om man har en UX på 50% så borde också en av kodnära utvecklarna vara på 50%… för att hålla ration. Om du vill ”fördela” testaren eller UX:aren på 2 team på 50% vardera, har du också tänkt fördela en av utvecklarna på två olika team? Det hänger också på reell närvaro (fysiskt eller virtuellt) för att fördelningen ska fungera. Dvs en testare som aldrig är delaktig i utvecklingsteamet på riktigt, gör antagligen inte så stor nytta som hon skulle kunna.

Jag vill helt enkelt slå ett slag för XP igen och att alla som beslutar om produktägarskap tar sig en funderare på vad man vill uppnå. Räcker det med att någon får hatten Produktägare för att öka nytta, kvalitet och time to market?  Eller krävs helt enkelt en ny och mer seriös approach till det utvecklingsarbete som är av mindre teknisk art för att våra nya metoder ska löna sig?

Heja alla produktägare därute som gör sitt bästa för att få någonting gjort på sin lilla tid och kämpar för att hålla takten i analys, kommunikation, visionerande, utredningar, planering och uppföljning av utvecklingsarbete, acceptanstest, marknadsresearch, kundstudier….

Vad är krav?

Häromdagen hörde jag en presentation av en person som jobbar på ett spelföretag. Han sa att de inte arbetar med krav alls. Vad jag hörde var att de inte har den gamla formen av kravanalytiker som sitter och samlar och specificerar allt de kommit fram till, för att sen föda utvecklare med dessa specifikationer. I stället låter de spelutvecklarna testa och experimentera fram olika varianter tills något känns bra. De har också en relativt stor grupp hängivna spelare (användare) som får pröva spelen tills de identifierar vilka som faktiskt är bra och roliga och då eventuellt släpper de spelen. Han sa att endast en bråkdel av spelen faktiskt når ut i produktion.

De arbetar också mycket med test, förutom användningstesten så automatiserar de test av sådant som bara måste fungera gång på gång, typ login och annat. Dessutom har de fasta regler att förhålla sig till, t.ex från API:er (gränssnitt) med tjänster som de använder, t.ex Facebook, Google mfl. Och det är ju bara att följa de gränssnittsspecarna.

I mitt huvud tänkte jag, men! Ni jobbar ju visst med krav! I alla fall enligt min personliga tolkning av vad krav faktiskt är. Det är bara så att ni jobbar mycket mer modernt och snabbt med kravarbete än vad många andra gör.

Det ni gör när ni experimenterar och släpper lös den kreativa sidan hos utvecklarna, testar med spelare och automatiserar gränssnitt och studerar och programmerar utifrån API-specar är ju också krav!

Fast ”Krav” är ett olyckligt ord. Just här använder jag ”krav” som ett samlingsord för alla tekniker, metoder och arbetsuppgifter som leder till förståelse av vad användarna faktiskt behöver och beslut om vad som ska ut i drift eller inte.

”Krav” för mig kan uttryckas muntligt, skriftligt, som en teckning, en modell, en skiss, en dialog, som ett test, som programkod, en första version av mjukvara. Någon sa att den enda sanna kravspecen är programkoden, och det håller jag med om, även om den kanske inte är så läsbar för alla. Programkoden talar faktiskt om för maskinen vad den ska utföra. Det mesta som inte är programkod är tankar och idéer som uttrycks på mer eller mindre luddiga sätt.

”Krav” är analysarbete. Att göra en prototyp av ett spel, eller en tjänst och att låta testa den samt studera och dra slutsatser av resultatet och förbättra eller förkasta är också analysarbete.

Problemet är att ”Krav” är ett så dåligt ord eftersom det associerar direkt till långa kravspecar.

”Krav” kan i min värld vara t.ex:

– En backlog
– Ett experiment eller en prototyp
– En skiss på en näsduk eller whiteboard
– En begrepps/informationsmodell eller domänmodell (vilket ord man nu föredrar..)
– En användarberättelse (user story eller en hel text om kundens resa genom systemen)
– Ett testscenario
– Feedback från någon
– En vision förmedlad av någon (användare, utvecklare, vd, medarbetare, marknadschef, säljare, kundtjänst…)
– Ett kommunicerat mål
– Regler definierade av någon

Jag vill dumpa ordet ”krav” och det är antagligen det vi måste göra för att komma loss från de långa kravspecarnas och användningsfallens bojor. Fenomenet i sig: att analysera, förstå, testa, undersöka, följa upp, visionera & designa försvinner dock inte för att vi dumpar ordet ”Krav”. Det är fortfarande en nödvändighet för att få något värdefullt ut av den mjukvara vi producerar.

Att hej vilt koda utan mål, mening, vision eller feedback vore hrm.. intressant.. att se resultatet av. Jag tror att den här killen från spelföretaget ville säga att de kodade hej vilt och ”kravlöst”, men faktum var att de verkar väldigt strukturerade i sin metod att experimentera och samla in feedback, förstå spelarna och jobba med visioner.

Kravspecifikationen då? Har den spelat ut sin roll?
Ordet i sig, ”kravspecifikation”, måste vi nog också göra oss av med för att bli av med dokument som ingen varken läser eller förstår, förutom den som skrev den.

Specifikationer och dokumentation av olika slag däremot kommer vi fortsätta behöva. I olika grad beroende på hur många beroenden vi har och hur stor vår affär eller verksamhet är. Att publicera ett API/webservice för någon internt eller externt att använda utan någon form av dokumentation blir… svårt för de som ska använda den. Att förvänta sig att mjukvara hos myndigheter, banker eller andra regulerade verksamheter ska anpassa sig till lagstiftning utan någon dokumentation av lagarna blir också.. svårt. Det är också specar.

Att gång på gång undersöka och muntligt sprida affärs- och verksamhetsregler i en stor organisation blir också… svårt. Lyckas man dokumentera dessa regler på ett läsbart och hållbart sätt så kanske man inte behöver så många fler specifikationer.

Problemet med specifikationer är inte att de finns, utan att de är för omfattande, att de snabbt blir inaktuella och beskriver design och andra delar som konstant förändras och att de är svårtillgängliga.

Utmaningen är att specificera tillräckligt lite.

I spelföretagets fall så höll de sina specifikationer i form av automatiserade testfall. Genom att titta i de specarna så förstår man hur spelen fungerar.

Jag har sett verksamheter där man faktiskt har en lätt tillgänglig källa över domänmodellen (informationsmodellen) som uppdateras med exakt vilka koder som betyder vad och vilka regler som gäller.

Det går.

Men kanske går det inte att prata om ”krav” och ”specifikationer” längre. Det för med sig en ryggsäck som vi inte vill ha.

Min ambition är att jobba med både krav och specifikationer utan att prata om dem.

Tests aren’t about testing – Scandev 2012

At Scandinavian Developers Conference April 2012 there were some rememberable messages about testing – what I heard tests aren’t anymore about testing, if it’s ever has been.

Kevlin Henney @KevlinHenney first mentioned the message on testing in his keynote which was really about architecture and good coding – such as economy, visibility, spacing, symmetry and emergence.

About testing he said,  the point of automated tests is NOT how many tests you have,  it is in the meaning of them. To explicitily state rules, to know exactly what we mean in a row of code – that’s the point of testing

Tests turns belief into knowledge.

Gojko Adzic, @gojkoadzic, test and requirement change agent, told us the story of a French team that threw away their automated tests as soon as they’ve passed.  They used automated tests as a

shared understanding of what to do very effectevily

rather than a tool for testing.

He busted a lot about myths of BDD (Behaviour Driven Development) and the challenges on understanding of it from business. He called it

Businessting – the belief business users could write acceptance tests

I’m happy he brought this challenge up. I’ve seen so many teams waiting for business to suddenly show up with very clear, ready to automate, covering test specifications at exactly the right level. Gojko reminded us of the importance of conversation with business people on the rules, on the examples, on the code that’s gonna be written.

The main benefit of Behaviour Driven Development is that is supporting us longterm with information on what the system does – therefore you don’t always need to keep them tightly integrated to the code when they have passed once (!)

We’re obsessed with wrong details.

Jeff Patton,  reminded us also of conversation with business, and of the thing many of us seem to have forgotten about user stories.

User stories, no matter in what written template, was in the beginning there for the purpose of making business people telling stories! Stories about what’s happening in the business, and what could be happening in the future. Now many asks about how to write correct user stories, rather than asking their business person to tell.. their story.

So whatever we do we need to find ways to include business people in our daily conversations 

This seems to be the greatest challenge when it comes to Agile.

Mary Poppendieck, always insightful, brought the subject up of the importance of whole product team. She said we need to let go of ”software development” and talk about what we’re actually doing – product (or service) development to get business on our team so we can do great products and services.

If we believe in whole product teams, which I guess we do if we want to deliver good stuff, software development teams need to start to talk about products (and services)

Go from programming language to design language.

Kvalitet och kommunicera lättrörliga krav – Sundsvall 42

Under konferensen Sundsvall42, som pågick den 18-20 oktober 2011 höll jag ett seminarium på tema ”Att kommunicera lättrörliga krav” i spåret ”Kvalitet” med undertexten ”Ok, nu jobbar vi agilt – är det bättre eller inte”. Flera frågor att svara på alltså, hur gör man det på 40 minuter?

Dessutom var det skrivet att detta är ett seminarium, inte en föreläsning, och min tolkning av seminarium är att det innehåller interaktivitet. Hur gör man en workshop i en biosalong med 60 deltagare?  Det finns säkert bra svar på det, det sätt som dök upp i huvudet på mig inför konferensen var att låta deltagarna refklektera omkring begreppet ”Kvalitet” och hur det kan tillämpas på kravarbete i en alltmer snabbrörlig värld – och dessutom dokumentera on the fly i Prezi. Att servera färdiga svar när det sitter 60 erfarna testledare, kravare, förvaltningsledare i publiken känns på något sätt.. omodernt – det måste finnas bättre sätt. Färdiga svar är bara att googla på – som min nyfunne digitala kamrat @erkstam sa under sitt föredrag om digitalisering.  ”Googla på mig så kan vi skippa hela den där presentationsbiten.”

Googla på ”Agile requirements” så hittar du en del, eller varför inte skaffa ett Twitter-konto tillslut och fråga där! Twitter är en fantastisk yrkeskunskapsbank för tips om artiklar, bloggar, rapporter mm. Om du hittar mig där (@ulrikapark] kan jag hjälpa till lotsa till intressanta grupper där du kan ställa frågan, eller så retweetar jag din fråga. Några tips från mig på tekniker och annat finns lite längre ner.

Prezi-dokumentationen från seminariet  (via traditionell dator behövs inget login). Jag försöker också få ner resultatet här i en något mer fyrkantig form som kanske är lättare att skriva ut. Tack till Ulf Eriksson, Reijo Soréus, Azim Rezaei, adjunkten från Mittuniversitetet och alla andra mycket kloka personer i lokalen som bidrog till ett facit, ett av flera multipla sanningar, för HUR vi bör jobba med krav för att uppnå kvalitet i de system, produkter eller tjänster vi levererar.

Några associationer  deltagarna gjorde till begreppet ”Kvalitet”:
(alla 60 kommer redovisas i separat inlägg)

LEVERERAT ENLIGT BESTÄLLNING

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att leverera enligt beställning (”det får kosta så här mycket, jag vill ha det här”)?

Deltagarnas svar:
Var TYDLIG! Hur blir vi tydliga? Genom DIALOG och MALLAR t.ex User Stories.

Detta brukar jag kalla ”Extreme Expliciteness”. Extrem tydlighet alltså. Att använda krav&test-tekniken ”Specification by example” (Gojko Adzic har skrivit bra böcker i området) i kombination med user stories (Mike Cohn) är mycket användbart för att uppnå extrem tydlighet.

INGA FEL

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att det blir rätt – inga fel?

Deltagarnas svar:
Test & granskning i iterationer!
Demos!
Flera iterationer över ett och samma krav!
Användarmedverkan!
Utvecklarmedverkan!

Inte bara kravaren är med i kravställningen alltså! och involverade på riktigt – mitt tillägg. Det räcker inte med att göra en workshop en gång där man ”samlar in krav” utan utvecklare och användare behöver vara med och påverka kraven löpande under hela genomförandet. Bästa sättet att lära sig mer om detta är att börja pröva idag!  Vad hindrar dig, ditt team, din organisation från att iterera över ett krav flera gånger, eller att involvera utvecklare i processen? Vad kan DU göra för att påverka det i små steg? Sitta 1 dag i veckan hos IT-leverantören? Sitta 1 dag i veckan hos din kravställare?

TRYGGT

Hur gör vi för att uppnå trygghet med kraven?

Deltagarnas svar:
Prototyper
Verifiera kraven, genom demos
Prioritering!
Kommunikation!
Rätt människor med

Ramverket Scrum innehåller många verktyg för just detta – tvärfunktionella team, prioriterade product backlogs och kommunikation och synlighet genom regelbundna demos och tvärfunktionella planeringsmöten (sprintplanering).
Scrum på 5 minuter.
Confessions of a serial Product Owner

ANVÄNDBARHET

Kvalitet är användbarhet. Hur uppnår vi användbarhet när vi arbetar med krav?

Deltagarnas svar:
Prototyper
Användningstester

Mitt tillägg: Engagera en duktig UX-designer (användbarhetsexpert ibland kallad) i teamet – som arbetar med teamet löpande genom hela genomförandet, inte bara i början eller i slutet. Personliga tips: Anette Lovas – Connecta, Fredrik Lindersson  – Söderhavet, Johanna Särnå – Valtech,  Sigrun Tallungs – Frontit, och säkert en hel bunt till därute t.ex på Antrop och Transformator Design.

Intressanta artiklar om User Experience Mapping

HÅLLBAR

Hur uppnår vi krav som håller över tid, är aktuella mer än 3 månader?

Deltagarnas svar:
Tydliga mål!
Gå ner på djupet! Gå ner på domänen och förstå varför.

Mål håller ofta längre än detaljerade krav. Vi ändrar inte målen varje dag, däremot gärna detaljerna beroende på förändrade omvärldskrav eller förväntningar.
Informationsobjekt/domänobjekt håller också längre än detaljer i funktionalitet är min erfarenhet. En informationsentitet – eller domänobjekt – (beroende på vilken ”skola” man pratar med) ändras inte varje dag när man väl lyckas förstå och kommunicera vad det är för objekt ”begrepp” vi pratar om. Därför är domänobjekt t.ex utmärkt lämpliga för att strukturera krav- och testdokumentation omkring, eftersom dessa strukturer håller över tid – åtminstone bra mycket längre tid än en user story.

Dessutom så vid de tillfällen jag varit med vid begreppsmodelleringsworkshops ”med rätt människor med” så har betydligt djupare insikter kommit fram om kraven. Insikter som kan vara både besvärliga och kännas omöjliga, men som verkligen bidrar till en djupare dimension av kravförståelse och detta kan förhindra allvarliga misstag och belysa nödvändiga samband och förändringar. En teknik som används alldeles för lite – eller för stelbent gömt i någons kammare, i ett hemligt filarkiv som bara vissa personer får åtkomst till. Sprid denna teknik!

Tips: Använd SMARTA mål. Googla på SMART goals. Eller fundera på vilka dina klarkriterier är. Beskriv, definiera vad ni menar när ett krav är ”klart” så har du ett mål definierat.
Tips: Arbeta med Domain Driven Design eller Begrepps-/informations-/domänmodellering. Förstå er verksamhet genom modellering. Ta hjälp av duktiga modellerare, kanske finns en ensam arkitekt någonstans hos er som inget hellre vill än att bli inbjuden till teamet och kravställningen? Eller en utvecklare som brinner särskilt för domänförståelse och modellering?

PORSCHE

Hur kan vi arbeta med krav om vi vill skapa en produkt/tjänst som är av motsvarande kvalitet som en Porsche?

Deltagarnas svar:
Smakar det så kostar det!
Sätt rätt förväntningar! Det kanske är ok att det blir en Trabant, bara förväntningarna är satta och kommunicerade så.

Min kommentar: Om vi förväntas skapa de administrativa stödsystemens motsvarighet till en Porsche, eller the BMW of kundtjänstsystem – då behövs det resurser för krav. Vi behöver antagligen flera olika kompetenser – analytiker, arkitekter, ux-designers, exploratory testers.. i teamen. Det räcker inte med en verksamhetsrepresentant på 30%…  Vi behöver också acceptans för att det kostar tid av flera personer i verksamheten såsom affärs-/verksamhetsutvecklare, strateger, domänexperter, personal att delta i användningstest, workshops mm.

OM VI HAR MÅLET ATT GÖRA ALLT DETTA, disciplinerat och ett steg i taget, visst kommer kraven hålla högre kvalitet?

Tack för orden och berätta gärna nästa år på SU42 hur det går med kraven!

Om jag hade trotsat programmet och hållt ett föredrag i stället, hade det jag tagit upp varit just dessa saker. De exempel jag hade med mig handlade om – Tydliga mål, begreppsmodellering, prioritering (backlog), user stories, specification by example och experience mapping – enklare version. Hade inte haft en chans att få med allt – t.ex användningstester och iterationer, så tack till deltagarna för att vi fick med mycket mer än jag hunnit med ensam.

De exempel från verkligheten jag tänkt visa upp finns lite av dem i Prezin. Vid något tillfälle ska jag försöka producera en artikel här om ”exempel från verkligheten på lättrörliga krav”.

Happy development!

Alla älskar vattenfall?

Jag tror de allra flesta organisationer (i Sverige iaf) numera säger att  de vill bli, håller på att bli, eller redan är agila. Åtminstone utifrån de berättelser jag hör och ser.

Vad väldigt få av de personer som uttalar sig om detta verkar vara medvetna om är att organisationen för att dra nytta av de agila metoderna, faktiskt på riktigt helt måste överge vattenfallsmetoden, och den viljan verkar än så länge bara finnas hos några få organisationer och personer. Alla verkar älska sin baby – vattenfallsmetoden, tryggheten, vanan, den kända marken, som visserligen misslyckas konstant men den är ändå känd och förankrad – Så här har vi alltid gjort!

Jag får ibland frågan att hålla utbildning i Scrum och agila metoder – då samtidigt med klausulen . ”Ja, fast vi måste självklart behålla nuvarande process med kravspecande och detaljerad analys och exakt tidsuppskattning innan projektet”. Vad svarar man på det?

alt 1 – Glöm det! Väx upp och säg till när ni är redo för att bli agila, återkom då, så sitter jag o gör annat så länge.

alt 2 – Ok! Kul! Hur antar vi den här utmaningen då? Vad kan vi göra tillsammans under utbildningen och efter för att se och förstå nödvändigheten av att överge babyn för att kunna adoptera en ny? Vad kan vi hitta på?

Hur är din approach?

Själv tror jag att så länge vi väljer att vara i konsultbranschen kan svaret i princip bara bli alt2, men att känna av klimatet ordentligt och faktiskt våga ge upp när det är för lång resa. Kanske är det något annat organisationen behöver först? Kanske gå utbildning i effekthemtagning och mål/visionsarbete, eller varför inte teamutveckling eller verksamhetsarkitektur eller något annat intressant. Scrum kanske inte alltid bör ha företräde i alla organisationer bara för att det känns modernt att säga att man gör Scrum? Det kan beställare tänka på . Vill vi verkligen överge vår baby – vattenfall? Vi älskar den ju så?

ps. för den som undrar. Den här bloggen får helt enkelt bli blandade språk.. ibland svenska ibland engelska.

Systemkraven är de nya verksamhetskraven

Sitter tillsammans med några andra ”kravare” ”produktägar-proxys” eller vad man nu vill kalla det.

Vi har uppdrag av ”verksamheten” att identifiera, prioritera, utreda, kommunicera och följa upp kraven i ett större systemutvecklings/systemförändringsprojekt.

Vi försöker varje dag hålla oss till ”business”-språk och kommunicera omkring kund och verksamhetsanvändning och låta bli att tänka på vilka system saker finns i eller vilka systemlösningar som passar bäst, och helt lämna det till utvecklare.

Problemet är att systemen numera ÄR en del av verksamhetsprocesserna.

Exempel: Vi ska göra en enkel blankett-beställning på webbsidan. Om det nu finns något som längre är ”enkelt” på en normalstor site.

Var sjutton ska blankettbeställningen ta vägen nånstans? Det finns en massa system därbakom i verksamheten för hantering av blanketter som webbutvecklarna (konsulter allihopa såklart) inte alls känner till. Lämnar vi frågan enbart till utvecklarna i just det här lilla teamet att besvara är det stor risk att lösningen blir ytterligare en av alla blankett-lösningar som finns.

Tillbaka till krav. ”Fokusera på vad användarna vill”. Ja, slutkunden vill ha blanketten på snabbaste sätt hem. Kundtjänst vill slippa ännu mer manuellt arbete och att beställningen ska gå helautomatiskt och lagras/loggas.

Vilket av de 5 tänkbara systemen som idag finns ska vi använda? Återstår intervjuer med kundtjänstmedarbetare, de kvarvarande anställda systemmänniskorna som finns och se till att de kommer i kontakt med webbteamet för att hitta bra lösningar. Frågan ligger i knät på krav ett tag till.

Hur länge då?

Jag tror att

1. vi måste acceptera att system- och verksamhetskrav i IT-intensiva verksamheter som nog alla större organisationer är idag, är väldigt väldigt lika och att vi behöver personer med bakgrund från  båda världar för att göra ”rätt sak” och leverera nytta som alla vill. Lär dem och ge dem verktygen att respektera varandra – t.ex teambuilding – låt dem leka ihop, och placera dem bredvid varandra – på bekostnad av andra som vill sitta tillsammans mm.

2. inse värdet av verksamhetskunniga systemutvecklare. Snälla, gör er inte av med dem! Ge dem dubbla lönen, finaste stolen och alla förmåner och kompetensutveckling ni kan – och ge dem sällskap, låt dem utvecklas i par! Det är bara dessa personer som verkligen kan se helheten och hjälpa oss andra (konsulter) att se den.

Finns det någon svensk organisation som gör detta än?

Vad väntar ni på?

Det räcker inte bara att jobba agilt för att lyckas med krav

Även om CS artiklar är rätt ytliga och inte säger så väldans mycket, så tycker jag att den här artikeln åtminstone nosar på vad det är vi behöver för att lyckas med våra krav för system ”Det gäller att se kravhantering som en ledningsfråga, inte som en it-fråga”

http://computersweden.idg.se/2.2683/1.333476/modernast-inte-alltid-bast

Tydliga och välformulerade och förankrade mål, målgrupper och affärsstrategier med systemutveckling börjar hos ledningen eller representanter som sitter mycket nära dem.

Som systemutvecklare och kravare har vi ett ansvar att hjälpa dem med den insikten och inte bara acceptera ogenomtänkta systemlösningar. ”Jag bara utför vad den korkade ledningen säger till mig att göra” håller liksom inte om man ser sig själv som mer än en avancerad kompilator.

Jag har sett fler än ett exempel på väldigt kloka och kreativa systemutvecklare som fullkomligt väller över av synpunkter på hur man ”borde” göra – och de yttrar sig bara när inte ledningen hör..

Eller för den delen kravare som aldrig ställer frågan vad vi vill uppnå och hur strategin ser ut för att nå dit utan ser sig som stenografer av andras viljor. Trots att de ofta sitter på väldigt mycket domänkunskap, affärsidéer och metodkunskap. ”Tänk om jag bara fick göra på _mitt_ sätt då..!”

Och jo, jag kastar sten i glashus för inte sjutton är det lätt att säga vad man tycker när de välartikulerade och karismatiska ledarna är i huset.

Men det går! Det har jag också sett 🙂

Slöseri med resurser att specificera innan utveckling

En för många agilister gammal princip att beskriva, men den tål att upprepas gång på gång.

Varför är det slöseri med resurser att skriva kravspecifikationer för tidigt?

En jämförelse. Jag vill att du renoverar mitt badrum. Renoveringen ska starta i maj nästa år, då du är klar med ett annat jobb du gör åt mig, renovering av mitt fritidshus. Därför börjar jag skriva specifikationen nu, med så många detaljer jag kan komma på. Badrummet ska ha svart golvkakel som jag sett hos Badrumsexperten till ett bra pris. Badkaret ska vara inbyggt av jacuzzimodell. Väggarna ska vara av vitt mosaik-kakel som jag sett och en vägg ska flyttas ut 1,10 meter. Handuksvärmare av modell värmi  mm.

Jag lägger en hel del tid på att hitta allt detta kakelmodeller och badkarsmodeller, spenderar mycket tid hos olika butiker och har redan börjat välja ut handdukar. Vad är problemet med det här?

Det här är ett väldigt enkelt och litet exempel där konsekvenserna inte blir förödande stora om jag kastat bort tiden, men faktum är att det räcker med att

1. Jobbet i fritidshuset tar (naturligtvis) längre tid än planerat, så badrumsrenoveringen kan inte börja i maj, och jag vill ju jobba med samma hantverkare, eftersom vi jobbat upp ett förtroende. Jag måste också säkerställa budgeten för fritidshusrenoveringen innan jag kan börja badrummet. Så den ursprungliga planen är trasig innan vi börjat.

2. När jobbet i badrummet väl kan starta i augusti nästa år visar det sig att det svarta golvkaklet inte alls går att få tag på i Sverige längre då det gått ur mode. Endast importerat från Italien kan beställas till en kostnad av 10 000 kr/kvm i stället för 1000 kr/kvm som planerat. Det är alltså inte längre aktuellt med det här och jag vill byta till vitt golvkakel. Då passar inte längre det vita väggkaklet jag tänkt från början och jag får tänka om, och hitta en ny färg och nya mått som passar med det nya golvkaklet.

3. Eftersom fridishusrenoveringen (naturligtvis) blev dyrare än planerat, måste jag överge tanken på inbyggt jacuzzibadkar och jag får ge mig ut och hitta ett passande stående vanligt badkar. Ut i butikerna igen..

4. När vi ska flytta väggen visar det sig att just den storleken jag tänkt inte fungerar med eldragningar gjorda i huset och en gammal skorstenssockel så måtten får planeras om och den lista jag gjort på golvyta och väggyta får skrivas om.

Någon som känner igen sig? Kanske av renoveringsbekymren? Men knappast inte av den specificerande delen, för VEM skulle skriva en detaljspec 8 månader i förväg av en renovering som ska göras kanske nästa år?? Däremot är det säkert många förnuftiga hemrenoverare därute som 8 månader i förväg börjar fundera på KONCEPTET, bläddrar i badrumstidningar, letar inspiration, gör sporadiska besök i butiker, skissar på papper gör en grovplanering och väntar tills JUST-in-time för att göra en riktig budget och planera det riktiga materialet och väggflyttarna.

Varför undrar jag, motarbetas denna princip så ofta i systemutvecklingsvärlden? Varför envisas så många med att fortfarande skriva detaljspecar på funktioner som KANSKE ska byggas, kanske har budget och kanske är aktuella om ett år, som är helt beroende av implementation av funktioner vi bygger just nu och vi än inte har sett resultatet av?

Min teori är – gammal vana, så har väldigt många (inte alla – inte Google, inte iPhone, inte alla dagens framgångssagor..) gjort de senaste 50 åren. Det går att ändra sig. Men stora förändringar är som alltid förknippad med stor ångest.

Prova att fundera på hur du agerar i andra utvecklings/renoverings/trädgårdsplanerings-, design- och eller förändringssituationer  och där finns många enkla svar på hur utvecklingsprojekt kan komma i mål med betydligt mindre resursslöseri.