Hur får vi acceptans närmare utveckling och vice versa?

2013-09-27 Artikelbanken Test Läst 8586 gånger

Det ska ju bara fungera. ”Hur svårt kan det vara?” Ändå är den produkt som kommer till acceptanstest ibland en helt annan än den som förväntades. Vad beror det på? Hur kan vi komma åt problemet? Det är frågor som vår Thought Leadership-gruppering gärna lyfter fram och som i slutänden bidrar till att våra satsningar på kravhantering och test leder till ökad affärsnytta.

I denna artikel kommer jag att tipsa om sju sätt att föra acceptans och utveckling närmare varandra med hjälp av just kommunikation och tydlighet inom kravhantering och test.

1. Skaffa en bra begreppsgrund att stå på
2. Etablera tydliga roller
3. Ut på fältet
4. Arbeta agilt
5. Jobba med granskning och prototyper
6. Gör användningstester
7. Underskatta inte det sociala

Artikeln handlar om vilka aktiviteter som kan förbättra arbetssättet i projekt och förvaltning men det allra mesta går också att applicera på individnivå. Nyckeln heter kommunikation och tydlighet! Vet vi syftet med projektet, vem som ansvarar för vad och dessutom vågar tänka lite nytt när det gäller arbetsuppgifter så har vi alla möjligheter att lyckas med målet.

 

Grundproblemet

En sak som jag upplevt och som jag gång på gång får höra från kursdeltagare är att avståndet mellan de som ska acceptanstesta, och i förlängningen också använda produkten, och de som utvecklar systemet är alldeles för stort. Det går att överbrygga!

För att lyckas i arbetet med acceptans av ett system, både i form av acceptanstestare och som formell ”godkännare” av det som levereras, krävs det att du måste ha god kännedom om det som skapats. Så fungerar det inte alltid. Självklart kan det ha flera olika anledningar men en ständigt återkommande är att avståndet mellan acceptans och utveckling upplevs väldigt stort. Vad beror det på? Jag tror att anledningarna är flera.

Några exempel kan vara:

• Acceptanstester utförs ofta av personer från verksamhetssidan som inte behöver ha särskilt stor systemkunskap. Utvecklingsarbetet å sin sida utförs av folk på IT-sidan som inte nödvändigtvis har någon djupare verksamhetskunskap. Man har alltså inte länkat ihop systemförståelse (hur) med verksamhetsförståelse (vad) för olika kompetenser.

• Utvecklarna kan ibland känna att ”det är ingen idé att fråga, beställarna vet ändå inte vad de vill ha” vilket kan resultera i att fel produkt skapas.

• Arbetet bedrivs sekventiellt. En formell beställning lämnas och det finns en förväntan att utvecklingssidan ska fixa det som önskas, även om det sällan är klart vad som egentligen behövs.

• Man vet inte vem som ansvarar för vad, vilket medför en risk att saker trillar mellan stolar eller att dubbelarbete utförs.

En gemensam nämnare i ovanstående punkter är bristande kommunikation! Oavsett vad man arbetar med och vilka som är involverade är kommunikation A och O för att uppnå målen. I detta fall rätt produkt med rätt kvalitet, i rätt tid till rätt pris.

Ibland får man inte gehör för önskade förändringar av olika skäl. Det saknas tid, pengar eller resurser. Kanske är förändringar svåra på grund av att ”såhär har vi alltid gjort”. Vissa av tipsen nedan kräver en större insats och behöver förankras i ledningen. Andra är små, påverkar inte tid och kostnad i någon märkbar utsträckning men kommer ge resultat i form av färre fel, bättre produktivitet och trevligare stämning. Ett tips är att alltid göra en konkret planering på åtgärder först, för att sedan visa upp resultat och därefter förtjäna mandat och möjlighet att fortsätta utveckla arbetssätten. Mycket handlar om förståelse. Få säger nej till åtgärder som ger synlig nytta i form av bättre kvalitet.

 

Sju konkreta tips

