Dåliga system är fortfarande inte utvecklarnas fel: Styr mot effekt och bemanna rätt

Johan Berndtsson

I senaste avsnittet av #JSlive tog Jonas och Richard upp mitt blogginlägg där jag beskriver varför det inte är utvecklarnas fel när när system blir svåra att använda. Richard poängterade då att alla har ett ansvar, och att utvecklarna inte kan frånsäga sig det. Det är helt riktigt, men...

...det problem som jag försökte sätta finget på i mitt förra inlägg är att många utvecklingsteam saknar den kompetens som krävs för att göra ett bra jobb på detta område, och då gör alla inblandade helt enkelt sitt bästa. De utvecklare som designar dåliga användargränssnitt gör så klart inte detta avsiktligt, eller för att de är lata.

Att dåliga system är ett (enormt) problem är vi rörande överens om, men att slentrianmässigt prata om att teknikerna/utvecklarna måste ta sitt ansvar är inte lösningen. De gör, i de allra flesta fall, sitt bästa utifrån givna förutsättningar. Vill vi ha bättre system behöver vi därför ändra förutsättningarna.

Några av de vanligaste, och största, problemen med IT-projekt idag är:

  • Att det saknas tydliga mål. Projekten styrs i huvudsak mot ett visst datum, mot en viss utvecklingsbudget, och mot en lista med funktioner. Istället för funktionslistan borde de styras mot tydliga mål som beskriver vad systemet skall bidra till i verksamheten. Det kan t.ex. handla om att 99% av förstagångsanvändarna skall kunna köpa en biljett till rätt destination i en biljettautomat på mindre än 30 sekunder, och känna sig säkra på att det blev rätt. Detta är grunden i Effektkartläggning, den metod som Jonas rekommenderade i samband med boktipset i programmet.
  • Att det saknas en person (ofta linjechef) som är ansvarig för att de uppsatta målen nås enligt plan. Om det inte finns någon som äger frågan kommer inget att hända...
  • Att rätt kompetens saknas i teamet. De två vanligaste bristerna i detta avseende är (1) produktägare/projektledare som inte insett poängen med, eller saknar kompetensen för, att styra mot effektmål, och (2) att det saknas användbarhetsexperter (interaktionsdesigners, UX designers (kärt barn har många namn)) som kan själva hantverket, och som kan säkerställa att det system som tas fram faktiskt blir så enkelt/effektivt att använda som krävs för att man skall nå de uppsatta målen.
Samtliga av ovanstående punkter är sådant som systemutvecklare (tekniker) har begränsade möjligheter att påverka, eftersom det just är chefernas ansvar att projekten styrs på ett bra sätt och ges bra förutsättningar för att lyckas.

Att styra projekten mot tydliga effektmål och säkerställa att det finns användbarhetskompetens i projekten löser inte alla problem, men det är ett rejält steg i rätt riktning. =)

PS. Om någon är intresserad av att lära sig mer om att styra projekt mot mål enligt ovan rekommenderar jag vår kurs i Effektkartläggning.

Lämna en kommentar

2 kommentarer

  • Felix Reychman

    Ett problem, åtminstone historiskt, har varit att utvecklare ofta inte vetat om att de inte kan. Slänga ut några knappar begriper väl vilken apa som helst hur man gör. Det är ju logiken bakom som är det avancerade.

    Det utvecklarna KAN göra, och bör göra, men nog sällan gör, är att påtala sina egna brister som användbarhetsexperter.

    Där kommer vi nog ofta tillkorta, men det har blivit väldigt mycket bättre.

  • Johan

    Jag håller med om den grundläggande poängen. Men jag upplever att det ofta finns en apati eller ointresse för användbarhet – inte bara hos utvecklare, utan även hos testare, projektledare och andra inblandade. Då hjälper inte mål i sig.

    Jag tror också att en skillnad jämfört med andra aspekter av utveckling är att det är mycket lättare att ha åsikter om gränssnitt, och där är det nog vanligare att utvecklare sätter sig på tvären för att de anser sig veta bättre.