Så säkerställer du affärsnyttan för dina produkter

Transkript

1 Så säkerställer du affärsnyttan för dina produkter Den här guiden ger dig konkreta tips på hur du skapar en effektiv kravprocess som ökar affärsnyttan i ditt företags leveranser.

2 Den här guiden ger dig konkreta tips på hur du skapar en effektiv kravprocess som ökar affärsnyttan i ditt företags leveranser. Med en bättre förståelse för de verkliga faktorerna bakom problemet och på vilken nivå du bör ställa kraven, kan du bidra till bättre kvalitet i de produkter och tjänster som ditt företag produceras. VAD ÄR KVALITET OCH HUR BIDRAR EN EFFEKTIV KRAVHANTERING TILL BÄTTRE KVALITETSSÄKRING? Att ha en effektiv kravprocess i utvecklingsarbetet är avgörande för att uppnå rätt kvalitet. Upplevelsen av kvalitet på olika produkter och tjänster är individuell och det som driver kraven grundar sig helt och hållet i de behov och utmaningar som målgruppen har. Informationen från slutanvändarna är helt avgörande för kundnöjdheten och för att företagets leveranser ska kunna skapa affärsnytta. Många organisationer har dock svårt att hantera återkopplingen från slutanvändare och omsätta det på ett bra sätt i kraven. 1. TA REDA PÅ DET EGENTLIGA PROBLEMET Flera utvecklingsprojekt resulterar i produkter som floppar eller slopas helt när det upptäcks att man skapat en produkt som inte håller rätt kvalitet, eller rent av inte ens behövdes. Onödigt mycket tid och pengar ödslas i alldeles för många utvecklingsprojekt på grund av att man inte ställer rätt frågor från början: Varför tillverkar vi detta?, Vad är din utmaning eller ditt problem?. Målgruppens behov grundar sig i en utmaning i deras vardag och kravhanteringens mål att leverera en lösning som löser just den utmaning som målgruppen har. Operationen lyckades, men patienten dog är en fras som ofta förekommer som metafor inom kravhantering och UX-design. Det är ett sätt att uppmärksamma beslutsfattare och projektledare på de risker det innebär att missa en produkts Varför i kravanalysen och vikten av en noggrann kravhantering. Målgruppens behov grundar sig i en utmaning i deras vardag och kravhanteringens mål att leverera en lösning som löser just den utmaning som målgruppen har. Det kan tyckas självklart för ett utvecklingsprojekt att leverera en produkt som löser en utmaning eller ett problem. Men varför fortsätter då företag att misslyckas gång på gång? Vad hände med Användbarhetstänket? Människan är i naturen lösningsorienterad. Vi ser ett problem och försöker instinktivt att hitta en lösning utifrån det vi just ser. Däremot är vi dåliga på att förstå att det problem som vi ser framför oss, inte alltid är det verkliga problemet. Därför måste kravprocessen alltid inledas med att ifrågasätta produktens betydelse för och utmaningarna hos målgruppen. För att vara helt säkra på att produkten som vi levererar motsvarar målgruppens verkliga behov måste vi validera vår problemdefiniering genom hela utvecklingsprocessen. 2