Och hur gör man då? Även om man jobbat länge med kravhantering och test kan man ha nytta av följande sju tips.

1. Skaffa en bra begreppsgrund att stå på

Folk på verksamhetssidan kan sin verksamhet. De har en massa bra ord och begrepp som kommer att användas flitigt i projektet. Utvecklarna är också jätteduktiga på sitt verksamhetsområde, det vill säga utveckling. Där finns helt egna begrepp och ord som också kommer att användas flitigt. Det är bäddat för missförstånd. Ta bara ordet ”transaktion”. Det kan betyda helt olika saker i olika sammanhang. För en användare kan det vara en överföring av pengar från ett konto till ett annat medan det för en utvecklare kan innebära att en förändring har genomförts och sparats i databasen. Ett sätt att förtydliga är att jobba med begreppsmodellering, informationsmodellering och ordlistor specifikt för detta projekt.

Om verksamhetssidan och utvecklarna har helt olika bild av syftet med projektet är det omöjligt att alla blir nöjda. Jag vill slå ett slag för en gemensam projektvision som alla kan förstå och acceptera. En projektvision ska besvara frågor som:

• Vad är målet med projektet?

• Varför är projektet nödvändigt?

• Vem kommer att få nytta av det, och hur?

2. Etablera tydliga roller

Ofta är många olika roller inblandade i projektet men det är ändå inte säkert att ansvarsfördelningen är tydlig. En person kan HA ansvaret för ett visst område men en annan TAR ansvaret. Detta bäddar för otydlighet.

Tips:

• Se till att ha rätt person på rätt position och beslutsnivå så kommer många saker att slippa ramla mellan stolar och missförstånd kan undvikas.

• Lista aktuella roller och ansvarsområden i en projektstrategi eller projektplan.

• Ha inga vattentäta skott mellan olika roller eller nivåer, t ex mellan beställare och leverantör.

3. Ut på fältet

Det är mycket lättare att förstå någons situation om man själv upplevt den, eller hur? Så utvecklare, ut i kundens verklighet! Försök besöka kunden på plats, se hur systemet ska användas, kanske prova på att utföra arbetet själv? Det kan öka förståelsen för varför kraven ser ut som de gör och även göra det lättare att komma med alternativa lösningsförslag.

På motsvarande sätt kan representanter från verksamheten komma in i utvecklingsarbetet för att få en förståelse för varför saker görs si eller så och varför det inte alltid ”bara är att fixa till” när det uppstår behov av förändringar. Acceptanstestare från verksamhetssidan kommer ofta in väldigt sent i processen; kanske rentav först när det är dags att börja testa. Om du jobbar med acceptanstest – se till att bli involverad tidigare. Du kan jobba med granskning av både krav och testfall, hjälpa till i prototyparbetet, bidra med idéer för att göra produkten mer användbar. Många krav är helt rätt i teorin men eftersom acceptanstestare ofta är de som faktiskt kommer att använda produkten (vilket kravställarna inte alltid är) så kan de ofta komma med idéer och synpunkter som annars inte skulle upptäckas förrän under acceptanstesterna, dvs. alldeles för sent. Acceptanstestare kan ibland hjälpa till redan under tidigare testnivåer systemtest och systemintegrationstest. Redan vid utvecklarnas komponenttester kan det vara bra att ha en acceptanstestare nära till hands för att få ett kvitto på att vi är på rätt väg och bygger rätt system.

Tips:

• Prya på ”andra sidan”. Sätt er in i hur de arbetar på verksamhetssidan/utvecklarsidan. Det kommer öka din förståelse och göra ditt arbete lättare i längden.

• Låt acceptanstestare delta på tidigare testnivåer.

4. Arbeta agilt

Arbeta i korta iterationer och ge alla möjlighet att vara delaktiga på samma villkor. Dagliga möten och täta avstämningar ger möjlighet till en flexibel planering och prioritering utifrån behov istället för prognos. Produktägaren, det vill säga den person som agerar som representant för beställaren och som ingår i det agila teamet kan fungera som en länk mellan acceptanstestarna och resten av teamet. Acceptanstestare kan komma med värdefull input vid detaljeringen av kraven. Kan de dessutom delta på tidigare testnivåer i iterationerna kan många frågeställningar lösas på ett tidigare stadium och man förebygger att bristerna upptäcks under acceptanstesterna.

