Skriv en beslutning, du kan genvurdere senere
Registrér problem, alternativer, dokumentation, accepterede begrænsninger og betingelser for review. Gør en byg-eller-køb-beslutning forståelig efter mødet.
Udgivet af TaigaSådan skriver vi
Det lærer du
- Skeln mellem krav, antagelser og observationer i en beslutning.
- Sammenlign realistiske alternativer med det samme omfang.
- Angiv en betingelse for review, der kan ændre beslutningen.
Bevar begrundelsen
Et beslutningsmøde giver et valg. Et beslutningsnotat bevarer, hvorfor valget gav mening.
Uden begrundelsen kan et senere team forveksle en midlertidig begrænsning med et permanent princip. Det kan også gentage en evaluering, organisationen allerede har gennemført.
AWS beskriver arkitekturbeslutningsnotater som en måde at dokumentere beslutninger og deres kontekst på. Samme korte struktur kan hjælpe med en driftsmodel for AI-udvikling. Hold notatet kort nok til, at de ansvarlige vil læse det.
Sammenlign realistiske alternativer
En fiktiv virksomhed skal vedligeholde sin kontraktapplikation. Den overvejer tre muligheder:
| Mulighed | Vigtigste ansvar, der bevares internt | Spørgsmål, der kan ændre beslutningen |
|---|---|---|
| Behold den nuværende arbejdsgang med individuelle AI-værktøjer | Forbind kontekst, review, release og dokumentation internt | Kan teamet opretholde koordineringsarbejdet? |
| Byg en intern udviklingsplatform | Design, integrér og driv kapabiliteten | Har organisationen finansieret langsigtet ejerskab? |
| Køb en softwarefabrik som tjeneste | Styr brugen, og integrér de ansvarsområder, organisationen beholder | Opfylder tjenesten de krævede kontroller og grænseflader? |
Brug samme applikationsomfang, periode, dataantagelser og forventninger til tjenesten. Sammenlign ikke en moden købt tjeneste med kun prototypeomkostningen for et internt system.
En kombination kan også være passende. En eksisterende platform kan levere miljøer og udrulning, mens en softwarefabrik koordinerer udviklingen. Forklar grænsefladen og ejerskabet frem for at tvinge et kunstigt alt-eller-intet-valg igennem.
Skriv seks dele
- Kontekst. Beskriv problemet og konsekvensen af at lade det fortsætte.
- Krav. Angiv de betingelser, en mulighed skal opfylde.
- Alternativer. Registrér de seriøse muligheder og deres vigtigste afvejninger.
- Dokumentation. Link til evalueringer, omkostningsantagelser og uafklarede spørgsmål.
- Beslutning. Angiv den valgte mulighed, omfang, ansvarlig og accepterede begrænsninger.
- Review. Definér datoen eller den observerbare hændelse, der kræver ny vurdering.
Skeln mellem det, du observerede, og det, du forventer. »Evalueringen gennemførte denne vedligeholdelsesændring« er en observation. »Tjenesten vil halvere de årlige vedligeholdelsesomkostninger« er en prognose, der kræver dokumentation og udtrykkelige antagelser.
Medtag den stærkeste indvending
For kontraktapplikationen kan en købt tjeneste reducere integrationsarbejdet, men skabe afhængighed af en ekstern udbyder. Registrér indvendingen og den eksportøvelse, der håndterer en del af den. Fjern ikke indvendingen, fordi teamet foretrækker muligheden.
Angiv, hvilke uafklarede punkter der blokerer ibrugtagning. Giv de øvrige ansvarlige og datoer. En beslutning om at fortsætte gør ikke et ubesvaret kontrolspørgsmål til et verificeret resultat.
Gennemgå notatet, når krav eller dokumentation ændres. Tilføj en ny beslutning, når valget ændres, og bevar den tidligere begrundelse. Fortsæt til praktiske Taiga-scenarier for at anvende principperne i produktets arbejdsgange.
Lav øvelsen
Skriv en beslutning på én side for den fiktive kontraktapplikation i lektionen. Sammenlign tre muligheder. Medtag én grund til at afvise din foretrukne mulighed, én uafklaret antagelse og en målbar betingelse for review.
Download arbejdsark (Markdown)Kontrollér din forståelse
Kilder og videre læsning
Relateret læsning fra Taiga
Fjerner du dette valg, slettes al fremgang gemt i denne browser.
Fremgangen bliver i denne browser. Ingen konto, ingen sporing.