Basically - Kravställan

Bryt ned problemet

Ofta när det handlar om att uppdatera/skapa nya funktioner, lösa buggar eller rentav planera för en ny webbplats, är det inte alls självklart att man som beställare har koll på hur allt ska lösas. Det man bör ha koll på är vad man i slutändan vill uppnå med förändringen.
Processen som beskrivs nedan är i sin helhet tillämplig på större uppgifter såsom att bygga en ny sajt, med delar av den kan förstås användas för mindre uppgifter.

Processen i översikt

Börja med att skapa dig en uppfattning av hur processen ser ut, vad du kan förvänta dig i vilket steg och av vilken roll. Försök även placera stegen i en övergripande tidslinje. 

• Innan estimat
  • Frågeställning och problembeskrivning
• Estimering
  • Vad behöver den som ska estimera:
    • Finns det design på plats - vem gör detta och när ska det vara klart?
    • Ska estimatet inkludera design? I de fall då det är möjligt är det bra om den som ska estimera/utföra uppgiften arbetar nära den som gör designen för att underlätta kommunikation och eventuella frågor
    • Ska estimatet inkludera uppsättning av analys?
    • Vem tar hand om innehållsskapande och uppsättning?
• Efter estimat
  • Godkännande från beställare
  • Beroende på estimatet - vilka datum ska vad vara klart och vem ska genomföra det?
• Planering
  • Godkännande från båda parter
• Genomförande
• Avslut
  • Retro - är alla nöjda med resultatet, leveransen, budgeten, tidsåtgång enligt kalender/budget?

Epics

Ett bra sätt att börja är att lista allt som du vill uppnå i övergripande områden - epics. Dessa delas sedan in i "must haves" och "nice to haves", dvs vilka funktioner måste finnas med vid lansering och vilka kan göras i mån av tid.

Handlar det om ett större projekt, så som en helt ny webbplats till exempel, kan vi även bryta ned dessa epics i olika releaser, för att få ut det viktigaste först innan vi bygger vidare.

User stories

Epics bryts ned till user stories, för att lättare förklara vad användaren ska uppnå. En user story är målet förklarat ur användarens perspektiv, till exempel "en användare ska kunna boka en tid direkt på sajten för att undvika att hamna på en tredjepartssajt". 

Acceptanskriterier sätts upp för varje user story, där varje kriterium beskriver vad som ska uppnås för att user storyn ska godkännas. Det kan handla om både tekniska och funktionella acceptanskriterier. Varje user story bryts ned till uppgifter att utföra.

• Epic - övergripande önskemål
  • User stories - enskilda fall från användarens perspektiv kring vad vill åstadkomma
    • Kopplade acceptanskriterier (tekniska och icke tekniska) för varje user story

Must have/nice to have

Skriv ned alla dina krav och sortera i:

• Must have
• Nice to have

Vad klarar sig den nya förändringen inte utan i ett första skede, vad skulle vara bra men är inte kritiskt om det fanns med från början osv. Dessa grupperingar kan komma att planeras för olika releaser av lanseringen och kan hjälpa dig och de du jobbar med att prioritera i ett senare skede.

En första release av ett projekt kan innehålla de allra viktigaste komponenterna för att produkten eller sajten ska fungera. Att dela in i olika releaser kan hjälpa till att skapa delmål och hålla projektet levande, samtidigt som man ser till att implementera och testa av enligt de krav som satts upp. 

Nyutveckling eller buggfix

Kravställan är viktigt även för mindre uppgifter. Försök att specificera så gott det går huruvida din förändring gäller en bugg, ny- eller vidareutveckling. Att reda ut detta är viktigt för att få rätt fokus på problemet och kommer hjälpa dig och de som ska utföra arbetet. 
Buggar, sådant som gått sönder eller slutat fungera bör generellt ses över före nya funktioner.

1. Något som tidigare fungerat men inte längre gör det - bugg
2. Något som fungerar men som du önskar fungerade på ett annat sätt - vidareutveckling
3. Något som är menat att det ska fungera som det gör i nuläget - by design - nyutveckling
4. En totalt ny idé - nyutveckling

Om du har fler frågor som rör olika saker/områden/ämnen, dela upp dem i olika förfrågningar för att det ska bli lätt för dig och den som handlägger ditt ärende att reda ut vad som ska göras och för att veta när ärendet är utrett och lanserat.

Buggfix

Om det gäller något som fungerat tidigare men inte längre gör det:

• Vad har du gjort för att försöka åtgärda problemet, berätta vilka steg du tagit

  • Har du testat i inkognitoläget i browsern?
  • Har du tömt cachen?
  • Har du publicerat sidan/blocket?
  • Har du behörighet att göra förändringen?
  • Kan du själv återskapa problemet om du testar igen nu?

Om du skickar in ett ärende för felsökning, se då till att skicka med svaret på följande frågor:

• • Hur länge har det här varit ett problem - upptäckte du det precis nu eller har det varit ett problem tidigare, är det ett återkommande problem?
  • Under vilka omständigheter uppstod problemet;
    • Vilken browser användes?
    • Vid vilken tidpunkt skedde det?
    • Om det dök upp ett felmeddelande vad stod det i så fall?
    • Vilken enhet användes; mobil, dator, tablet?
  • Kan du skicka med en länk till den sida där problemet uppstod
  • Har du tagit någon skärmbild där du kan visa hur det såg ut när du fick problem
  • Ser du någon antydan på sidan till förklaring över varför det inte fungerar som du förväntat dig - finns det något felmeddelande eller annat som beskriver varför det inte fungerar?

Nyutveckling

