Brooks lag
Varför fler utvecklare i ett försenat projekt gör det ännu långsammare
När ett mjukvaruprojekt ligger efter schemat är den instinktiva reaktionen från ledningen ofta att tillföra mer personal. Men inom systemutveckling fungerar storskalig problemlösning sällan som ett löpande band. Brooks lag sätter ord på det fenomen som många projektledare erfart: att tillföra fler utvecklare i ett redan försenat projekt gör det i regel ännu mer försenat. I detta kapitel utforskar vi mekanismerna bakom lagen, hur kommunikationskanaler växer exponentiellt och hur man i praktiken undviker denna klassiska fälla.
Bakgrunden och formeln bakom fördröjningen
Brooks lag formulerades av Fred Brooks i hans klassiska bok The Mythical Man-Month från 1975. Lagen uppstod ur erfarenheter från utvecklingen av operativsystemet OS/360 hos IBM. Det centrala resonemanget bygger på två huvudsakliga faktorer: skolningstid och kommunikationskomplexitet.
När nya personer kliver in i ett pågående projekt kan de inte bli produktiva omedelbart. De kräver en introduktion till källkoden, domänkunskapen och arbetssätten. Eftersom det är de befintliga, mest erfarna utvecklarna som måste stå för denna skolning, minskar deras egen kapacitet drastiskt under upplärningsfasen. Projektet tappar alltså styrfart precis när det behöver den som mest.
Den andra faktorn är antalet kommunikationsvägar, som växer kvadratiskt. Antalet unika relationer mellan n personer beräknas med formeln n(n-1)/2. Ett team på fyra personer har 6 kommunikationsvägar. Ökar man teamet till tio personer stiger antalet vägar till 45. Den administrativa och informativa överföringen tar överhanden och ersätter faktiskt kodningsarbete.
Att bära fram ett barn tar nio månader, oavsett hur många kvinnor du sätter på uppgiften.
Praktisk användning och hantering
Hur ska man då reagera när ett viktigt mjukvaruprojekt börjar bli försenat? För det första krävs det att man justerar förväntningarna i tid i stället för att kasta mer personal på problemet. Om datumet inte går att flytta måste man i stället minska på projektets omfattning (scope).
Om man absolut måste tillföra personal bör det göras så tidigt som möjligt i projektlivscykeln, innan förseningen är ett faktum. Dessutom kan man mildra effekterna av Brooks lag genom god arkitektur. Om systemet är uppdelat i fristående, modulära komponenter med tydliga gränssnitt kan nya utvecklare arbeta isolerat utan att störa resten av teamet eller kräva ständig avstämning.
Begränsningar och undantag
Det är viktigt att notera att Brooks lag inte är en universell naturlag för alla situationer. Lagen gäller specifikt förförsenade mjukvaruprojekt med hög komplexitet. Det finns flera undantag där fler personer faktiskt hjälper:
1. Helt oberoende uppgifter: Om uppgifterna är helt fristående från varandra (till exempel att rätta stavfel i tusen fristående dokument) skalar arbetet nästan linjärt. 2. Långsiktig investering: Om man accepterar att projektet blir ännu mer försenat på kort sikt för att bygga upp kapacitet för framtiden kan personaltillskott vara rätt beslut. 3. Senaste generationens verktyg och dokumentation: Med utmärkt automatiserad testning, tydlig arkitektur och bra onboarding-material minskar skolningströskeln avsevärt.
Vanliga misstag och missuppfattningar
Den vanligaste missuppfattningen är att Brooks lag innebär att man aldrig ska utöka ett team. Lagen belyser risken med att lägga till personer sent i processen under tidspress. Ett annat misstag är att behandla utvecklare som utbytbara enheter (så kallade personmånader) där två utvecklare förväntas göra en utvecklares jobb på halva tiden.
Man glömmer också ofta bort den mentala ställtiden och den kognitiva belastningen. Varje ny person förändrar dynamiken i gruppen och kräver omförhandling av beslut, vilket skapar otrygghet och otydlighet om rollfördelningen inte hanteras aktivt.
Tankeövningar
Använd övningarna för att tillämpa kapitlets idéer. Du behöver inte skriva – stanna bara upp och fundera på varje fråga.
Analysera kommunikationsvägar
Reflektera över hur kommunikationsmängden förändras när team växer.
- Hur många personer ingår i ditt nuvarande primära arbetsteam?
- Kan du märka av skillnaden i mötestid när teamet vuxit med bara två personer?
- Hur stor del av din arbetsdag går åt till att förklara kontext för andra?
- Vilka beslut i ditt projekt kräver godkännande från fler än tre personer?
Identifiera delbara kontra odelbara uppgifter
Granska dina arbetsuppgifter för att se om de kan parallelliseras.
- Vilken av dina nuvarande uppgifter skulle gå snabbare om någon hjälpte dig?
- Vilken uppgift skulle ta exakt lika lång tid oavsett hur många som hjälpte till?
- Vad gör en uppgift svår att dela upp i mindre bitar?
- Hur kan du omdesigna en uppgift för att göra den mer modulär?
Utvärdera onboarding-kostnaden
Tänk på vad som händer när en ny kollega ansluter till ett projekt.
- Hur lång tid tar det innan en nyanställd hos er producerar sitt första värde?
- Hur mycket tid tvingas den mest erfarna personen lägga på skolning?
- Finns det dokumentation som gör att en ny person kan starta självständigt?
- Har ni någonsin tagit in någon under kris som i stället sakta ner arbetet?
Hantering av projektspänning
Fundera på alternativ till att utöka teamet när en deadline är hotad.
- Vad händer om du minskar funktionaliteten i stället för att flytta deadline?
- Hur reagerar dina intressenter om du förklarar Brooks lag för dem?
- Vilka delar av projektet kan skjutas upp till en version 2.0?
- Hur kan du skydda teamets fokustid när stressen ökar?
Arkitektur och oberoende
Undersök hur er tekniska eller organisatoriska struktur påverkar samordning.
- Är era projektmoduler tydligt avgränsade från varandra?
- Kan två personer jobba i samma kodbas utan att skapa konflikter?
- Vilka tekniska beroenden skapar flest väntetider i din vardag?
- Hur skulle en mer modulär struktur minska behovet av synkade möten?
Tidig planering kontra sena åtgärder
Reflektera över när i tiden personalförstärkningar faktiskt gör nytta.
- När i ert senaste projekt hade det varit optimalt att ta in fler personer?
- Varför väntar organisationer ofta för länge innan de stöttar ett team?
- Hur kan ni upptäcka fördröjningar flera månader innan deadline inträffar?
- Vilka tidiga varningssignaler tyder på att ett projekt behöver omstruktureras?
Sammanfattning
Brooks lag förklarar varför extra resurser i ett försenat projekt skapar mer kommunikationstrassel än nytta. Genom att förstå skolningstid, kommunikationsvägar och uppgifternas delbarhet kan team fatta bättre strategiska beslut när deadlines närmar sig.
Läs kortversionen i arkivet.