När projektformen inte funkar

Många digitala produkter slutar utvecklas och glöms bort alldeles för tidigt.

Så här går det enligt min erfarenhet ofta till: När projektet är klart, helst inom tid och budget, firar man (det är bra). Sedan går projektmedlemmarna åt olika håll, med undantag för några som blir kvar och ska jobba med förvaltning. Förvaltning innebär att man hanterar buggar. Ska det till något större behövs ett nytt projekt dras igång. Det leder till att man duckar för större förändringar.

Det finns ofta en övertro på vad som kan levereras inom projektets tid och budget. Klart man är alltid tvungen att prioritera bort saker, det är en sak. Men framför allt har man inte hunnit ta sig tid att lära sig om hur användarna faktiskt använder produkten som levereras, på riktigt.

Det går att göra hur mycket användningstester, djupintervjuer och fokusgrupper som helst under projekttiden. Det är ändå inte förrän när precis hela produkten är färdigimplementerad och har använts under en längre tid som man kan säga hur den används och uppfattas.

Det här är ett extra stort problem när man tar fram komplexa system som användarna jobbar intensivt med varje dag. En sådan situation är svår att användningstesta med en prototyp.

Det är också ett problem när man tar fram en ny och innovativ produkt, eller en social tjänst som bygger på att många använder den samtidigt. Det funkar inte att fråga användarna om de kommer köpa eller gilla produkten, hur ska de kunna veta det?

Resultatet när man inte vet tillräckligt om hur användarna kommer använda produkten blir självklart en dålig produkt med ”dålig UX”, alltså fel funktionalitet presenterad på fel sätt.

Leverera tidigare

Dels behöver man sätta produkten (den riktiga produkten, inte prototypen) i händerna på användarna tidigare. För att komma dit tror jag man måste slarva lite. Inte slarva så mycket med det användaren ser utan med strukturerna och koden bakom. Även om det känns fel måste man prioritera att få ut något snabbt istället för att bygga en perfekt systemarkitektur. Man kan slarva med saker som skalbarhet, dokumentation, driftsäkerhet och annat tekniskt som behövs men inte syns.

För att börja slarva på det sättet måste man prioritera upp kunskap om användandet och prioritera ned teknisk elegans. Alla som jobbar med projektet måste förstå varför.

Kontinuerlig förbättring istället för projekt

Dels tror jag man skulle behöva sluta driva projekt med start och slut. Man behöver se utvecklingen som en investering som börjar men aldrig tar slut. I början bränner man mer pengar, förstås. När det är läge minskar man på tempot gradvis. Kalla det inte förvaltning, utan kontinuerlig utveckling och förbättring i rätt tempo. Självklart kontinuerliga användarundersökningar, utvärderingar och redesign när man lär sig mer om hur produkten används. Inget är slaget i sten.

Det här är klart svårt eftersom beslutsfattare gillar budgetar och deadlines. Det handlar om en förändring i hur man tänker kring IT-satsningar och budgetar i stort.

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