Att driva projekt är ingen lätt sak. Under åren vi har jobbat med webb har vi haft många lyckade projekt, men även en del mindre lyckade. Som en webbyrå som är här för att stanna vill vi därför försöka dra lärdom av projekt som inte går så bra, och förbättra vår process till nästa gång. Såhär ser vår process ut idag.
Vi har anammat agil utveckling eftersom det är det arbetssättet vi tycker ger det bästa resultatet för kunden, samtidigt som det ger schyssta villkor för både oss och vår kund. Genom att ständigt omvärdera projektet och att i små iterationer försöka bygga det kunden behöver snarare än det de från början trodde de ville ha är otroligt viktigt.
Att ha ett sånt här arbetssätt ger en mängd utmaningar. Som tur är finns det lösningar för de flesta av dem. Den första är ju naturligtvis tidsuppskattning och därmed offertskrivande. Hur kan man tidsuppskatta någonting som man bara har en generell idé om vad det kommer sluta som? Det finns bara ett enkelt svar, och det är erfarenhet. Utifrån sin erfarenhet får man försöka gissa ungefär hur mycket tid som kan behövas till en sån typ av projekt. Om kunden sedan har den sortens budget, då kan man börja arbeta.
På så sätt är det enda man kan göra ”gratis” för kunden som inte är en del av ett konsultarbete att konstatera om man har kompetensen för att genomföra projektet eller inte, samt att ge en mycket grov uppskattning på vilken sorts budget de måste ha. Om man sedan känner att man är på samma plan, då kan själva arbetet påbörjas.
Att specificera sitt projekt
Nästa steg i arbetet med vad man skall göra för kund är man tillsammans med kund samlas på en workshop och där skriver man user stories. Det är helt enkelt ett sätt att uttrycka vad för saker man skall kunna göra med det man bygger, och vad för funktioner man behöver ha för att dessa mål skall vara möjliga.
Än så länge har man bara specificerat ganska så tekniska uppgifter eller generella saker man behöver. Vad man behöver göra är att tillsammans ta fram skisser, så kallade wireframes, där man ritar upp vad man vill ha. Det kan hända att ibland så utmanar detta arbetet de user stories man har gjort, och att en del av dem behöver skrivas om eller kompletteras.
När det arbetet är klart så försöker vi uppskatta tidsåtgången via en metod som kallas tidsuppskattningspoker. Alla i arbetsgruppen sätter sig och med den kollektiva erfarenheten kommer man fram till en tidsuppskattning som är ganska så realistisk. Nu har man en ganska så bra uppskattning på hur mycket tid projektet kommer att ta. Redan nu är det dags att jobba med prioriteringar. Vad för saker är viktigast att ha med i projektet? Vad kan vi lägga i framtida versioner? När prioriteringslistan är klar är det dags att skrida till verket.
Veckovisa avstämningar
Det är viktigt att ha en tight kontakt i sitt projekt. Det är viktigt för att projektet skall bli ett framgångsrikt projekt, men även viktigt för projektets transparens. Här har små detaljer väldigt stor innebörd för hur projektet går.
Varje vecka har vi en avstämning med kunden. På detta tillfället går vi igenom vad vi har gjort och pratar om eventuella önskemål samt ändrar i prioriteringen för projektet. Vår ambition är att aldrig behöva utöka projektet utöver den budgeten som är avsatt. Det enda sättet det går att göra, samtidigt som kunden ”får lov” att komma med önskemål längst vägen, är helt enkelt att kunden själv får prioritera.
Till den första avstämningen har vi helt enkelt gjort ett Google-docs / exceldokument där vi har skrivit ner alla våra user stories i den prioriteringsordningen som vi initiellt satte upp i Y-ledd, och i X-ledd har vi sedan arbete lagt över tid.
Detta sätt är bra av flera anledningar. Dels kan vi jobba i små iterationer på ett enkelt sätt. Om kunden tex vill ha en förändring i User story 1, så är detta helt OK. Men; denna skall läggas in som en ny user story. Förändrad funktionalitet får absolut inte ”ingå” i någon befintlig user story, det skapar en situation där det blir väldigt svårt att se förändringar i projektet över tid. Istället läggs denna in i som en ny user story. Detta gör det tydligt att kunden måste prioritera, och någon annan user story kanske måste skjutas ner till nästa version (och därmed ingå i en annan budget).
När budgeten är slut, så är projektet slut.
Genom att leda projektet på det här sättet får man en produkt som man vill ha, samtidigt som man inte överskrider sin budget. Vi brukar göra som såhär att om vi är färdiga med allting innan projektets budget är slut, då får kunden helt enkelt chans att avbryta jobbet där och betalar 25% av det som återstår av budgeten. Om det är så att man inte fick plats med alla user stories som man ville fått med, antingen på grund av att saker tog längre tid än vad vi trott, alternativt därför att kunden prioriterat att skapa nya user stories så får vi helt enkelt göra ett uppföljningsprojekt. Men; Det viktiga att komma ihåg här är att kunden har redan fått en leverans på en produkt som fungerar. Även om inte alla user stories kom med, så har kunden fortfarande fått en fullt användbar produkt. För att utföra resterande user stories gör man antingen ett uppföljningsprojekt, eller beroende på komplexitet går det även att lägga i ett löpande supportavtal.
Löpande samarbete / Supportavtal
Att uppdatera mjukvara, skapa nya funktioner samt göra löpande förbättringar och bidra med support för redaktörer behöver alltid göras. Hos oss gör vi det som supportavtal. Det betyder helt enkelt att man köper ett garanterat antal timmar varje månad som man gör vad man vill för. Och använder man inte de timmar man köper en månad skjuts de helt enkelt över till nästa månad. Här får vi gemensamt komma fram till vad som är rätt nivå, och följa upp över tid om det behövs mer eller mindre tid.