3 Den bittra verkligheten är att målgruppen själva sällan kan definiera sin utmaning korrekt, eftersom de ofta är ovetande om vad deras egen påverkan innebär för deras utmaning. Det är naturligt svårt att ändra sitt beteende när det gäller problemdefiniering, men som kravledare är just den egenskapen nyckeln till att kunna säkerställa att vi bygger rätt produkt. Nyfikenhet och envishet leder vägen till den faktiska problemorsaken Kravledare är generellt sett duktiga på att försöka involvera målgruppen och gör det ofta genom enkäter, fokusgrupper eller intervjuer. Dessa former räcker ofta för duktiga och erfarna kravledare att bilda sig en god uppfattning av problemområde och behov. Det finns dock en risk med att acceptera målgruppens egen problemdefinition. Användare är ofta väldigt tydliga med vad de vill ha, men det är inte samma sak som vad de faktiskt behöver. Det är därför viktigt att se till hela kravbilden och använda både nyfikenhet och envishet för att hitta den verkliga grunden till problemet. Användare är ofta väldigt tydliga med vad de vill ha, men det är inte samma sak som vad de faktiskt behöver. För att undvika att hamna i fällan måste du kontinuerligt, genom hela utvecklingsprocessen, fortsätta att ställa frågan Varför? : Varför är du stressad? För att jag inte hinner göra allt mitt arbete. Varför hinner du inte göra ditt arbete? För att det tar lång tid att göra mina uppgifter. Varför tar det lång tid? För att det är långsamt att arbeta i systemet. Här hade många antagit att systemet har dålig prestanda, medan med en till fråga kan du utesluta osäkerheterna: Varför är det långsamt att arbeta i systemet? För att jag inte hittar rätt funktionalitet. Svaret innebär alltså att systemet inte nödvändigtvis är långsamt, utan snarare lider av att det är för komplext att förstå funktionaliteten. Ta inte miste i problemformuleringen, så fångar du upp det faktiska problemet I ett projekt jag jobbade i fick vi en buggrapport i form av en video från en kund. Kunden hade spelat in steg-för-steg och visade sitt problem. Han klickade på en ikon, förväntade sig att hamna på en sida men hamnade på en annan. Inte helt förvånande gick det ganska snabbt med problemidentifieringen i projektet och vi glömde hur vi bör jobba med användbarhet. Projektledare pratade med en utvecklare och de skapade tillsammans en problemdefiniering: Knappen fungerar inte som den ska. Därefter påbörjade utvecklaren processen med att rätta problemet, helt ovetandes om vad det faktiska problemet egentligen var. När utvecklaren inte kan återskapa problemet enligt beskrivningen och i koden och konstaterar att det här ska inte kunna hända, det är teoretiskt omöjligt! hamnade det ganska snart i mitt knä som kravledare för en djupare undersökning. I just det här fallet kände till vår målgrupp väl och hade tidigare gjort en målgruppsanalys. Vi hade även tidigare varit i kontakt med kunden, som hade rapporterat felet. Alla inblandade hade erfarenhet av den här typen av rapporter, men var ändå lite för snabba med att dra slutsatser. Jag kollade på videon och hittade orsaken till problemet. Det visade sig att kunden ALLTID dubbelklickade när han navigerade i systemet. Det var alltså inte fel på knappen, den länkade till helt rätt sida. När den sidan laddas fanns däremot en annan knapp på precis samma ställe, vilket innebar att dubbelklick också innebar att man navigerar ifrån sidan man vill till. Problemet Jag hamnar på fel sida Problemdefinitionen Knappen är trasig Orsaken Ett inarbetat beteende hos kund som skapade en förväntning. Lösningen Utbildning och manualer för slutanvändare Misstaget lösningsorienterat tänk kostade projektet tid, pengar och frustration eftersom man inte ifrågasatte problemet tillräckligt. 3

4 2. TÄNK BEHOVSORIENTERAT FÖR KRAVSTÄLLNING PÅ RÄTT NIVÅ En del har varit med och beställt den, andra har konfronterats med den i vardagen och en tredje har varit med och levererat den. Vi talar om lösningen som inte löste problemet! Vad kan du som beställare göra för att oftare lyckas med att beställa lösningar som möter upp mot de bakomliggande behoven i din verksamhet? Svaret är att tänka behovsorienterat och våga ta med leverantören i dialogen kring kravutvecklingen! Kommunicera på rätt abstraktionsnivå Krav kan uttryckas på många olika sätt beroende på vem du frågar, ta en runda på verksamhetsgolvet och du snappar sannolikt upp saker mellan himmel och jord. Tänk om vi kunde ha ett systemstöd som gjorde att vi kunde handlägga fler ärenden per dag. Jag skulle vilja att det gick att lägga in nya värden utan att behöva kontakta leverantörens support. Jag vill ha en ny knapp just HÄR och den skall vara blå! Känslan av att verksamhetens krav ofta är allt mellan himmel och jord brukar vi kravhanterare förklara med att kraven kommuniceras på olika *abstraktionsnivåer. Vissa är övergripande, andra extremt detaljerade. Om kraven dessutom framställs till leverantören på fel abstraktionsnivå, riskerar lösningen att fokusera på att leverera detaljerna istället för helheten. Beställer du en knapp så får du i värsta fall bara en knapp och en knapp löser sällan ensam de komplexa problem som verksamheter brottas med idag. 4

