Alla har vi svurit över att vad som specificerades från början sällan stämmer till 100% när vårt webbprojekt väl är igång. Projektet kantas istället av extrainsatta möten för att förtydliga och komplettera, nya beslut och bilagor samt en förbannad massa frustration från alla parter. Alla typer av projekt kan råka ut för detta, oavsett om de är agila eller traditionella.
Så, finns det en gyllene lösning för att ha ett utopiskt webbprojekt? Nej. Tyvärr.
Men det finns en några tips för att maximera en tydlig kommunikation.
1. Separera VAD från HUR
Det finns inte en specifikation. I sin enklaste form finns det två.
1) Krav specifikation (VAD)
Detta är beställarens roll att bestämma. Vad är det för problem vi vill lösa för kunden eller underlätta. Lägg gärna till ett VARFÖR också, så har du genast affärsargumentet på plats också.
Exempel: Kunden måste kunna logga in i system
2) System specifikation (HUR)
Här ska någon eller några från utvecklarsidan enas om det bästa sättet att uppfylla varje krav i kravspecifikation.
Det är vanligt att beställaren kommer på en funktion som han/hon vill ha. D.v.s. ett HUR. Det är mänskligt och helt normalt. Detta ska vara vägledande, men i kravspecifikationen ska endast resultatet av vad kunden ska åstadkomma finnas med.
2. Show. Don’t tell.
Inom journalistiken är det viktigt att ”tala” målande för att trollbinda läsaren. För webbprojekts systemspecifikation är det överlägset viktigaste en skiss eller mock up över hur en funktion eller sajt ska se ut. Den måste ha alla element som ska finnas med, med rätt etiketter och riktig data. Vilka färger eller vilken font som ska användas är obetydligt i jämförelse med vilken typ av data som ska visas, vilka knappar och länkar som finns och vad som händer när man klickar på dem. Med en bild är det lätt att ha ett effektivt första möte mellan beställare och programmerarna där många frågor får svar. Skriv ner svaren i systemspecifikationen.
På Videoplaza har vi länge använt Balsamiq för mockups och jag tycker att den är helt oöverträffad.
3. Använd samma termer i både kod och kundkommunikation
Språket som används på en sajt eller webbapp är kritiskt för användarvänlighet och för att produkten blir tydlig. Lägg ner mycket tid på att hitta rätt termer och använd dem internt överallt. Marknadsföringen måste kunna förstå vad de säljer och programmerarna måste kunna förstå vad de ska åstadkomma genom att läsa en kravspecifikation. Om programmerarna måste hitta på egna begrepp för de komponenter eller funktioner som de ska bygga kan det tyda på att de inte riktigt förstår vad de ska producera. Genomtänkta termer underlättar också för nya programmerare som vill läsa kod. De förstår vad en funktion hör hemma.
Att använda samma termer är också det lättaste sättet att undvika problem med otydlig kommunikation.
4. Undvik vaga och mångtydiga begrepp
Vaga och mångtydiga begrepp skapar behov av kompletteringar och förtydliganden i både kravspecifikation och systemspecifikation. Alternativt, tolkar läsaren själv in en mening och gör något som avsändaren inte förväntar sig.
Exempel vaghet:
VAGT: En säljare får snabbt tillgång till tydlig information om sina inlagda annonser.
TYDLIGT: En säljare kan se en lista med namn, publiceringsdatum och pris på sina inlagda annonser. Den är sorterad efter publiceringsdatum med senaste publicerade annonsen överst.
Andra vaga ord: mycket, litet, lagom, komplett, full, begränsad, sexig
Exempel mångtydighet:
MÅNGTYDIGT: Sajten ska följa mallen för webdesign genomgående på alla sidor
TYDLIGT: Följande sidor ska innehålla sidhuvud och sidfot enligt vad som anges i dokumentet grafisk_mall_for_webbsidor.pdf.
– Sida blabla
– Sida blabla2
Andra mångtydiga ord: användare, få, skapa, ladda
Tydligt, betyder inte omfattande. Var smart och försökt skriva kort.
5. Du måste kunna testa!
Byggde vi vad vi sa att vi skulle bygga?
I kravspecifikationen ställer vi krav på vad användare ska kunna göra.
I systemspecifikationen finns alla krav på hur användaren går till väga.
Det grundläggande för en kvalitetssäkrare (QA) är att kunna bocka av att systemet faktiskt lever upp till de kraven. Kraven måste med andra ord vara testbara. Skriv gärna ner hur testet ska genomföras tidigt. Det avslöjar även alla vagheter och mångtydigheter i krav.
– – –
Med dessa 5 tips blir nästa webbprojekt lättare. Kommentera gärna och komplettera om det behövs.
/Björn