Hur mjukvara vill byggas

Ett mjukvaruprojekt kan inte hanteras som andra slags projekt.

Själva det som byggs, produkten, är för komplex för att planeras i förhand. I stället måste planering ske efterhand och korrigera för det vi lär oss längs vägen.

Ju längre planen i ett mjukvaruprojekt sträcker sig, desto mer bör den ses som preliminär.

Grova långsiktiga planer är viktiga som en punkt på horisonten att gå mot, samt för att hitta ett utsnitt av den tänkta produkten, en helhet att skeppa ut så tidigt som möjligt.

Långsiktiga planer behövs i mjukvaruprojekt när vi behöver föreställa oss produktens helhet: t ex för att pröva våra antaganden om användarens behov, för att utveckla affärsmodeller, för att forma användarupplevelsen. (Allt detta kan i sin tur lära oss saker som innebär ändringar i planen.)

I varje skede i ett mjukvaruprojekt bör vi se de långsiktiga planerna som preliminära och därmed basera oss på dem så löst som vi kan.

Även om vi har konkreta planer för det vi gör den här veckan så bör vi erkänna vår ovisshet om de kommande månaderna.

Det rimliga sättet att driva mjukvaruprojekt är alltså evolutionärt, både avseende produktens helhet och dess delar, på ett sådant sätt att vi snabbt får pålitlig feedback.

Mjukvara vill bli byggd evolutionärt,
inkrementellt,
iterativt,
så att varje steg är så förenklat och avskalat som möjligt,
fokuserande på essensen,
kärnan av vad förändringen består i.

Jag vet inte om något annat i motsvarande komplexitet som bör byggas så.

Att mjukvaruprojekt bör drivas evolutionärt avser tre saker:

1. mjukvaran själv,
2. dess värde för användaren, samt
3. den sociala konstellationen individer–team–organisation.

Samtliga dessa börjar som vaga fantasier och får gradvis sin form i ett samspel sinsemellan.

Även ett mjukvaruteam som tidigare har jobbat ihop börjar i stort från noll i och med ett nytt projekt.

I början finns bara någons fantasier om mjukvaran och dess värde för en tänkt användare; inga bekräftade antaganden, ingen samstämmig bild, inget gemensamt språk eller berättelse.

Således utgår ett mjukvaruteam från ett läge med mycket ovisshet, utan ett språk för de diskussioner som är avgörande för att nå tillräckligt mycket visshet för att kunna välja var att börja, för att identifiera en liten helhet som när den klar har chans att besvara många frågor.

Varje mjukvaruprojekt börjar med en idé om något som en möjlig användare skulle kunna se ett värde i. Därefter gäller det att med största möjliga ekonomi bekräfta att det är mer än bara en fantasi. Ytterst sker det först när någon upplever ett värde av att använda mjukvaran.

Alltså är det något som vi vill se så tidigt som möjligt i ett mjukvaruprojekt: att en person får höra vad vår produkt kan ge dem, att de testar den och finner det värdefullt, samt att vi får feedback om att detta har hänt. Ett lyckat litet experiment.

I de flesta mjukvaruprojekt tar det månader eller år innan vi kan få den starkaste formen av feedback: att en användare tipsar en annan om det värde de har fått av vår mjukvara. Då får vi hitta andra sätt att kontinuerligt minska vår ovisshet, med största möjliga ekonomi.

Så fortskrider vårt projekt: vi minskar vår ovisshet, ökar vår förståelse; vi formar ett gemensamt språk och en berättelse inom vårt projekt; vi formar om vår mjukvara när vi bygger vidare; vi formar om oss själva som individer, som team, gentemot andra team och organisationen.