Tidigare har vi skrivit inlägg om hur beställare säkerställer framgångsrika webbprojekt. Kortfattat kan misslyckade webbprojekt undvikas genom ett korrekt förarbete, detta kan du läsa mer om här.

Men ibland befinner man sig i projekt som inte går enligt förväntan, då är det viktigt att veta vad som kan göras åt de problem som uppstått. I detta inlägg diskuterar vi de största och vanligaste problemen som kan uppstå under webbprojekt samt hur dessa problem kan lösas.

Det finns vanligtvis två anledningar till att webbprojekt misslyckas. Den ena är att omfattning växer, vilket kallas scope creep, medan den andra är återkommande förseningar. Mestadels är det en kombination av de båda som gör webbprojekt försenade och dyrare än väntat.

Här nedan diskuterar vi dessa två problem och dess lösningar.

Problem: Scope creep

Scope creep är ett vanligt problem inom webbprojekt, vilket betyder att projektets omfattning blir större än förväntat under projektets gång. Vanligtvis handlar detta att kravspecifikationen inte är tillräckligt detaljerad från start. I stället för att skriva en detaljerad kravspecifikation, har endast den tilltänkta webblösningen formulerats genom övergripande förklaringar.

Det är vanligt att förvänta sig att detaljer kan specificeras under projektets gång. Vilket resulterar i att leverantörerna underskattar omfattningen av projektet och därmed brister den ursprungliga estimeringen. Självklart kan inte alla små detaljer bestämmas innan projektstart, men det allra mesta bör vara specificerat och förankrat redan innan utveckling påbörjas.

Men vilka lösningar finns det om projektet redan är påbörjat och omfattningen växer?

Lösning

Ta kontroll över projektet genom att specificera gränssnittet samt varje funktion och övriga detaljer tillsammans med leverantören. Det är viktigt att även specificera icke-funktionella krav såsom prestanda, säkerhet och teknisk sökoptimering. Ladda ner vårt white paper och lär dig mer om vilka icke-funktionella krav som är viktiga – här.

Dessutom är det viktigt att se till att allt dokumenteras, att leverantören tagit del av denna dokumentation och att ni är överens om vad som ska göras. Därefter begärs en ny tidsplan med tydliga milstolpar och deadlines. Den nya strukturen och tidsplanen innebär förhoppningsvis att resterande tiden av projektet inte resulterar i fler överraskningar.

I detta stadie är det också viktigt att diskutera den valda webbtekniken. Detta beror på att förändringar i kravspecifikationen också kan innebära att webblösningen grundstruktur förändras. En hemsida kan bli ett webbsystem och vice versa, vilket kan leda till att den valda webbtekniken inte längre passar webblösningen och därför är felaktig.

Håll tummarna för att detta inte är fallet då detta kan innebära ombyggnationer, vilket kan resultera i både dyrare och försenade webbprojekt. Dock finns det en ganska liten risk för detta eftersom det krävs stora förändringar i kravspecifikationen för att det ska bli så pass fel.

Problem: Återkommande förseningar

Det andra vanliga problemet som kan uppstå under webbprojekt är återkommande förseningar. Vanligtvis är de relaterade till tidigare problem, det vill säga att kravspecifikationen inte är tillräckligt detaljerad. Dock är det självklart möjligt att det finns en tydlig kravspecifikation och att det trots detta uppstår förseningar.

Förseningar kommer ske, men om förseningar sker återkommande bör detta ses som ett varningstecken. I detta stadie bör du ifrågasätta vad förseningarna beror på. Om de beror på sjukdom eller en optimistisk leverantör är det positivt, medan om det beror på svårigheter i utvecklingsarbetet så finns det betydligt större problem.

Lösning

Om de återkommande förseningarna beror på att leverantörer missar milstolpar och deadlines, har leverantören med stor sannolikhet ett felaktigt tidsestimat. Det beror på olika anledningar, till exempel att utvecklarna inte är tillräckligt erfarna och därför håller ett lågt tempo eller inte kan estimera arbeten.

Generellt är det en kombination av dessa två och i sådana fall är det viktigt att ta höjd för leverantörens estimat. Försök då räkna hur lång tid leveranser tidigare tagit i jämförelse med leverantörens estimat, ta sedan höjd för detta i kommande tidsplaner. Om förseningarna beror på leverantörens bristande kompetens bör du självfallet aldrig betala mer än överenskommet.

Vid utveckling av webbsystem händer emellanåt det som vi i branschen kallar för att “koda i cirklar”. Detta innebär att webbsystemet buggar och när man löser en bugg, så dyker en annan upp. Detta blir en negativ spiral, buggar kommer att fortsätta upptäckas och endast öka i antal. Om detta sker har du ett större problem, eftersom det är ett tecken på att källkoden är stökig. Detta kan i en del fall innebära att källkoden måste skrotas och omarbetas, vilket såklart aldrig är önskvärt.

Om du misstänker att källkoden är stökig och eventuellt behöver skrotas, är det bäst att ytterligare en part granskar källkoden. Det är då viktigt att den ursprungliga leverantören delar med sig av källkoden, dock kan du räkna med att de eventuellt kommer vara motstridiga.

Efter granskning bör du få en uppfattning om vad som kan räddas och vad som behöver byggas om. I denna fas rekommenderar vi även att avsluta projektet med den bristande leverantören, dock bör alltid källkod som kan återanvändas sparas.

Samtidigt är det viktigt med tålamod innan man beslutar sig för att blanda in en ny part för att granska koden. Kom ihåg att det är vanligt med många buggar i webbsystem under pågående arbete. Men om du tydligt märker att ett flertal gamla buggar uppstår upprepade gånger och leverantören inte når deadlines, så beror det troligtvis på bristfällig källkod.

Sammanfattning

Sammanfattningsvis finns det två vanliga problem som uppstår under webbprojekt. Det ena är scope creep som betyder att ett projekt blir större än förväntat på grund av en otillräcklig kravspecifikation. Medan det andra är återkommande förseningar, vilket kan bero på olika anledningar såsom optimistisk leverantör, oerfarna utvecklare eller ett felaktigt tidsestimat.

Om scope creep uppstår i ditt projekt kan det vanligtvis lösas genom att ta kontroll över projektet. Detta kan du göra genom att specificera gränssnittet samt varje funktion och övriga detaljer tillsammans med leverantören. Dessutom bör val av teknik diskuteras i detta stadie eftersom förändringar i kravspecifikationen också kan innebära att webblösningens grundstruktur förändras.

Problemet med återkommande förseningar kan vara sammankopplade till andra problem såsom scope creep eller förändringar i kravspecifikationen. I sådana fall är det alltid viktigt att ta höjd för leverantörens tidsestimat. Men om återkommande förseningar fortsätter att uppstå, finns det en risk att den ursprungliga källkoden är stökig och behöver omarbetas. I ett sådant fall måste källkoden ses över av en extern part.