Skip to content
maj 31, 2012 / Dan Kindeborg

Vattenfallsträsket del 2 – Jakten på korrekta estimat

I del ett skrev jag om varför vi UX designers/interaktionsdesigners måste sluta leverera designdokument och börja samarbeta med utvecklarna istället.

För att svara på hur vi åstadkommer denna förändring tror jag vi först måste fråga oss hur kommer det sig att vi hamnat här. Hur kommer det sig att vi fortsätter jobba isolerat och leverera våra designdokument när tekniska kompetenser som utvecklare, arkitekter och testare lärt sig samarbeta?

Jag tror det handlar om flera saker.

Jakten på korrekta estimat

Ett IT-projekt börjar ofta med någon sorts vision om hur något ska bli bättre. Man vill uppnå ett mål, kanske sälja mer prylar via webben eller spara pengar på att personalen kan jobba mer effektivt. Men för att beslutsfattare ska kunna besluta om projektets start vill de veta hur mycket projektet kommer kosta så de kan avgöra om det är värt att lägga pengar på.

För att kunna bedöma hur mycket projektet ska kosta gör man en förstudie där man uppskattar (estimerar) utvecklingstiden. Problemet är att för att få ett så bra estimat som möjligt sätter man igång med att utforma produkten redan i förstudien. Här kommer vi interaktionsdesigners in. Vi är ju experter på utformning av digitala produkter. För att resultatet ska bli bra ska vi vara med och bestämma vad produkten ska innehålla, baserat på våra användarundersökningar, vår erfarenhet och vår kunskap.

Så man löser det hela genom att göra förstudien längre och kallar den designfas eller konceptfas. För att estimaten ska bli riktigt, riktigt bra ser vi till att klara av all utformning i designfasen, inklusive grafisk formgivning. Och vips så har vi ett riktigt maffigt designdokument att leverera till utvecklarna.

Allt det här på grund av att beslutsfattaren ville ha en kostnad på sitt mål. Men den här beräknade kostnaden ligger fortfarande långt ifrån den verkliga kostnaden för utveckling. Det är nämligen mycket svårt att beräkna utvecklingstiden på det som kommer levereras i slutändan, även om man gjort en lång förstudie (hur mycket kostade den, förresten?).

Jobbar man enligt den agila filosofin levererar teamet värde kontinuerligt istället, vilket gör att man ungefär när som helst kan avbryta projektet och fortfarande ha lyckats leverera värde (i teorin). På så sätt tar man en mycket lägre risk än ett traditionellt projekt. Men det blir å andra sidan svårt att tidigt säga hur mycket det kommer kosta att nå målet.

Agila avtal

För att kunna jobba agilt fullt ut måste beslutsfattare förstå och gilla den agila filosofin så de kan besluta om ett projekts start på vagare grunder än idag. Istället för att sätta igång med en kostsam och lång förstudie kör man igång själva utvecklingen direkt och följer kontinuerligt upp om projektet verkar närma sig målet i rimlig takt. Verkar det gå trögt kan man alltid avbryta och investera i något annat. Förhoppningsvis kommer ändå nytta ha levererats innan man bestämmer sig för att avbryta, till skillnad från en misslyckad förstudie som bara slängs i soptunnan.

Det här är inte en enkel förändring att göra och svårare blir det om beslutsfattare och de som ska utveckla kommer från olika företag, så det blir en avtalsfråga. Jag jobbar inte med att utforma avtal men misstänker att det blir svårare att utforma avtal där man inte har någon uppskattad kostnad på slutleveransen.

Historia och kunskap

Det agila manifestet och de agila principerna är skrivet av utvecklare och nämner inga andra teamkompetenser än utvecklare, därför har det också först anammats av utvecklare. Men egentligen går principerna om samarbete och kontinuerlig leverans att applicera även på oss interaktionsdesigners som en del av teamet. Vi behöver bara komma fram till hur detta samarbete med andra kompetenser ska gå till, och det är precis vad som håller på att hända i området som kallas Agil UX eller Lean UX (här försöker Anders Ramsay reda ut begreppsförvirringen).

Många beslutsfattare  och projektledare jobbar trots den agila filosofin som de alltid gjort. En lång designfas följs av en korrekt estimerad utvecklingsfas men med den lilla skillnaden att man kallar utvecklingsfasen för ”agil utveckling”, har standup-möten på morgonen och levererar kontinuerligt.