Inom agil utveckling uppmuntras muntlig kommunikation, som i de allra flesta fall är överlägsen skriftlig när det gäller att komma fram till vad som ska göras, lösa ett specifikt problem och bestämma hur testerna ska genomföras. Långa mailkonversationer medför ofta stor insats till liten nytta. Däremot bör resultatet av den muntliga kommunikationen dokumenteras för att undvika missförstånd och oenighet. Ha dagliga möten (max 10 min), korta avstämningar vid behov eller varför inte bara träffas vid kaffeautomaten och prata väder och vind i fem minuter?

Tips:

• Spika inte planeringen för längre period än några veckor. Då kan kraven utvecklas med hjälp av feedback från användare och acceptanstestare.

• Ha korta dagliga avstämningar, både rörande planering och aktuella frågor.

• Dokumentera resultatet.

5. Jobba med granskning och prototyper

Innan man bestämmer sig för vilken lösning som fungerar bäst i just detta fall är det en bra idé att jobba med prototyper eller skisser. Kunden får eller ger en uppfattning om hur det skulle kunna se ut och hur det skulle kunna fungera. Utvecklarna får mer kött på benen och slipper göra onödigt arbete. Jobbar man agilt kan man till och med avsätta en tidsperiod för att experimentera och undersöka olika alternativ, en så kallad ”spike”.

Att granska prototyper, krav, testfall och designspecifikationer leder i tio fall av tio till högre kvalitet i det som granskas. Olika roller behöver självklart delta för att bilden ska bli komplett.

Tips:

• Jobba ”hands on” med prototyper, skisser, mallar. Det ger bekräftelse att vi bygger rätt lösning och att vi bygger den på rätt sätt. Dessutom kan vi hitta saknade krav, motstridiga krav och krav som inte är testbara, för att nämna några exempel.

• Låt testarna granska kraven.

6. Gör användningstester

Att göra användningstester kommer att ge många aha-upplevelser. Det spelar ingen roll hur noggrant kravhanterare och utvecklare tänkt under framtagande av krav och design av system, det är först när vi frågar riktiga användare som vi får bekräftat hur systemet faktiskt kommer att användas. Användningstester kan göras tidigt, till exempel på prototyper redan i designfasen. Acceptanstestare är ju i många fall faktiska användare och kan representera slutanvändare. Utnyttja den kunskapen!

Tips:

• Låt användare och acceptantestare klämma och känna på produkten i så tidigt skede som möjligt.

• Använd den feedback som kommer in för att utveckla en ännu bättre produkt.

7. Underskatta inte det sociala

Jobb är viktigt men glöm inte att bara ha kul och umgås ibland. Det är ett bra sätt att stärka sammanhållningen i gruppen.

Tips:

• Ha en rolig kick-off när projektet drar igång och en ännu roligare kick-out när det avslutas.

• Många bra tankar och idéer har uppstått på kafferasten. Kör en after work emellanåt eller bara ta en fika, men gör det tillsammans!

 

 

Sammanfattning

Oavsett om projektet precis har börjat sin resa eller om det pågått under flera år finns alltid områden att förbättra. Upplever du att acceptanstesterna och utvecklingen skulle vinna på att närma sig varandra? Här har du fått (minst) sju konkreta tips på aktiviteter att jobba med. Listan skulle kunna göras lång. Vilka är dina bästa förslag?

 

 

Nästa steg

Anmäl dig till en av Konsultbolag1s populära helhetskurser inom kravhantering och test:

Process, roller, ansvar, aktiviteter, begrepp, praktisk verktyglåda inom kravhantering respektive test.

Du kan läsa fler tips och idéer i följande artiklar i Faktabanken:

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln