La scelta e le sue ragioni
Che cosa rende una scelta comprensibile a chi arriva dopo
Scrivere “il sistema prepara soltanto bozze” descrive un comportamento. Aggiungere “perché alcune risposte impegnano il cliente e richiedono la decisione di un responsabile” rende comprensibile la scelta. Precisare “l'invio automatico non è stato provato né autorizzato” impedisce di scambiare una possibilità futura per una funzione già consegnata.
Queste informazioni servono a persone diverse. Chi utilizza il sistema capisce quando fermarsi; chi lo mantiene riconosce quale modifica cambierebbe il perimetro; chi commissiona il lavoro distingue un difetto da una nuova richiesta. Non occorre consegnare ogni conversazione del progetto. Occorre conservare i legami senza i quali una decisione diventerebbe arbitraria.
Caso illustrativo
Un esempio: rispondere da documentazione di prodotto
Consideriamo un caso interamente illustrativo, non un cliente MAIOS o un risultato misurato. Un team vuole preparare risposte tecniche partendo da manuali e note di versione. La soluzione proposta produce una bozza con i documenti utilizzati; una persona verifica e decide se inviarla.
Nella prima prova compare una risposta corretta per la versione precedente del prodotto, ma sbagliata per quella richiesta. Sostituire quella frase risolve il caso. Capire che mancava la relazione fra domanda e versione suggerisce invece una correzione riutilizzabile: identificare la versione prima di scegliere le fonti e chiedere chiarimento quando l'informazione manca.
La differenza conta alla consegna. Il nuovo manutentore non riceve soltanto una risposta corretta: riceve il motivo per cui la selezione delle fonti deve funzionare in quel modo. La correzione può così partecipare al caso successivo, senza diventare una regola indiscriminata per ogni altro progetto.
Oggetto operativo
Una nota di consegna già compilata
Puoi partire dalla nota seguente e adattarla al tuo lavoro. I valori appartengono all'esempio, non costituiscono requisiti universali.
Risultato richiesto
Aiutare il supporto a preparare risposte coerenti con la versione del prodotto indicata nella richiesta.
Decisione e ragione
Produrre una bozza con fonti; una persona decide l'invio perché deve valutare l'impegno assunto nella risposta.
Fonti e dipendenze
Manuali e note approvati dal responsabile prodotto, associati alla loro versione. Se la versione manca, chiedere chiarimento.
Correzione acquisita
Una risposta usava documentazione superata: la scelta delle fonti deve seguire la versione della richiesta, non soltanto la somiglianza delle parole.
Stato e confine
La risposta dell'esempio è stata corretta; una verifica su richieste nuove resta da effettuare. Invio e modifiche agli account sono esclusi.
Condizione che riapre la scelta
Cambiano le fonti, il risultato richiesto o le azioni che il sistema dovrebbe compiere. Identificare quali decisioni dipendono dal cambiamento.
Continuazione
Provare una richiesta relativa a un'altra versione; osservare quali fonti vengono selezionate e come viene trattata un'ambiguità.
Una prova da eseguire
Consegna la nota a un collega
Prova a consegnare questa nota a un collega insieme ai materiali necessari. Chiedigli di spiegare la scelta e di affrontare una variazione del caso senza usare la stessa risposta. Se deve ancora ricostruire con te ogni passaggio, hai individuato quale relazione manca nella consegna. Questa è una prova da eseguire, non un esito già dimostrato dall'esempio.
Il presente cambia
Riprendere il lavoro non significa ripetere la vecchia soluzione
Se cambia soltanto la persona, può bastare recuperare ragioni e fonti della scelta. Se cambia una fonte, occorre capire quali conclusioni dipendevano da essa. Se il cliente chiede un risultato diverso, può essere necessario riformulare il problema e coinvolgere altre competenze.
Nell'esempio, “mostrare meglio la versione” e “inviare automaticamente le risposte” non sono due ritocchi equivalenti. La prima richiesta può riguardare la comprensione dell'output. La seconda cambia gli effetti del sistema e le responsabilità. Trattarle entrambe come piccoli cambiamenti di interfaccia nasconderebbe il lavoro realmente necessario.
Questo modo di riprendere un progetto mantiene utilizzabile ciò che si è imparato, senza obbligare ogni situazione nuova dentro la decisione precedente.
Apprendere dal lavoro
Dalla correzione del caso alla competenza
Una correzione diventa utile oltre il singolo output quando cambia il modo di affrontare casi pertinenti. Per conservarla, annota che cosa l'ha resa necessaria, quale criterio cambia e dove quel criterio vale. Se correggi un'informazione isolata, può bastare aggiornare la fonte: non ogni errore richiede una nuova procedura.
Anche l'assenza di un miglioramento è informativa. Se la nota è corretta ma chi subentra continua a non capire, il problema potrebbe essere nella spiegazione, negli accessi o nella conoscenza del lavoro. Aggiungere altra documentazione senza distinguere queste possibilità può lasciare intatto il problema.
Da dove nasce questa guida
Il collegamento con il lavoro da cui nasce MAIOS
Nel kernel attraverso cui sviluppiamo MAIOS, contesto, competenze, risultato e correzione sono collegati: ciò che emerge dal lavoro può cambiare il modo in cui il sistema affronta il passaggio seguente. Il reingresso recupera il senso del percorso e lo incontra nel contesto presente; non consiste soltanto nel richiamare un testo precedente.
È questa relazione che abbiamo usato per comprendere il passaggio di consegne. La nota della guida ne rende utilizzabile una parte anche in un team che lavora senza AI. Non è, da sola, un kernel, e non dimostra che un pacchetto installato imparerà automaticamente o che la consegna avrà successo.
Per approfondire la distinta incarnazione di prodotto puoi consultare MAIOS Project Kernel. Qui il risultato è più circoscritto: poter continuare un lavoro comprendendo quali ragioni conservare, quali premesse riesaminare e quale capacità manca.
Domande frequenti
Domande sul passaggio di consegne
Che cosa aggiungere al codice e alle istruzioni?
Le ragioni delle scelte, le fonti da cui dipendono, ciò che è stato verificato e le condizioni che richiedono di riesaminare il lavoro. La nota compilata nella guida offre un esempio da adattare.
La nota di consegna dimostra che il sistema funziona?
No. Conserva il ragionamento, ma non sostituisce le prove. Nell'esempio la verifica su richieste nuove resta da effettuare; la prova con un collega è proposta, non già osservata.
Ogni errore deve diventare una nuova regola?
No. Un errore isolato può richiedere soltanto una correzione della fonte. Un criterio riutilizzabile deve conservare il motivo della correzione e l'ambito in cui è pertinente.