La decisione, prima delle opzioni
Un portale interno nasce da una lista di funzioni desiderate da reparti diversi. Il rischio maggiore, però, è capire se gli utenti adotteranno un nuovo passaggio di approvazione. Il verdetto da produrre è delimitato: «Qual è il perimetro minimo che permette di decidere se proseguire?»
Usa la decisione futura come filtro per includere o escludere ogni funzione. Il punto di partenza è delimitare un caso, indicare chi ne risponde e dichiarare quale evidenza farebbe cambiare idea; l’evidenza da conservare è «ipotesi più costosa o incerta». Senza questa soglia ogni feedback tende ad allargare il progetto, mai a chiuderne un’ipotesi; il caso operativo si verifica con «dato minimo necessario al flusso».
Che cosa deve essere vero per procedere
Quattro verifiche separano una preferenza da una decisione difendibile. Il riferimento tecnico è «Ipotesi critica, flusso end-to-end e criterio go/no-go»: impedisce di giudicare soltanto l’interfaccia o la prima impressione.
Ipotesi più costosa o incerta
Questo dato decide quale alternativa resta aperta. Sul criterio «ipotesi più costosa o incerta», l’owner confronta l’evidenza «utente e decisione da osservare» con il controesempio «chiamare MVP una release senza obiettivo» e decide se l’opzione resta aperta.
Utente e decisione da osservare
È una soglia di scelta. Sul criterio «utente e decisione da osservare», l’owner confronta l’evidenza «dato minimo necessario al flusso» con il controesempio «includere tutti i reparti nel primo ciclo» e decide se l’opzione resta aperta.
Dato minimo necessario al flusso
Qui si separano vincolo e preferenza. Sul criterio «dato minimo necessario al flusso», l’owner confronta l’evidenza «criterio concreto di stop o prosecuzione» con il controesempio «rimandare sicurezza e ownership del dato» e decide se l’opzione resta aperta.
Criterio concreto di stop o prosecuzione
La risposta può cambiare il perimetro. Sul criterio «criterio concreto di stop o prosecuzione», l’owner confronta l’evidenza «ipotesi più costosa o incerta» con il controesempio «trasformare feedback in scope illimitato» e decide se l’opzione resta aperta.
La soglia applicata
Caso isolato: «criterio concreto di stop o prosecuzione». Operazione osservata: «raccogliere evidenze prima della roadmap». Deviazione forzata: «chiamare MVP una release senza obiettivo».
Verdetto richiesto: «Qual è il perimetro minimo che permette di decidere se proseguire?» Il no resta valido se «chiamare MVP una release senza obiettivo» supera l’evidenza disponibile. Perimetro della prova: «trattare l’MVP come verifica di un rischio e non come prodotto incompleto».
Controprova: «utente e decisione da osservare». Arresto: «rimandare sicurezza e ownership del dato». Passo ammesso dopo il recupero: «scegliere un flusso end to end». Verbale finale: «Qual è il perimetro minimo che permette di decidere se proseguire?»
Differenza decisiva: «Usa la decisione futura come filtro per includere o escludere ogni funzione». Regola di chiusura: «Il perimetro minimo non è quello che costa meno, ma quello che produce evidenze sufficienti per scegliere il passo successivo».
Tre esiti sono tutti legittimi
Il primo esito è mantenere il sistema attuale e correggere una regola del processo; il controllo associato riguarda «trasformare feedback in scope illimitato». Il secondo è configurare o integrare ciò che già esiste. Il terzo è costruire una capacità nuova perché il vincolo rimane scoperto; nel perimetro descritto conta «formulare una domanda verificabile». L’ordine conta: ogni livello aggiunge costi di gestione, test e continuità; il controesempio viene cercato in «ipotesi più costosa o incerta».
Per trattare l’MVP come verifica di un rischio e non come prodotto incompleto, 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; la decisione resta collegata a «chiamare MVP una release senza obiettivo».
Un test che può dire anche no
Il test deve attraversare un caso completo e lasciare un output revisionabile; qui la prova concreta è «scegliere un flusso end to end». I passaggi seguenti trasformano la tesi in una verifica limitata, evitando che il pilot diventi un progetto senza confini; l’evidenza da conservare è «definire criteri di accettazione».
- 1
Formulare una domanda verificabile
«Formulare una domanda verificabile» risponde a «Qual è il perimetro minimo che permette di decidere se proseguire» con un caso recente. L’output documenta «ipotesi più costosa o incerta» e usa «chiamare MVP una release senza obiettivo» per decidere se procedere verso «scegliere un flusso end to end».
- 2
Scegliere un flusso end to end
«Scegliere un flusso end to end» risponde a «Qual è il perimetro minimo che permette di decidere se proseguire» con un caso recente. L’output documenta «utente e decisione da osservare» e usa «includere tutti i reparti nel primo ciclo» per decidere se procedere verso «escludere funzioni che non cambiano la decisione».
- 3
Escludere funzioni che non cambiano la decisione
«Escludere funzioni che non cambiano la decisione» risponde a «Qual è il perimetro minimo che permette di decidere se proseguire» con un caso recente. L’output documenta «dato minimo necessario al flusso» e usa «rimandare sicurezza e ownership del dato» per decidere se procedere verso «definire criteri di accettazione».
- 4
Definire criteri di accettazione
«Definire criteri di accettazione» risponde a «Qual è il perimetro minimo che permette di decidere se proseguire» con un caso recente. L’output documenta «criterio concreto di stop o prosecuzione» e usa «trasformare feedback in scope illimitato» per decidere se procedere verso «raccogliere evidenze prima della roadmap».
- 5
Raccogliere evidenze prima della roadmap
«Raccogliere evidenze prima della roadmap» risponde a «Qual è il perimetro minimo che permette di decidere se proseguire» con un caso recente. L’output documenta «ipotesi più costosa o incerta» e usa «chiamare MVP una release senza obiettivo» per decidere se procedere verso «formulare una domanda verificabile».
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; il caso operativo si verifica con «includere tutti i reparti nel primo ciclo».
Chiamare MVP una release senza obiettivo
Rischio nominato: «chiamare MVP una release senza obiettivo». Perimetro operativo: «trattare l’MVP come verifica di un rischio e non come prodotto incompleto». Segnale osservato: «criterio concreto di stop o prosecuzione». Recupero ammesso: «definire criteri di accettazione». Checkpoint finale: «criterio concreto di stop o prosecuzione».
Includere tutti i reparti nel primo ciclo
Rischio nominato: «includere tutti i reparti nel primo ciclo». Perimetro operativo: «trattare l’MVP come verifica di un rischio e non come prodotto incompleto». Segnale osservato: «ipotesi più costosa o incerta». Recupero ammesso: «raccogliere evidenze prima della roadmap». Checkpoint finale: «ipotesi più costosa o incerta».
Rimandare sicurezza e ownership del dato
Rischio nominato: «rimandare sicurezza e ownership del dato». Perimetro operativo: «trattare l’MVP come verifica di un rischio e non come prodotto incompleto». Segnale osservato: «utente e decisione da osservare». Recupero ammesso: «formulare una domanda verificabile». Checkpoint finale: «utente e decisione da osservare».
Trasformare feedback in scope illimitato
Rischio nominato: «trasformare feedback in scope illimitato». Perimetro operativo: «trattare l’MVP come verifica di un rischio e non come prodotto incompleto». Segnale osservato: «dato minimo necessario al flusso». Recupero ammesso: «scegliere un flusso end to end». Checkpoint finale: «dato minimo necessario al flusso».
Il criterio finale
Il perimetro minimo non è quello che costa meno, ma quello che produce evidenze sufficienti per scegliere il passo successivo. 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 controllo associato riguarda «trasformare feedback in scope illimitato».
Il perimetro minimo non è quello che costa meno, ma quello che produce evidenze sufficienti per scegliere il passo successivo. La decisione si chiude con «definire criteri di accettazione»: «ipotesi più costosa o incerta» deve restare leggibile anche nel controesempio «includere tutti i reparti nel primo ciclo».
Contesto e limiti
Useremo un esempio fittizio per rendere verificabile la domanda «Qual è il perimetro minimo che permette di decidere se proseguire?» Le alternative vengono confrontate sullo stesso caso.
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ì.