La decisione, prima delle opzioni
Un progetto parte da una lista di schermate. Durante lo sviluppo emergono ruoli, eccezioni e integrazioni che cambiano il comportamento di quelle schermate. Il verdetto da produrre è delimitato: «Quali informazioni riducono ambiguità senza scrivere un capitolato infinito?»
Converte richieste di interfaccia in esempi, controesempi e criteri di accettazione. Il punto di partenza è delimitare un caso, indicare chi ne risponde e dichiarare quale evidenza farebbe cambiare idea; il controllo associato riguarda «regole, eccezioni e autorizzazioni». Senza questa soglia ogni feedback tende ad allargare il progetto, mai a chiuderne un’ipotesi; nel perimetro descritto conta «scrivere scenari end to end».
Le soglie che rendono la scelta verificabile
Quattro verifiche separano una preferenza da una decisione difendibile. Il riferimento tecnico è «Example mapping, domain rule, permission boundary e acceptance test»: impedisce di giudicare soltanto l’interfaccia o la prima impressione.
Utente e risultato di ogni flusso
La risposta può cambiare il perimetro. Sul criterio «utente e risultato di ogni flusso», l’owner confronta l’evidenza «dati in ingresso e fonte» con il controesempio «specificare solo l’interfaccia» e decide se l’opzione resta aperta.
Dati in ingresso e fonte
Questo dato decide quale alternativa resta aperta. Sul criterio «dati in ingresso e fonte», l’owner confronta l’evidenza «regole, eccezioni e autorizzazioni» con il controesempio «parole come semplice o veloce senza criterio» e decide se l’opzione resta aperta.
Regole, eccezioni e autorizzazioni
È una soglia di scelta. Sul criterio «regole, eccezioni e autorizzazioni», l’owner confronta l’evidenza «criterio osservabile di accettazione» con il controesempio «eccezioni rinviate a dopo» e decide se l’opzione resta aperta.
Criterio osservabile di accettazione
Qui si separano vincolo e preferenza. Sul criterio «criterio osservabile di accettazione», l’owner confronta l’evidenza «utente e risultato di ogni flusso» con il controesempio «approvazione senza owner» e decide se l’opzione resta aperta.
Il caso da portare al tavolo
Caso isolato: «regole, eccezioni e autorizzazioni». Operazione osservata: «prioritizzare il vincolo principale». Deviazione forzata: «approvazione senza owner».
Verdetto richiesto: «Quali informazioni riducono ambiguità senza scrivere un capitolato infinito?» Il no resta valido se «approvazione senza owner» supera l’evidenza disponibile. Perimetro della prova: «descrivere flussi, dati, vincoli e accettazione».
Controprova: «utente e risultato di ogni flusso». Arresto: «parole come semplice o veloce senza criterio». Passo ammesso dopo il recupero: «prototipare decisioni incerte». Verbale finale: «Quali informazioni riducono ambiguità senza scrivere un capitolato infinito?»
Differenza decisiva: «Converte richieste di interfaccia in esempi, controesempi e criteri di accettazione». Regola di chiusura: «Lo sviluppo può stimare e testare quando le regole hanno esempi; il mockup da solo non contiene il contratto del comportamento».
Tre esiti sono tutti legittimi
Il primo esito è mantenere il sistema attuale e correggere una regola del processo; il controesempio viene cercato in «utente e risultato di ogni flusso». Il secondo è configurare o integrare ciò che già esiste. Il terzo è costruire una capacità nuova perché il vincolo rimane scoperto; la decisione resta collegata a «modellare dati e responsabilità». L’ordine conta: ogni livello aggiunge costi di gestione, test e continuità; qui la prova concreta è «regole, eccezioni e autorizzazioni».
Per descrivere flussi, dati, vincoli e accettazione, l’alternativa più piccola deve essere scartata con una prova, non per gusto. Anche un rinvio è informativo se specifica la condizione che manca e chi può crearla; l’evidenza da conservare è «eccezioni rinviate a dopo».
Un test che può dire anche no
Il test deve attraversare un caso completo e lasciare un output revisionabile; il caso operativo si verifica con «prototipare decisioni incerte». I passaggi seguenti trasformano la tesi in una verifica limitata, evitando che il pilot diventi un progetto senza confini; il controllo associato riguarda «specificare solo l’interfaccia».
- 1
Scrivere scenari end to end
«Scrivere scenari end to end» risponde a «Quali informazioni riducono ambiguità senza scrivere un capitolato infinito» con un caso recente. L’output documenta «utente e risultato di ogni flusso» e usa «specificare solo l’interfaccia» per decidere se procedere verso «prioritizzare il vincolo principale».
- 2
Prioritizzare il vincolo principale
«Prioritizzare il vincolo principale» risponde a «Quali informazioni riducono ambiguità senza scrivere un capitolato infinito» con un caso recente. L’output documenta «dati in ingresso e fonte» e usa «parole come semplice o veloce senza criterio» per decidere se procedere verso «modellare dati e responsabilità».
- 3
Modellare dati e responsabilità
«Modellare dati e responsabilità» risponde a «Quali informazioni riducono ambiguità senza scrivere un capitolato infinito» con un caso recente. L’output documenta «regole, eccezioni e autorizzazioni» e usa «eccezioni rinviate a dopo» per decidere se procedere verso «prototipare decisioni incerte».
- 4
Prototipare decisioni incerte
«Prototipare decisioni incerte» risponde a «Quali informazioni riducono ambiguità senza scrivere un capitolato infinito» con un caso recente. L’output documenta «criterio osservabile di accettazione» e usa «approvazione senza owner» per decidere se procedere verso «trasformare requisiti in test».
- 5
Trasformare requisiti in test
«Trasformare requisiti in test» risponde a «Quali informazioni riducono ambiguità senza scrivere un capitolato infinito» con un caso recente. L’output documenta «utente e risultato di ogni flusso» e usa «specificare solo l’interfaccia» per decidere se procedere verso «scrivere scenari end to end».
I segnali che cambiano il verdetto
Una decisione robusta include i casi che la renderebbero sbagliata. Questi non sono dettagli da demandare alla manutenzione: definiscono il costo reale dell’opzione; nel perimetro descritto conta «approvazione senza owner».
Specificare solo l’interfaccia
Rischio nominato: «specificare solo l’interfaccia». Perimetro operativo: «descrivere flussi, dati, vincoli e accettazione». Segnale osservato: «regole, eccezioni e autorizzazioni». Recupero ammesso: «scrivere scenari end to end». Checkpoint finale: «regole, eccezioni e autorizzazioni».
Parole come semplice o veloce senza criterio
Rischio nominato: «parole come semplice o veloce senza criterio». Perimetro operativo: «descrivere flussi, dati, vincoli e accettazione». Segnale osservato: «criterio osservabile di accettazione». Recupero ammesso: «prioritizzare il vincolo principale». Checkpoint finale: «criterio osservabile di accettazione».
Eccezioni rinviate a dopo
Rischio nominato: «eccezioni rinviate a dopo». Perimetro operativo: «descrivere flussi, dati, vincoli e accettazione». Segnale osservato: «utente e risultato di ogni flusso». Recupero ammesso: «modellare dati e responsabilità». Checkpoint finale: «utente e risultato di ogni flusso».
Approvazione senza owner
Rischio nominato: «approvazione senza owner». Perimetro operativo: «descrivere flussi, dati, vincoli e accettazione». Segnale osservato: «dati in ingresso e fonte». Recupero ammesso: «prototipare decisioni incerte». Checkpoint finale: «dati in ingresso e fonte».
Il criterio finale
Lo sviluppo può stimare e testare quando le regole hanno esempi; il mockup da solo non contiene il contratto del comportamento. Nel caso in esame, l’intervento deve rendere più semplice ricostruire stato, dati usati e responsabilità; se migliora soltanto la superficie, il vincolo resta; il controesempio viene cercato in «utente e risultato di ogni flusso».
Lo sviluppo può stimare e testare quando le regole hanno esempi; il mockup da solo non contiene il contratto del comportamento. La decisione si chiude con «scrivere scenari end to end»: «criterio osservabile di accettazione» deve restare leggibile anche nel controesempio «specificare solo l’interfaccia».
Contesto e limiti
Non vengono attribuiti risultati a clienti SYNAPT. Lo scenario serve a distinguere regole, assunzioni e decisioni. Il risultato utile è una decisione spiegabile e reversibile.
Prossimo passo
Hai un processo che non entra negli strumenti standard?
Porta il vincolo operativo, i sistemi coinvolti e il risultato che vorresti ottenere. Partiamo da lì.