Alla som jobbat med krav och lämnar den perfekta listan till IT hemma eller offshore har någon gång fått den brutalt dåliga känslan.
Nä, det gick ju fel!
För att senare säga. Om vi bara hade a,b,c.
I grunden går projekt fel av tre anledningar:
- Orealistiska förväntningar.
- Ändrade förväntningar.
- Icke uppfyllda förväntningar.
Och de som avgör i slutet är användarna i 95% av fallen. Så lösningen är:
Börja med användarna.
Skrev för rätt många år sedan ett inlägg från min tid på riksidrottsförbundet. Vi hade i traditionell mening skrivit krav och fick sällan se saker förrän det var försent. Vi behövde göra något åt det och vände tänket till att visa resultat kring gränssnitt först samtidigt som vi fortsatte att undersöka vilka tekniska möjligheter vi hade. Så den tekniska super-processen:
- Verifiera med användarna att vi som ska leverera något fattat rätt. Gärna som prototyper de kan klicka runt i.
- Förtydliga, prioritera och ta bort krav.
- Bygg.
Acceptanstest handlade om att se om funktionen funkade enligt den tidigare prototyp vi gjort. Inte om den var användbar för det visste vi redan.
När det inte längre är användarvänligt
”Men det här är ju standard” får jag höra rätt ofta. Men om det är oanvändbart. Spelar det någon roll om det är standard?
Vi lägger ofta rätt mycket tid kring användarupplevelsen för vår kund genom kundresor. Vi ser ofta över våra gränssnitt för att optimera hur en kund, medlem, medborgare ska kunna genomföra och lösa det problem de har för stunden.
Varför läggs inte lika mycket när vi bygger våra interna system? Det är också en kundresa, men en medarbetarresa.
Det man glömmer bort är att gränssnittet som alla jobbar i är viktigt. Det är ibland lika viktigt som att det ser bra ut på kontoret.
Det finns otaliga människor, mig inkluderat, som väljer bank efter hur deras mobil-app fungerar. Är det då fel att anta att personer som ska jobba 2000 h per år också får en emotionell känsla av gamla grässnitt?
Slutsats: Så nästa gång du är sugen på skriva en kravlista. Strunta i det och börja med skisser på resultat och gränssnitt istället. Börja ställ frågor där. Gör kravarbetet efter det.
Inom projektledning så har det funnits en ”sanning” länge. De som börjar-med-slutet och backar därifrån har en bättre bild vad som ska hända. Vilket sätt passar då bättre än att faktiskt börja med vilka gränssnitt som användarna ska jobba i som utgångspunkt för arbetet?
Vilka är dina reflektioner?
Proaktivt 