Vad varje webbprojekt bör lära sig av Vasaskeppet

Att bygga krigsskepp för flera hundra år sedan och att bygga mjukvara har fler likheter än du kan tro. Vi går igenom vad som gick snett då, och hur du gör för att ditt projekt inte ska kapsejsa.

Regalskeppet Vasa ute på vattnet innan hon sjönk

När regalskeppet Vasa byggdes tänkte de att det nya krigsskeppet måste vara mäktigt, fruktat – det ska vara Östersjöns största skräck. Skeppet skulle ha dubbla däck med kanoner, tung bestyckning, höga master och många skulpturer.

Allt detta vägde så mycket att skeppets manöverduglighet hämmades. Tyngdpunkten blev högre än vanligt, och därför mindre stabilt.

"Borde vi inte testa det här, skeppet känns ostadigt", frågade kapten Hansson efter sjösättningen. Viceamiral Fleming, en mäktig man inom flottan, lät därför genomföra ett test av skeppets stabilitet.

Testet gick till så här: trettio män fick springa från den ena sidan av skeppet till den andra, men redan efter bara några vändor krängde Vasa så mycket att testet måste avbrytas. Kungen var inte närvarande vid testningen, han var upptagen i Polen och stressade på viceamiralen i brev efter brev att skeppet måste bli klart så snart som möjligt. Han informerades inte om de kända bristerna, och skeppet färdigställdes enligt ritning.

"Jaja, det löser sig, var inte så negativ", sa kanske någon. Sedan vet vi alla hur det gick. En kastvind sänkte skeppet på jungfruresan bara ett stenkast från Gröna Lund.

Efter olyckan frågades kaptenen, viceamiralen, skepparen och en löjtnant ut om varför skeppet sjönk. Ingen ville ta på sig skulden. Till slut enades man om att skylla allt på skeppsbyggmästaren Hybertsson. Han var redan död då och kunde inte försvara sig.

Vad har detta med webb att göra?

Det har massor med webb att göra. Att bygga ett skepp kan på många sätt liknas vid att bygga mjukvara.

Behovet (att ha ett fruktat krigsskepp) kommunicerades av en beställare/stakeholder (kung Gustav II Adolf).
Lösningen (dubbla batteridäck/höga master/skulpturer) skissades fram av en designer (skeppsbyggmästaren).
Detta kan ses som features (funktioner).
En produktägare (flottan/viceamiralen) gav grönt ljus att bygga funktionerna och tog order från beställaren.
Utvecklarna (varvet) byggde funktionerna.
Det fanns en projektledare (skeppsbyggmästaren).
Funktionerna testades av testare (30 män).

Tre tips för att ett projekt inte ska kantra

Våga problematisera

Ställ många frågor tidigt, var "jobbig" – då ökar chanserna att bygga rätt från början. Varför bygger vi detta, för vem? Kommer det att hålla? Vad händer om x, y och z? Om en idé eller funktion inte tål att provtryckas eller att testas tidigt, så tål den inte heller att testas i produktion. Att "problematisera" är inte detsamma som att vara negativ.

Ha modet att säga till

Räck upp handen när något känns tokigt. Det är att ta ansvar. Men att våga säga "hmm, det här som vi bygger just nu verkar inte funka så bra, kan vi stoppa lite" kan kännas otäckt. Det krävs mod att stå upp mot ett team eller en stark ledare. Kanske är ledaren auktoritär, hen kanske antyder att du är motsträvig, en som inte samarbetar. Du vill ju inte förlora jobbet eller skapa dålig stämning.

Kapten Hansson vågade i alla fall säga till, och det gjordes tester. Men varför fortsatte de ändå att bygga klart? Det kan vi mest spekulera kring. Känner du igen dessa resonemang?

Vi har investerat så mycket tid/resurser i detta.
Det är för sent för att dra i handbromsen.
Vi har redan passerat deadline, vi måste leverera nu.
Så mycket pengar har plöjts ner i detta, vi måste lansera det.
Det är inte försvarbart att bara lägga ner allt.

Dessa är alla uttryck för "sunk cost", vilket innebär en kostnad som redan har uppkommit och inte kan återvinnas. Det tog tid att bygga Vasa. Och det var definitivt inte billigt heller. Förväntningarna var säkert höga och säkert ville de inte tappa ansiktet inför kungen och folket? Inte kan väl vi, flottan, misslyckas?

Det finns tyvärr ett otal exempel på sajter och tjänster som har misslyckats genom åren. Det kan röra sig om säkerhetshål, prestandaproblem eller en dålig användarupplevelse, för att inte tala om obegriplig kod eller tillgänglighetsbrister.

Misslyckas tidigt ("fail fast")

Ett sätt att undvika en hög "sunk cost" är principen om "fail fast". Den går ut på att hitta brister tidigt, så att teamet kan lära sig av misstagen. Att testa flöden, att avbryta, justera och lägga om kurs innan teamet har kommit för långt ska ses som en del av arbetet.

Vasaskeppet blev ju till slut en succé, men inte alls på det sätt designern hade tänkt. Du vill nog inte att din sajt ska misslyckas så spektakulärt att folk kommer att prata om det i flera hundra år?

Källor

https://www.vasamuseet.se/
https://sv.wikipedia.org/wiki/Regalskeppet_Vasa
https://en.wikipedia.org/wiki/Fail-fast

Kuriosa

Metamatrix byggde sajten för Vasamuseet en gång i tiden! Vår version ligger arkiverad någonstans på havets botten!
Webbplats för Vasamuseet, arkiverad på Wayback Machine