Skriv en beslutning som kan vurderes senere

Bevar resonnementet

Et beslutningsmøte gir et valg. Et beslutningsnotat bevarer hvorfor valget ga mening.

Uten resonnementet kan et senere team forveksle en midlertidig begrensning med et permanent prinsipp. Det kan også gjenta en evaluering organisasjonen allerede har fullført.

AWS beskriver arkitekturbeslutningsnotater som en måte å dokumentere beslutninger og konteksten deres på. Samme konsise struktur kan hjelpe med en driftsmodell for AI-utvikling. Hold notatet lite nok til at de ansvarlige leser det.

Sammenlign realistiske alternativer

Et fiktivt selskap må vedlikeholde kontraktsapplikasjonen sin. Det vurderer tre alternativer:

Bruk samme applikasjonsomfang, tidsperiode, dataantakelser og tjenesteforventninger. Unngå å sammenligne en moden kjøpt tjeneste med bare prototypekostnaden for et internt system.

En kombinasjon kan også være riktig. En eksisterende plattform kan levere miljøer og utrulling mens en programvarefabrikk koordinerer utvikling. Forklar grensesnitt og eierskap fremfor å tvinge frem et kunstig alt-eller-ingenting-valg.

Skriv seks deler

1. Kontekst. Angi problemet og konsekvensen av å la det være uendret.
2. Krav. List opp betingelsene et alternativ må oppfylle.
3. Alternativer. Registrer de seriøse alternativene og viktigste avveininger.
4. Dokumentasjon. Lenk evalueringer, kostnadsantakelser og uløste spørsmål.
5. Beslutning. Navngi valgt alternativ, omfang, ansvarlig og aksepterte begrensninger.
6. Gjennomgang. Definer datoen eller den observerbare hendelsen som krever ny vurdering.

Skill det du observerte, fra det du forventer. «Evalueringen fullførte denne vedlikeholdsendringen» er en observasjon. «Tjenesten vil halvere årlig vedlikeholdskostnad» er en prognose som trenger dokumentasjon og tydelige antakelser.

Ta med den sterkeste innvendingen

En kjøpt tjeneste kan redusere integrasjonsarbeid for kontraktsapplikasjonen, men skape avhengighet av en ekstern leverandør. Registrer innvendingen og eksportøvelsen som håndterer en del av den. Ikke fjern innvendingen fordi teamet foretrekker alternativet.

Angi hvilke uløste punkter som blokkerer aktivering. Gi resten ansvarlige og frister. En beslutning om å fortsette gjør ikke et ubesvart kontrollspørsmål til et verifisert resultat.

Gjennomgå notatet når krav eller dokumentasjon endres. Legg til en ny beslutning når valget endres, og bevar det tidligere resonnementet. Fortsett til praktiske Taiga-scenarioer for å anvende prinsippene på produktarbeidsflyter.