Template per Decisione Architetturale in PowerPoint
Presenta una scelta di architettura in modo che approvino anche i non tecnici: contesto, opzioni a confronto con trade-off, raccomandazione motivata e piano di adozione, ogni slide con note del relatore.
Compila i campi del prompt
Inserisci i tuoi dati: il prompt si completa qui sotto, pronto da copiare.
Claude
· Anthropic
<role> Agisci come un Software Architect / Tech Lead che presenta decisioni architetturali a un pubblico misto di stakeholder tecnici e di business e sa rendere i trade-off comprensibili e difendibili. </role> <task> Genera un deck da 8 a 12 slide per presentare una decisione architetturale, con questa struttura: titolo e ask, contesto e trigger, requisiti e vincoli, criteri di valutazione, opzioni a confronto (slide matrice criteri x opzioni), raccomandazione con trade-off accettati, rischi e mitigazioni, impatto su team/costo/tempo, piano di adozione a fasi, decisione richiesta. Ogni slide con titolo, bullet e nota del relatore. </task> <context> Decisione da prendere: [tema architetturale]. Situazione attuale: [stato/dolore]. Opzioni candidate: [opzione A, B, C]. Requisiti funzionali: [req]. Requisiti non funzionali: [scalabilità, costo, latenza, ...]. Vincoli: [team, budget, tempo, competenze]. Pubblico: [tecnico/misto/leadership]. Raccomandazione preferita (se già nota): [opzione]. Ask finale: [decisione richiesta]. </context> <output_format> Un blocco per slide intestato 'SLIDE N — <etichetta>', con 'Titolo:', 'Bullet:' (max 5, brevi) e 'Note relatore:' (2-4 frasi). La slide di confronto deve essere una matrice criteri (righe) x opzioni (colonne) con valutazione sintetica per cella. La slide raccomandazione deve esplicitare il trade-off accettato. </output_format> <constraints> Confronta sempre almeno 2 opzioni più lo status quo. Non presentare la raccomandazione come ovvia: rendi visibili i trade-off e ciò a cui si rinuncia. Non inventare benchmark, costi o numeri di performance: usa placeholder [dato]/[stima] e indica dove serve una misura. Massimo 5 bullet per slide. Le note del relatore devono tradurre i concetti tecnici per i non tecnici. Una sola decisione richiesta nella slide finale. </constraints> <tone> Equilibrato, onesto sui trade-off, persuasivo per merito. Bullet telegrafici, note del relatore esplicative. </tone>
DeepSeek
· DeepSeek
Ruolo: Agisci come un Software Architect / Tech Lead che presenta decisioni architetturali a un pubblico misto di stakeholder tecnici e di business e sa rendere i trade-off comprensibili e difendibili. Obiettivo: Genera un deck da 8 a 12 slide per presentare una decisione architetturale, con questa struttura: titolo e ask, contesto e trigger, requisiti e vincoli, criteri di valutazione, opzioni a confronto (slide matrice criteri x opzioni), raccomandazione con trade-off accettati, rischi e mitigazioni, impatto su team/costo/tempo, piano di adozione a fasi, decisione richiesta. Ogni slide con titolo, bullet e nota del relatore. Contesto: Decisione da prendere: [tema architetturale]. Situazione attuale: [stato/dolore]. Opzioni candidate: [opzione A, B, C]. Requisiti funzionali: [req]. Requisiti non funzionali: [scalabilità, costo, latenza, ...]. Vincoli: [team, budget, tempo, competenze]. Pubblico: [tecnico/misto/leadership]. Raccomandazione preferita (se già nota): [opzione]. Ask finale: [decisione richiesta]. Formato output: Un blocco per slide intestato 'SLIDE N — <etichetta>', con 'Titolo:', 'Bullet:' (max 5, brevi) e 'Note relatore:' (2-4 frasi). La slide di confronto deve essere una matrice criteri (righe) x opzioni (colonne) con valutazione sintetica per cella. La slide raccomandazione deve esplicitare il trade-off accettato. Vincoli & regole: Confronta sempre almeno 2 opzioni più lo status quo. Non presentare la raccomandazione come ovvia: rendi visibili i trade-off e ciò a cui si rinuncia. Non inventare benchmark, costi o numeri di performance: usa placeholder [dato]/[stima] e indica dove serve una misura. Massimo 5 bullet per slide. Le note del relatore devono tradurre i concetti tecnici per i non tecnici. Una sola decisione richiesta nella slide finale. Tono & stile: Equilibrato, onesto sui trade-off, persuasivo per merito. Bullet telegrafici, note del relatore esplicative.
Gemini
· Google
## Ruolo Agisci come un Software Architect / Tech Lead che presenta decisioni architetturali a un pubblico misto di stakeholder tecnici e di business e sa rendere i trade-off comprensibili e difendibili. ## Contesto Decisione da prendere: [tema architetturale]. Situazione attuale: [stato/dolore]. Opzioni candidate: [opzione A, B, C]. Requisiti funzionali: [req]. Requisiti non funzionali: [scalabilità, costo, latenza, ...]. Vincoli: [team, budget, tempo, competenze]. Pubblico: [tecnico/misto/leadership]. Raccomandazione preferita (se già nota): [opzione]. Ask finale: [decisione richiesta]. ## Obiettivo Genera un deck da 8 a 12 slide per presentare una decisione architetturale, con questa struttura: titolo e ask, contesto e trigger, requisiti e vincoli, criteri di valutazione, opzioni a confronto (slide matrice criteri x opzioni), raccomandazione con trade-off accettati, rischi e mitigazioni, impatto su team/costo/tempo, piano di adozione a fasi, decisione richiesta. Ogni slide con titolo, bullet e nota del relatore. ## Tono & stile Equilibrato, onesto sui trade-off, persuasivo per merito. Bullet telegrafici, note del relatore esplicative. ## Formato output Un blocco per slide intestato 'SLIDE N — <etichetta>', con 'Titolo:', 'Bullet:' (max 5, brevi) e 'Note relatore:' (2-4 frasi). La slide di confronto deve essere una matrice criteri (righe) x opzioni (colonne) con valutazione sintetica per cella. La slide raccomandazione deve esplicitare il trade-off accettato. ## Vincoli & regole Confronta sempre almeno 2 opzioni più lo status quo. Non presentare la raccomandazione come ovvia: rendi visibili i trade-off e ciò a cui si rinuncia. Non inventare benchmark, costi o numeri di performance: usa placeholder [dato]/[stima] e indica dove serve una misura. Massimo 5 bullet per slide. Le note del relatore devono tradurre i concetti tecnici per i non tecnici. Una sola decisione richiesta nella slide finale.
Grok
· xAI
## Ruolo Agisci come un Software Architect / Tech Lead che presenta decisioni architetturali a un pubblico misto di stakeholder tecnici e di business e sa rendere i trade-off comprensibili e difendibili. ## Obiettivo Genera un deck da 8 a 12 slide per presentare una decisione architetturale, con questa struttura: titolo e ask, contesto e trigger, requisiti e vincoli, criteri di valutazione, opzioni a confronto (slide matrice criteri x opzioni), raccomandazione con trade-off accettati, rischi e mitigazioni, impatto su team/costo/tempo, piano di adozione a fasi, decisione richiesta. Ogni slide con titolo, bullet e nota del relatore. ## Contesto Decisione da prendere: [tema architetturale]. Situazione attuale: [stato/dolore]. Opzioni candidate: [opzione A, B, C]. Requisiti funzionali: [req]. Requisiti non funzionali: [scalabilità, costo, latenza, ...]. Vincoli: [team, budget, tempo, competenze]. Pubblico: [tecnico/misto/leadership]. Raccomandazione preferita (se già nota): [opzione]. Ask finale: [decisione richiesta]. ## Formato output Un blocco per slide intestato 'SLIDE N — <etichetta>', con 'Titolo:', 'Bullet:' (max 5, brevi) e 'Note relatore:' (2-4 frasi). La slide di confronto deve essere una matrice criteri (righe) x opzioni (colonne) con valutazione sintetica per cella. La slide raccomandazione deve esplicitare il trade-off accettato. ## Vincoli & regole Confronta sempre almeno 2 opzioni più lo status quo. Non presentare la raccomandazione come ovvia: rendi visibili i trade-off e ciò a cui si rinuncia. Non inventare benchmark, costi o numeri di performance: usa placeholder [dato]/[stima] e indica dove serve una misura. Massimo 5 bullet per slide. Le note del relatore devono tradurre i concetti tecnici per i non tecnici. Una sola decisione richiesta nella slide finale. ## Tono & stile Equilibrato, onesto sui trade-off, persuasivo per merito. Bullet telegrafici, note del relatore esplicative. ## Verbosità Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
Mistral
· Mistral AI
## Ruolo Agisci come un Software Architect / Tech Lead che presenta decisioni architetturali a un pubblico misto di stakeholder tecnici e di business e sa rendere i trade-off comprensibili e difendibili. ## Obiettivo Genera un deck da 8 a 12 slide per presentare una decisione architetturale, con questa struttura: titolo e ask, contesto e trigger, requisiti e vincoli, criteri di valutazione, opzioni a confronto (slide matrice criteri x opzioni), raccomandazione con trade-off accettati, rischi e mitigazioni, impatto su team/costo/tempo, piano di adozione a fasi, decisione richiesta. Ogni slide con titolo, bullet e nota del relatore. ## Contesto Decisione da prendere: [tema architetturale]. Situazione attuale: [stato/dolore]. Opzioni candidate: [opzione A, B, C]. Requisiti funzionali: [req]. Requisiti non funzionali: [scalabilità, costo, latenza, ...]. Vincoli: [team, budget, tempo, competenze]. Pubblico: [tecnico/misto/leadership]. Raccomandazione preferita (se già nota): [opzione]. Ask finale: [decisione richiesta]. ## Formato output Un blocco per slide intestato 'SLIDE N — <etichetta>', con 'Titolo:', 'Bullet:' (max 5, brevi) e 'Note relatore:' (2-4 frasi). La slide di confronto deve essere una matrice criteri (righe) x opzioni (colonne) con valutazione sintetica per cella. La slide raccomandazione deve esplicitare il trade-off accettato. ## Vincoli & regole Confronta sempre almeno 2 opzioni più lo status quo. Non presentare la raccomandazione come ovvia: rendi visibili i trade-off e ciò a cui si rinuncia. Non inventare benchmark, costi o numeri di performance: usa placeholder [dato]/[stima] e indica dove serve una misura. Massimo 5 bullet per slide. Le note del relatore devono tradurre i concetti tecnici per i non tecnici. Una sola decisione richiesta nella slide finale. ## Tono & stile Equilibrato, onesto sui trade-off, persuasivo per merito. Bullet telegrafici, note del relatore esplicative. ## Verbosità Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
ChatGPT
· OpenAI
## Ruolo Agisci come un Software Architect / Tech Lead che presenta decisioni architetturali a un pubblico misto di stakeholder tecnici e di business e sa rendere i trade-off comprensibili e difendibili. ## Obiettivo Genera un deck da 8 a 12 slide per presentare una decisione architetturale, con questa struttura: titolo e ask, contesto e trigger, requisiti e vincoli, criteri di valutazione, opzioni a confronto (slide matrice criteri x opzioni), raccomandazione con trade-off accettati, rischi e mitigazioni, impatto su team/costo/tempo, piano di adozione a fasi, decisione richiesta. Ogni slide con titolo, bullet e nota del relatore. ## Contesto Decisione da prendere: [tema architetturale]. Situazione attuale: [stato/dolore]. Opzioni candidate: [opzione A, B, C]. Requisiti funzionali: [req]. Requisiti non funzionali: [scalabilità, costo, latenza, ...]. Vincoli: [team, budget, tempo, competenze]. Pubblico: [tecnico/misto/leadership]. Raccomandazione preferita (se già nota): [opzione]. Ask finale: [decisione richiesta]. ## Formato output Un blocco per slide intestato 'SLIDE N — <etichetta>', con 'Titolo:', 'Bullet:' (max 5, brevi) e 'Note relatore:' (2-4 frasi). La slide di confronto deve essere una matrice criteri (righe) x opzioni (colonne) con valutazione sintetica per cella. La slide raccomandazione deve esplicitare il trade-off accettato. ## Vincoli & regole Confronta sempre almeno 2 opzioni più lo status quo. Non presentare la raccomandazione come ovvia: rendi visibili i trade-off e ciò a cui si rinuncia. Non inventare benchmark, costi o numeri di performance: usa placeholder [dato]/[stima] e indica dove serve una misura. Massimo 5 bullet per slide. Le note del relatore devono tradurre i concetti tecnici per i non tecnici. Una sola decisione richiesta nella slide finale. ## Tono & stile Equilibrato, onesto sui trade-off, persuasivo per merito. Bullet telegrafici, note del relatore esplicative. ## Verbosità Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
Perplexity
· Perplexity
Genera un deck da 8 a 12 slide per presentare una decisione architetturale, con questa struttura: titolo e ask, contesto e trigger, requisiti e vincoli, criteri di valutazione, opzioni a confronto (slide matrice criteri x opzioni), raccomandazione con trade-off accettati, rischi e mitigazioni, impatto su team/costo/tempo, piano di adozione a fasi, decisione richiesta. Ogni slide con titolo, bullet e nota del relatore. Ruolo: Agisci come un Software Architect / Tech Lead che presenta decisioni architetturali a un pubblico misto di stakeholder tecnici e di business e sa rendere i trade-off comprensibili e difendibili. Contesto: Decisione da prendere: [tema architetturale]. Situazione attuale: [stato/dolore]. Opzioni candidate: [opzione A, B, C]. Requisiti funzionali: [req]. Requisiti non funzionali: [scalabilità, costo, latenza, ...]. Vincoli: [team, budget, tempo, competenze]. Pubblico: [tecnico/misto/leadership]. Raccomandazione preferita (se già nota): [opzione]. Ask finale: [decisione richiesta]. Formato output: Un blocco per slide intestato 'SLIDE N — <etichetta>', con 'Titolo:', 'Bullet:' (max 5, brevi) e 'Note relatore:' (2-4 frasi). La slide di confronto deve essere una matrice criteri (righe) x opzioni (colonne) con valutazione sintetica per cella. La slide raccomandazione deve esplicitare il trade-off accettato. Vincoli & regole: Confronta sempre almeno 2 opzioni più lo status quo. Non presentare la raccomandazione come ovvia: rendi visibili i trade-off e ciò a cui si rinuncia. Non inventare benchmark, costi o numeri di performance: usa placeholder [dato]/[stima] e indica dove serve una misura. Massimo 5 bullet per slide. Le note del relatore devono tradurre i concetti tecnici per i non tecnici. Una sola decisione richiesta nella slide finale. Tono & stile: Equilibrato, onesto sui trade-off, persuasivo per merito. Bullet telegrafici, note del relatore esplicative.
Esempio di output
SLIDE 1 — Titolo Titolo: Decisione architetturale: [tema] Bullet: - [nome, ruolo] · [data] - Obiettivo: decidere su [scelta] Note relatore: Inquadra che oggi serve una decisione, non solo una discussione. Dichiara l'ask fin da subito. SLIDE 2 — Contesto Titolo: Perché ne parliamo ora Bullet: - Situazione attuale: [stato] - Cosa ci blocca: [vincolo/dolore] Note relatore: Spiega il trigger in modo che anche i non tecnici capiscano la posta in gioco. SLIDE 3 — Requisiti e vincoli Titolo: Cosa deve soddisfare la soluzione Bullet: - Funzionali: [req] - Non funzionali: [scalabilità, costo, ...] - Vincoli: [team, tempo, budget] Note relatore: Questi criteri guideranno il confronto: anticipali ora. SLIDE 5 — Opzioni a confronto Titolo: Le alternative sul tavolo Bullet (matrice): - Criteri (righe): Costo · Complessità · Scalabilità · Time-to-market · Rischio - Opzioni (colonne): A · B · C Note relatore: Cammina la matrice per criterio, non per opzione. Evidenzia i trade-off, non vendere ancora. SLIDE 7 — Raccomandazione Titolo: Cosa proponiamo e perché Bullet: - Scegliamo [opzione] - Perché: [motivo principale legato ai criteri] - Cosa accettiamo in cambio: [trade-off] Note relatore: Sii esplicito sul prezzo della scelta: aumenta la fiducia. SLIDE 9 — Piano di adozione Titolo: Come ci arriviamo Bullet: - Fase 1: [spike/POC] - Fase 2: [migrazione incrementale] - Fase 3: [dismissione legacy] Note relatore: Mostra che il rischio è gestito per fasi reversibili. SLIDE 10 — Decisione richiesta Titolo: Cosa chiediamo oggi Bullet: - Approvazione di [opzione] - Prossimo passo: [azione, owner, data] Note relatore: Chiudi chiedendo una decisione esplicita.
Domande frequenti
In cosa differisce da un ADR scritto?
Un ADR è un documento da leggere; questo è un deck da presentare. Riprende la stessa logica (contesto, opzioni, decisione, conseguenze) ma la trasforma in slide con un narrativo orale e note del relatore, pensate per ottenere una decisione in riunione, anche da stakeholder non tecnici.
Come confronta le opzioni?
Con una slide a matrice che mette le opzioni sulle colonne e i criteri (costo, complessità, scalabilità, time-to-market, rischio) sulle righe, più una valutazione sintetica per cella. Questo rende il trade-off visibile e la raccomandazione difendibile, invece di una scelta presentata come ovvia.
Include il piano di adozione?
Sì. Dopo la raccomandazione c'è una slide con le fasi di adozione (es. spike, migrazione incrementale, dismissione del vecchio), i rischi principali con mitigazione e la richiesta di decisione finale agli stakeholder.
Vuoi un prompt su misura?
Costruiscine uno in poche domande — e adattalo a ogni modello.