5 Den som tror det kommer att bli besviken. Ändå är det ganska ofta på den mest detaljerade knappkramande *abstraktionsnivån som en beställning kommuniceras från kund till leverantör. Om du grundar dina beställningar på allt för detaljerade lösningskrav, utan att se vilka behov som driver kraven, finns stor risk att lösningen missar målet. Istället för att uppnå dina effektmål blir du sittande med din nya knapp, samma gamla problem, en saftig faktura, sura användare och mindre pengar i projektbudgeten! Därför är det viktigt att du som ska formulera en beställning fokuserar på att det är det bakomliggande behovet som driver kraven och som först och främst måste identifieras. Den blå knappen är kanske bara en av tio delar i att avhjälpa ett verksamhetsproblem eller att uppnå ett effektmål. Problem måste i de allra flesta fall attackeras från flera håll för att lösas, då många verksamhetsproblem i grund och botten har ursprung i organisation och rutiner snarare än i mjukvaran. Således är också långt ifrån alla lösningar relaterade till förändringar i mjukvaran, vilket är viktigt att komma ihåg när du ska beställa något nytt i avsikt att lösa ett problem. Allt för detaljerade lösningskrav, som inte tar hänsyn till vilka behov som driver kraven riskerar att lösningen missar målet. Våga blanda in leverantören i diskussionen Att kommunicera vad du vill uppnå istället för hur det ska gå till, ökar sannolikheten för att du kommer få förslag från din leverantör som bättre möter dina behov. Du och din leverantör har olika erfarenheter och perspektiv på det problem som ska lösas och tillsammans kan ni hjälpas åt att få fram ett optimalt hur. I fallet problem- och behovsanalys kokar faktiskt fler kockar en godare soppa! * ABSTRAKTIONSNIVÅ Hur konkret eller abstrakt något är eller hur övergripande eller detaljerat något är. Benäms oftast som hög eller låg. Vertikal spårbarhet säkerställer att det du beställer ger effekt Det är viktigt att tänka spårbarhet mellan de krav som verksamheten har och de effektmål som lösningen ska uppfylla. Genom att visualisera kopplingen mellan krav och effektmål, ökar sannolikheten för att du hittar ännu fler krav som måste ställas och vinklar som problemet måste angripas ur för att till fullo kunna lösas. Kanske har verksamheten kommit med krav som inte pekar mot något identifierat effektmål alls? Bör dessa då inte genomföras eftersom de inte bidrar till att uppfylla effektmålen, eller indikerar kraven kanske att det finns ytterligare bakomliggande behov som ännu inte är identifierade? Att arbeta aktivt med vertikal spårbarhet mellan krav på olika abstraktionsnivåer gör att du oftare lyckas nå dina mål och därigenom säkra affärsnyttan i både din verksamhets- och systemutveckling. För vem vill vara en del i lösningen som inte löste problemet? För dig som arbetar med systemutveckling eller systemförvaltning ligger grunden för att bygga dina system rätt och för att bygga rätt system i kraven. Kunskap om vad kravarbete innebär och hur vi på bästa sätt fångar in kraven är därför centralt för att kunna arbeta kostnadseffektivt och samtidigt leverera de IT-system verksamheten behöver. Vi hoppas att du får nytta av denna guide och önskar dig lycka till i ditt fortsatta kvalitetsarbete. 5

6 VILL DU HA MER KUNSKAP OM KRAVHANTERING? Vill du hjälp att samla in, analysera, planera och leda så kan vi paketera lösningar som passar ert behov. På ADDQ utgår vi från den verklighet du verkar i och hjälper dig att möta de utmaningar som ditt företag och era målgrupper står inför. Vill du också ha stöd i krav- och kvalitetsarbetet guidar vi gärna dig och ditt företag genom förändringsarbetet mot effektivare kvalitetssäkring för rätt kvalitet och maximal affärsnytta. Vi bistår även med konsulter för att täcka företagets resursbehov på både kort och lång sikt. Våra kompetenser spänner från management consulting och förändringsledning av hela utvecklingsprocessen till kvalitetsspecialister inom enskilda delar av processen. Välkommen att kontakta oss så berättar vi mer! Wallingatan Stockholm info@addq.se 6