Om du ska beställa nyutveckling - gå igenom följande punkter:

• Berätta vad du vill åstadkomma som i nuläget inte tycks vara möjligt.
• Vad är syftet med det du försöker åstadkomma?
• Vem är målgruppen - vem ska i slutändan använda det som beställts?
• Om det är fler sajter/domäner/språk inblandade - specificera om förändringen ska slå igenom för alla eller endast specifika marknader.
• När anser du att uppgiften är slutförd - vad skulle få dig att känna dig nöjd med resultatet:
  • Vad förväntar du dig kunna åstadkomma efter det att utvecklingen är klar.?
    • Förklara stegvis både vad du förväntar dig se och hur funktionen ska fungera.
  • Var tydlig, ord som "bra" eller "snygg" är tolkbara och lämnar utrymme för missförstånd vilket är precis sådant du vill undvika när du gör en beställning.
    Ett exempel på en bra beställning: Jag förväntar mig kunna ladda upp 5 bilder i formatet 16:9 som automatiskt ska växla mellan varandra i heron på startsidan var 5:e sekund. När man klickar på dem ska man komma till den sida som jag har länkat till på respektive bild. Det ska fungera med även färre bilder än 5. 
• Vilket datum/tid önskar du att det du beställer är klart och när kan det faktiskt förväntas bli klart, vad kommer ni överens om? Ta reda på om det finns ett avtal på plats, vad som är rimligt att förvänta sig och utgå ifrån det.
• Vad händer om det uppstår problem eller frågor på vägen, hur ska sådana tillfällen hanteras, hur påverkas budget och tidsplan? Kom överens redan från början.
• Vem får ta beslut kring förändringar i projektet? Namnge vem som har sista ordet och om en specifik person måste godkänna förändringar.
• Vem ansvarar för att kommunicera förändringen/nyutvecklingen till de som berörs?
• Ska nyutvecklingen dokumenteras, i så fall av vem och var?
• Vad hoppas du på att uppnå med det du beställer, öka konvertering med x%, x antal fler besökare till sajten, x antal färre timmar för redaktörer nedlagda?
  Sätt upp smarta mål:
  • Specific - tydliga och specifika
  • Measurable - som går att mäta
  • Assignable - vem som ansvarar för att följa upp
  • Realistic - kännas realistiska att uppnå
  • Time-related - planerade i kalendertid, när ska vad vara klart

Regelbundna avstämningar

Det kanske låter självklart, men vi är alla olika när det kommer till kommunikation. Möten som sker mellan beställare och leverantör i början av processen bör inte nödvändigtvis skilja sig så mycket från de regelbundna avstämningar vi rekommenderar att man har under projektets gång. Dock kommer båda partner gynnas längre fram om ni kommer överens om:

• En kravställan uppdelad i eventuella releaser
• En tidslinje
• Vem som förväntas göra vad
• Hur och vad ni ska kommunicera och hur ofta
• Hur ska vi hantera förändringar längs vägen
  • Sådant som påverkar tidsåtgången (kalender och faktisk) - hur hanterar vi sådana förändringar
  • Designförändringar eller förväntningar som inte klargjorts från början - kan påverka sådant som redan hunnit implementeras och planerade lösningar

Gemensamt för alla möten, i större eller mindre utsträckning, är att det blir tydligt efter varje avstämning vad som förväntas av vem, och när i tid det förväntas. 

• Vilka frågor behöver beställare/leverantör få svar på:
  • Vilka ansvarar du för att svara på?
  • Vilka ansvarar någon annan för att svara på?
• När förväntar du dig få svar på dina frågor?
• Vad behöver andra från dig för att kunna ge dig svar?
• Vad är den förväntade utkomsten?
• Vad krävs för att du ska godkänna leveransen?

Använd alla dina kunskaper

När du börjar sätta samman dina önskemål, se till att du redan innan beställningen ser över:

• om det du tänker dig är möjligt - med tanke på webbplatsens uppsättning och befintliga struktur
• om det är rimligt - kommer utkomsten att leverera ett värde som motiverar kostnaden för förändringen
• hur påverkar förändringen SEO och vad bör vi ta med i kravställningen som tar hänsyn till denna
• kan vi styrka just den här förändringen med hjälp av insamlade data, finns det mätvärden som hjälper oss att påvisa att förändringen bör genomföras? Om inte, saknas det spårning i dagsläget som vi i samband med projektet bör sätta upp för framtida utveckling?

Avslutningsvis

Det är inte konstigt att man ibland behöver lite hjälp för att komma vidare men det finns bra och bättre sätt att konkretisera vad problemet är. Om du blir expert på att berätta vad du vill åstadkomma så kommer det inte bara att innebära att du snabbare kommer se resultat, utan även att du lätt kan testa av och godkänna leveransen. Detta oavsett om du beställer ny utveckling eller vill ha hjälp med en bugg eller liknande.

Förväntningar är ledordet här. Undvik att bli besviken, satsa istället från början på att bli nöjd genom att berätta om det förväntade resultatet. Räkna med att det kommer att ske förändringar längs vägen, krav kan komma att förändras eller förtydligas, prioritering mellan delmål skiftar, nya metoder och verktyg öppnar upp för oanade möjligheter med mera. Allt går inte att planera för. Sätt förväntningar från start kring hur ni ska möta de förändringar som kommer att dyka upp längs vägen. 

Ett par snabba frågor...

• Vilken är din yrkesroll?
• Lärde du dig något av artikeln?
• Saknar du någon information eller skulle vilja ändra på någonting?

Kommentera gärna nedan eller maila mig direkt!