Tesi

La memoria decisionale di un'azienda dipende da ciò che il suo registro rifiuta di accogliere

Info

Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.

Angolo

Un registro delle decisioni di prodotto trae la sua forza da tre rifiuti, e ciascuno protegge da un modo distinto in cui la documentazione aziendale di solito fallisce. Rifiuta ciò che dice cosa costruire, perché una regola scesa al livello della funzionalità smette di permettere di ricavare decisioni sui casi che nessuno aveva previsto. Rifiuta ciò che non evita alcuna ridiscussione futura, perché un registro si consulta a memoria e oltre una quindicina di voci nessuno lo consulta più. Rifiuta di essere corretto, perché una decisione è una coppia scelta-contesto e riscrivere cancella il contesto credendo di sostituire solo la scelta. Ciò che l'azienda ottiene in cambio di questi tre rifiuti non è un risparmio di tempo ma una risposta unica là dove quattro funzioni ne applicavano quattro: il supporto, le partnership, il prodotto e i commerciali smettono di decidere ciascuno secondo la propria razionalità. E il prezzo di questo strumento si legge per sottrazione — le spiegazioni ripetute cinquanta volte, le scelte riaperte con ogni grande prospect, la dipendenza dalla memoria di chi era nella riunione.

Sintesi

Prese separatamente, queste idee somigliano a consigli di scrittura. Messe insieme, descrivono uno strumento le cui proprietà utili sono tutte restrizioni.

Il punto di partenza è una diagnosi, non un metodo. Un'azienda di prodotto sa cosa ha fatto e non sempre sa più perché: la questione della controversia tra cliente e fornitore in un marketplace ritorna nel comitato di roadmap, con i commerciali, nel supporto, nelle specifiche. Questa ricorrenza non è una serie di casi trattati male, è il segno di una regola assente al livello in cui si applicherebbe. Ciò che l'assenza costa non è anzitutto tempo di riunione: è che ogni funzione decide secondo la propria logica, e che quattro decisioni incompatibili si applicano simultaneamente alle politiche sulle controversie, ai messaggi del supporto e alle priorità di prodotto.

Viene poi ciò che fa funzionare il rimedio, e sono tre limiti. Il livello, anzitutto: «in questo tipo di situazione, ecco la regola» funziona perché la frase non si impegna su alcuna funzionalità — una regola che dice cosa costruire è una specifica travestita, meno precisa di una specifica vera. Poi la rarità, che non è una disciplina ma la condizione d'uso: quindici voci stanno nella testa di un Product Manager e di un direttore commerciale, cinquanta a trimestre non stanno da nessuna parte. Infine l'immutabilità: la regola sulle lingue supportate, sostituita due anni dopo perché il costo di traduzione è crollato, non si corregge — la nuova decisione si scrive accanto, e la vecchia continua a spiegare perché allora il rifiuto era ragionevole.

Un quarto elemento impedisce a questi limiti di trasformarsi in rigidità. Scrivere cosa dovrebbe succedere perché la decisione cambi chiude il tema oggi senza chiuderlo per sempre, e sposta la riapertura dai rapporti di forza a un fatto da accertare: un prospect italiano che insiste non apre la porta, un cambiamento dimostrato del costo di traduzione sì.

Resta la questione della collocazione, che decide se tutto il resto serve. Una regola trasversale scritta in una card Jira è esatta e introvabile per chi riguarda; eredita il pubblico del ticket e la sua durata di vita, cioè nulla. Niente segnala questa scomparsa, perché la decisione non è scomparsa.

Ciò che l'insieme mostra, e che nessuna di queste idee dice da sola: la memoria di un'organizzazione non si costruisce scrivendo di più. Si costruisce con uno strumento in cui ogni regola è un'esclusione, e che si giudica dalle discussioni che fa sparire — un bilancio strutturalmente sfavorevole alla lettura, perché il costo di scrittura è immediato e visibile mentre le ridiscussioni evitate non lasciano traccia.

Tensioni / contraddizioni

La prima tensione riguarda la portata del rimedio. Un registro scritto produce una risposta unica solo se i team lo conoscono e lo applicano; niente nello strumento lo assicura, e una regola ignorata lascia intatte le letture divergenti aggiungendo un documento che afferma il contrario.

Seconda tensione, tra due idee riunite qui. Una sostiene che un artefatto vecchio descrive un contesto scomparso e inganna chi lo riprende; l'altra sostiene che una vecchia decisione conservata con il suo contesto resta utile anni dopo. La differenza qui mantenuta è che il primo contiene un'intenzione e la seconda un motivo datato — ma il confine è più sottile di quanto sembri non appena una decisione contiene condizioni di rivalutazione, che sono un'intenzione.

Terzo punto, lasciato aperto: la soglia di rarità è posta per esperienza e non per misura. Nessuna osservazione dice a partire da quante voci un registro smette di essere consultato, e il numero proposto varia con la dimensione dell'organizzazione senza che si sappia secondo quale legge.

Domande

  • Cosa fa sì che, in un'organizzazione, un registro delle decisioni venga davvero consultato nel momento in cui la domanda si pone, invece di essere ripescato a cose fatte per giustificare ciò che è già stato risposto?
  • Quali decisioni strutturanti sono già scritte nei ticket e nelle specifiche di un team, e con quale mezzo individuarle?
  • A chi spetta scrivere una regola trasversale quando riguarda in egual misura il supporto, i commerciali e il prodotto, e nessuno dei tre ha mandato sugli altri due?