Fanfarer och optimism – så börjar det. Teamet är övertygat om att med några rader kod och några open source-bibliotek så kommer arbetet att gå galant.
Några veckor eller månader senare kommer baksmällan. Är det verkligen tillräckligt bra? Ligger det tillräckligt nära specifikationerna? Kommer någon att använda det? Ofta visar det sig att svaret på åtminstone någon av de frågorna är ett nej. Så hur ser man till att det inte blir så?
Vår amerikanska systersajt CIO.com har plockat ihop några varningstecken att ha koll på – här är några av dem.
Intresset från ledningen svalnar
Har din cio ställt in de senaste tre mötena där ni skulle berätta om hur det hela utvecklas? Har det kanske gått ett år sedan du senast såg cio:n? Har er finanschef ställt frågor om din personalbudget? Är det en sammanslagning på gång som kommer att slå mot er organisation?
Många mjukvaruprojekt misslyckas av helt andra skäl än vilken kod ni skriver. Den i ledningen som gillade projektet och drev igenom det kanske slutar och ni förlorar det stödet. Då spelar det ingen roll hur stora visioner ni har – andra kan ha andra visioner. Så den interna politiken i företaget är en viktig faktor att ha koll på.
Marknaden förändras
Det är inte bara stödet internt som avgör. Även hur det ser ut externt är avgörande. Konsumentmönster kan ändras och marknader kan försvinna på nolltid. Om projektet riktar in sig på en marknad i snabb förändring så är risken givetvis större att förutsättningarna förändrats när det väl är färdigkodat.
Men även om det handlar om ett mer stabilt område kan det dyka upp konkurrens nästan över en natt. Om teamet inte har en plan för hur man ska hantera förändringar så är risken stor att ni misslyckas.
Programmerare hoppar av
Folk byter jobb hela tiden och programmerare är hett byte. Men om teamet oavbrutet förlorar folk är något fel. Är lönerna och arbetsförhållandena tillräckligt bra så kan det ha med projektet i sig att göra.
Är kraven förvirrande så att de hoppar av på grund av mental stress? Är arkitekturen fel så att de inte kan få ihop det? Eller är det så att det finns personer som förgiftar stämningen i teamet och får folk att sluta?
Avhopp kan vara ett tecken på att något inte står rätt till med projektet.
Enkla saker tar lång tid
Hur snabbt kan teamet göra enkla förändringar? Kan de ändra bakgrundsfärgen? Flytta en kryssruta några pixlar? Om de små sakerna inte kan lösas snabbt ja, då är frågan hur lång tid de stora förändringarna kommer att ta.
Dålig arkitektur kan vara boven som gör att även enkla saker blir nästan omöjliga att ändra. Om teamet har problem att klara av de små förändringarna är det en indikation på att grunden är för komplex.
Nollkoll på kostnader
Det är lättare än någonsin att beräkna vad varje användare kostar. Med molntjänster är varje transaktion prissatt.
Men en del projekt har inte en aning om kostnaderna så det är dåliga nyheter när det visar sig att transaktionen som kostar x kronor bara drar in y kronor – där y tyvärr är mindre än x. Så även om mjukvaran fungerar utmärkt så dör projektet av att det är en pengaslukare.
Ett geni tar över
Visst är det toppen när ni lyckats få med smarta personer i ert projekt. Men faran är att en av dem börjar dominera. Det finns undantag men ofta är det ett dåligt tecken när alla plötsligt börjar hänvisa till en enda person. Om den personen dör eller slutar – ja, då förlorar också projektet riktning och styrfart.
Och om personen inte slutar kan det också bli problem – om alla vill kolla av allt med den personen uppstår en flaskhals och saker slutar röra sig framåt. Då spelar det ingen roll att hen är ett geni.
Bråk om kodstandarder
Om utvecklarna börjar bli alltför upptagna av kodstandarder så är det ett tecken att ta på allvar. Det är ett sätt för några att utöva makt och det kan förgifta stämningen i teamet.
När estetiken i intern kod som ingen annan kommer att se blir huvudfrågan och varje felplacerat mellanslag möts av kritik och tal om att koden inte lever upp till standarder – då är risken stor att teamet aldrig når målet.
Oklara affärsspecifikationer
Talas det mer i termer av ”disruption” och att ”förändra världen” och mindre i tekniktermer och om databasval eller arkitekturstrategi? För att utveckla mjukvara krävs konkreta tekniska beslut och är affärsspecifikationerna för vaga är risken stor att misslyckas. För kanske det visar sig kräva för mycket bandbredd, eller att molnkostnaderna blir högre än vad annonserna kan täcka. Det går helt enkelt inte att veta vad som ska hända eftersom planeringen är för odetaljerad.
Dålig planering av tester
En bra plan för testning tittar bakåt och inte framåt genom att man kollar att allt verkligen fungerar som det är tänkt. Det är inte särskilt spännande utan resulterar mest i tjat om att göra om och göra rätt.
Men testning är minst lika mycket en konst som själva kodandet. Om du testar för mycket blir du aldrig klar och om du testar för lite finns risk att koden inte funkar. Att få rätt balans är nödvändigt för ett lyckat projekt.
Orimliga förväntningar
Ibland handlar det inte om själva mjukvaran utan vad folk förväntar sig av den. Det gäller att ha kontroll över projektet så det inte tas över av drömmare och stora tänkare.
Om förväntningarna hålls i schack så går det också att nå upp till dem. Och lyckas man inte med det – ja, då kan den mest fantastiska mjukvara som är utan buggar och är snabb framstå som ett misslyckande.
Artikeln är tidigare publicerad i maj 2019
Läs också:
Här är de sju farligaste programmeringsspråken
