Väga vägra vattenfall

IKDNT0YH2N

Att skapa digitala strategier, design och kod kan göras på mer eller mindre lyckade sätt. Jag har lärt mig en del knep och metoder på vägen och sett några skräckexempel på hur man inte ska göra. Den vanligaste och (för kunden) dyraste modellen är vattenfallsmodellen som har sina rötter i tillverkningsindustrin. Här måste allt ske i steg, A innan arbetet går vidare till B. De flesta förespråkar istället(men lever inte upp till) agil utveckling som är en modern motreaktion mot allt det som inte fungerade med vattenfallsmodellen.

Vattenfallsmodellen

Vattenfallsmodellen har till uppgift att med näbbar och klor försöka motverka ändringar i ett sent skede. Den hade sina poänger innan tillverkningsindustrin fick tillgång till datorer och snabba prototypverktyg som 3D-skrivare. Idag är det mest en rest som hindrar digitala produkter från att nå sin fulla potential.

I vattenfallsmodellen sker allt i kronologisk ordning. Först en analysfas, därefter jobbar man fram en kravspecifikation, sedan sker designarbetet. När designen är godkänd och klar börjar implementationen som sedan går till test och lansering. Om beställaren godkänt skisserna på en webbsida så finns ingen möjlighet att komma med förbättringar i ett senare skede. Det blir i såna fall ett nytt projekt efter den första lanseringen, eller i vissa fall en tilläggsbeställning.

Den här modellen kan fungera i riktigt små projekt där risken för ändringar är liten eller minimal och alla krav och förutsättningar är kända redan innan projektet drar igång. Eller i andra ord, nästan inga projekt.

Dessutom finns en användbar produkt först efter att hela projektet är avslutat. Tills slutleveransen har skett är produkten inte testad och inte redo att skeppas ut. Man vet heller inte om det man bygger är rätt produkt. Det finns en risk att fel sak byggs när det inte snabbt kommer ut till test.

Agil utveckling

Ett sätt att motverka det här kallas agil eller iterativ utveckling. Då byggs istället en liten bit helt färdig innan nästa bit påbörjas.

Om en kund till exempel beställt en ny webbsida av en byrå så jobbar byrån och kunden först fram en digital strategi för att reda ut så att alla vet vilket syfte och mål den nya hemsidan ska uppfylla. Det här ska inte bli något långt statiskt styrdokument utan ska snarare vara en kortfattad, lättläst och levande text.

Därefter skapar vi en struktur och design för en liten enskild bit av den totala webbplatsen. Kanske bara en enskild sida. När designen känns good enough tar utvecklarna vid och börjar bygga. Ett av målen är att snabbt få ut en användbar, om än begränsad, produkt.

Snabbt som rackarns försöker byrån att få ut sidan till test för att kunden ska kunna känna och klämma på produkten. Om det som byggts håller måttet lanseras det i de fall det är möjligt, och bara en liten bit i taget. I annat fall görs raskt ändringar och samma lilla bit av kakan kommer ut till test igen.

Ofta är det först när det verkligen finns något att testa som frågorna uppstår. Skulle vi inte kunna göra så här? Tänk om vi skulle kunna ändra den här tankegången hit istället? Byrån ser till att hjälpa kunden att hålla fokus på målet (ökat sälj oftast) och tillsammans jobbar de sig vidare genom utvecklingsprocessen. Agil utveckling kräver täta och snabba kontakter mellan byrå och kund. Risker tas upp och hanteras gemensamt långt mycket tidigare än vad vattenfallsmodellen tillåter.

Agil utveckling handlar inte om att göra någonting slarvigare, tvärt om byggs mindre delar fullt ut tills de är klara. Med agila utvecklingsprocesser går det istället att undvika att en slutprodukt känns lite småhafsig överallt. Varje liten del som släpps kommer att vara putsad och de ändringar som gjordes direkt i början kommer givetvis inte att behöva göras om överallt som om de hade upptäckts sent i vattenfallsmodellen.

Slutprodukten blir bättre, alla inblandade blir mer nöjda och som en bonus blir priset ofta lägre.

Varför gör vi som vi gör?

Så varför används vattenfallsmodellen fortfarande i branchen trots att riskerna är större, priset högre och resultatet sämre? Delvis för att många byråer inte har utvecklat sina arbetsprocesser. Men också för att agil utveckling kräver ett större engagemang och mod från kunden.

Det här är en bloggpost jag först publicerade på minabastapolare.se
Här är den i något omarbetad form igen på min egen sida.

admin

Leave a Reply

Your email address will not be published. Required fields are marked *

Powered by kittens and brainpower.