Vidare läsning

Min kollega Magnus Gudhén körde en presentation om agila avtal på HiQ:s kunskapsbar förra året. Hittade även den här presentationen av Carin Meurlinger.

På engelska finns det mycket skrivet. Här finns utdrag ur boken Scaling Lean & Agile Development. Här finns en artikel på InfoQ av Allan Kelly.

About these ads

4 kommentarer

Lämna en kommentar
  1. jenny / Mar 1 2013 10:47

    Jag känner verkligen igen mig i del 1 i Vattenfallsträsket. Men när jag läste denna del blev jag lite osäker. du skrev:

    ”Istället för att sätta igång med en kostsam och lång förstudie kör man igång själva utvecklingen direkt ”

    I min utbildning (interaktionsdesign) har jag lärt mig att förstudien är jätteviktig för att kunna få fram ett bra koncept genom iterering och samtal med kund, och utvecklare. Dels eftersom utvecklarna inte ska behöva göra om sin kod flera gånger och dels för att kunden ska kunna se hur resultatet ska bli och kunna påverka detta INNAN det är satt i kod.

    För mig är det det som är syftet med wireframes – att kunna visa upp de för kunden och föra en diskussion kring de. Och för att visa upp de för utvecklare så att de kan säga om det är görbart eller inte.

    Därför kan jag inte riktigt få ihop det du skrev…om utvecklarna börjar utveckla hipp som happ hur ska man då kunna få en känsla för helhet? hur ska utvecklarna veta vad de ska utveckla? Och hur ska kunden veta vad han/hon får i slutändan? Det känns okontrollerat!

    Kan tillägga att jag jobbar med stora projekt för väldigt stora kunder så det är ofta komplicerade system. Jag tycker det ofta är problematiskt få ihop ett bra samarbete mellan kund, utvecklare och mig själv som jobbar som UX arkitekt.

    • Dan Kindeborg / Mar 1 2013 17:12

      Tack för kommentaren! Du är inne på något väldigt intressant.

      Poängen är att man kan tjäna på att inte köra långa förstudier utan istället iterera designbesluten med kunden samtidigt som utveckling sker. Designen ska fortfarande vara genomtänkt och diskuterad men istället för att först ta fram all design och sedan börja utveckla så försöker vi dela upp projektet i portionsbitar och jobbar med en tårtbit i taget. Gör vi det så får vi mindre jobbiga överlämningar och mer utrymme för samarbete mellan kompetenser. Det blir också lättare för kunden att påverka utformningen under projektets gång eftersom interaktionsdesignern faktiskt finns med och kan hjälpa till med att ändra designen från start till mål, inte bara i förstudien.

      Den naturliga och svåra frågan blir nu: hur skär man tårtan? Och hur ser man till att allt hänger ihop, vad händer med helheten? Man måste väl börja med att rita ett bra tårtkoncept som täcker in alla bitarna?

      Jag tror fasen där interaktionsdesignern koncentrerat jobbar med att ta fram ett övergripande helhetskoncept behövs, det vi traditionellt kallar förstudie. Men jag tror vi kan korta ner förstudien ordentligt så den bara inkluderar det övergripande helhetskonceptet. Om en förstudie i ett vattenfallsprojekt är 3 månader lång och resulterar i 20 detaljerade wireframes med beskrivningar så kanske en förstudie eller ”sprint 0″ i ett agilt projekt bara behöver pågå i 3 veckor och resultera i beskrivningar av målgrupperna, designprinciper och en skissartad wireframe.

      Att kunden inte vet vad hon får är alltid ett problem. Även om du gör en lång förstudie och visar kunden en interaktiv prototyp kommer det som implementeras i slutändan inte stämma med prototypen. Jag tror snarare på att involvera kunden i processen än att specificera allt från början, då kan kunden få bättre förståelse för frågeställningarna teamet ställs inför.

Trackbacks

  1. Vattenfallsträsket del 1 – Varför vi måste börja samarbeta « Helt Sonika
  2. Vattenfallsträsket del 3 – Nya arbetssätt för agil UX « Helt Sonika

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s

Följ

Få meddelanden om nya inlägg via e-post.

Gör sällskap med 41 andra följare

%d bloggare gillar detta: