1.0

View in English

1.0 Introduktion till del 1: Människor

Programvara byggs av människor, och människor organiseras av kultur, struktur och processer. Innan vi pratar om kod, arkitektur eller verktyg tittar den här delen därför på det mänskliga system som skapar allt detta: de gemensamma värderingar ett team lever efter, hur det delar upp sig i team, hur det utvecklar karriärer, hur det samordnar sig dag för dag och hur det fattar och minns beslut. Allt annat i boken vilar på de här grunderna. En briljant arkitektur byggd av en rädd, splittrad eller glömsk organisation överlever inte mötet med verkligheten.

För stora team slutar de här grunderna att vara intuitiva och blir strukturella. Arbetssätt som sprids av sig självt bland åtta personer i ett rum faller samman bland åtta hundra spridda över hela världen. Du måste därför göra kulturen uttalad, utforma teamgränser med avsikt, skriva ner förväntningar på utveckling, flytta samordningen från korridorssamtal till varaktiga dokument och dokumentera beslut så att resonemangen överlever dem som fattade dem.

Företag och offentlig sektor känner varje sådant tryck med full kraft. De arbetar i stor skala, under revision och tillsyn, över långa tidsperspektiv och med en blandning av egen personal, konsulter och leverantörer. Ett system du bygger i dag kan köras i ett decennium och underhållas av människor som aldrig träffat dig. I sådana miljöer är grunderna i den här delen inte mjuka färdigheter eller trevliga extrasaker. De är maskineriet bakom institutionellt minne, ansvarsskyldighet och riskhantering.

Kapitel i den här delen

  • 1.1 Värderingar inom programvaruutveckling: De gemensamma föreställningar och vardagsbeteenden som faktiskt styr hur programvara byggs, med tyngdpunkt på psykologisk trygghet, skuldfritt lärande, tydligt ägarskap, en skrivkultur och ett hållbart tempo.

  • 1.2 Teamtopologier och organisationsdesign: Hur uppdelningen av människor i team formar den programvara de kan bygga (Conways lag: organisationer skapar system som speglar deras egna kommunikationsstrukturer), med strömjusterade team, plattformsteam, stödjande team och team för komplicerade delsystem för att minimera kognitiv belastning och minska beroenden mellan team.

  • 1.3 Roller, karriärstegar och utveckling: Att bygga tydliga, kalibrerade karriärramverk med parallella spår för specialister och chefer, så att nivåsättning, befordran, rekrytering och lön blir rättvisa, konsekventa och försvarbara i stor skala.

  • 1.4 Arbetssätt: Hur team samordnar, planerar och levererar dag för dag, med principer före ritualer och som standard asynkrona, dokumentationsdrivna, resultatfokuserade arbetssätt som fungerar över tidszoner och blandade arbetsstyrkor.

  • 1.5 Beslutsfattande och styrning: Att balansera teamens autonomi mot organisationens samstämmighet genom upptrampade stigar, rätt dimensionerad granskning, tänkande kring reversibla mot irreversibla beslut och att hantera teknisk skuld som en portfölj.

  • 1.6 Beslutsloggar: Hur man skriver, lagrar och vidmakthåller beslutsloggar, oftast arkitekturbeslutsloggar (ADR), så att resonemanget bakom ett val överlever personalomsättning och klarar revision, och hur beslut görs sökbara och till och med testbara.

  • 1.7 Tekniska standarder och undantag: Hur en organisation skriver, publicerar, upprätthåller och utvecklar sina tekniska standarder, och hur den hanterar avvikelser genom en styrd, dokumenterad undantagsprocess (dispens) så att standarderna förblir trovärdiga utan att bli stela.

  • 1.8 Rekrytering, intervjuer och introduktion: Att bygga teamet med avsikt genom inkluderande sökning, strukturerade och kalibrerade intervjuer som minskar fördomar och en verklig introduktionsplan som gör nya ingenjörer produktiva och delaktiga snabbt i stället för att låta dem klara sig själva.

  • 1.9 Distribuerat arbete och distansarbete: Att arbeta över platser och tidszoner genom att som standard välja asynkront, skriftligt, dokumentationsdrivet samarbete, utforma medveten överlappning och överlämningar och bedöma människor efter resultat i stället för timmar eller synlighet.

  • 1.10 Teknisk effektivitet och utvecklarproduktivitet: Att mäta och förbättra hur effektivt ingenjörer kan göra sitt bästa arbete med flerdimensionella ramverk (SPACE och utvecklarupplevelse) i stället för enskilda tal som går att manipulera, och att ta bort det friktion och det slit som bromsar team.

  • 1.11 Ledarskap inom utveckling: Hantverket att leda ingenjörer snarare än själva karriärstegen: enskilda samtal, återkoppling och coachning, delegering, human prestationshantering och att mätas som en multiplikator för teamet snarare än på den egna insatsen.

  • 1.12 Mångfald, jämlikhet, inkludering och tillhörighet: Att bygga ett team där olikheter finns, behandlas rättvist, aktivt inkluderas och får känna tillhörighet, eftersom inkluderande team bygger bättre programvara och eftersom det är rätt, med ärlig mätning och utan fasadinsatser.

  • 1.13 Mentorskap, coachning och kunskapsdelning: Att utveckla människor och sprida expertis med avsikt genom mentorskap, coachning och sponsring, praktikgemenskaper, interna föredrag, parprogrammering och dokumentation som undervisning, så att kunskapen överlever varje enskild person och risken med få nyckelpersoner förblir låg.

Hur kapitlen hänger ihop

De här kapitlen bildar en enda röd tråd. Värderingar definierar vad en organisation bryr sig om. Struktur och roller avgör vem som gör arbetet och hur de utvecklas. Arbetssätt styr hur människor samordnar sig. Styrning och beslutsloggar bevarar resonemanget bakom valen. Beroendena löper i den ordningen. Skrivkulturen och den psykologiska tryggheten i kapitel 1.1 är förutsättningar för den ärliga kalibreringen i kapitel 1.3, det dokumentationsdrivna samarbetet i kapitel 1.4 och de varaktiga beslutsloggarna i kapitel 1.6. De teamgränser som utformas i kapitel 1.2 är ditt främsta verktyg för att skala samordningen i kapitel 1.4, som öppet föredrar att minska behovet av samordning framför att lägga på tyngre ramverk. Kapitel 1.5 och 1.6 är ett medvetet par: det första sätter styrningsfilosofin, det andra gör den till en vidmakthållen praktik.

Den här delens räckvidd sträcker sig över hela boken. Teamtopologierna i kapitel 1.2 formar plattformsutvecklingen i kapitel 8.4 och driftansvaret i kapitel 9.1. De beslutsloggar som introduceras här återkommer överallt där viktiga val görs, från arkitekturens grunder i kapitel 3.1 till bygga-eller-köpa och upphandling i kapitel 10.3, och deras säkring med anpassningsfunktioner kopplar till leveransflödena i kapitel 8.1. Det skuldfria lärandet i kapitel 1.1 ligger till grund för incidenthanteringen i kapitel 9.3, och det försvarbara, dokumenterade beslutsfattande som etableras genom hela den här delen är precis vad arbetet med risk, revision och säkerställande i kapitel 10.2 bygger på. Får du grunderna rätt blir resten av boken mycket lättare att tillämpa.