Dissentire da una richiesta tecnica senza perdere il problema del cliente

Quando una richiesta tecnica mi convince poco, il primo lavoro è capire quale problema dovrebbe risolvere. Contestare subito la soluzione può far perdere un’informazione importante: il cliente sta spesso cercando di eliminare un passaggio che, dal suo punto di vista, rallenta il lavoro.

Questo non significa accettare qualunque proposta. Significa rendere il dissenso utile, collegandolo a effetti verificabili e a un’alternativa che rispetti l’obiettivo.

Un esempio: pubblicare senza un passaggio di approvazione

Consideriamo un caso illustrativo, non un episodio attribuito a un cliente: una redazione chiede di permettere ad alcuni autori di pubblicare direttamente. Il problema dichiarato è l’attesa della revisione.

La pubblicazione diretta non è necessariamente una cattiva scelta. Può essere coerente con ruoli e responsabilità della redazione. Prima di valutarla, chiederei quali contenuti coinvolge, chi risponde della pubblicazione e quali verifiche restano necessarie.

Il punto critico potrebbe essere un’approvazione duplicata, la mancanza di un sostituto o una notifica che non arriva. Aggiungere un privilegio permanente per correggere un difetto di notifica risolverebbe il problema nel posto sbagliato.

Separare fatti, ipotesi e preferenze

“Questa funzione è pericolosa” dice poco. È più utile spiegare che consentirebbe a un ruolo di rendere pubblico un contenuto prima del controllo previsto, e mostrare in quali circostanze ciò può accadere.

Se non conosciamo frequenza o impatto, li tratterei come aspetti da verificare. Non userei una previsione di danno come se fosse un incidente già osservato.

Anche le preferenze tecniche vanno riconosciute. Una soluzione può non piacermi ed essere comunque adeguata al contesto; una struttura elegante può costare più del beneficio atteso per chi la usa.

Proporre alternative confrontabili

Nell’esempio editoriale, valuterei approvazione differenziata per tipo di contenuto, delega a un secondo revisore oppure pubblicazione diretta per ruoli definiti, con tracciamento e possibilità di correzione.

Ogni alternativa deve indicare cosa semplifica e quale responsabilità introduce. Eviterei di presentare una lista in cui la mia opzione è descritta bene e le altre come caricature.

Una prova circoscritta può chiarire se la causa del ritardo è davvero il passaggio contestato. Il criterio di riuscita dovrebbe essere un flusso più efficace senza perdere i controlli che la redazione considera necessari.

Registrare la decisione e i suoi confini

Una volta scelto il percorso, documenterei chi può fare cosa e come verificare il comportamento. Le autorizzazioni devono essere applicate nel punto corretto del sistema, non soltanto nascoste nell’interfaccia.

Se resta un rischio che non possiamo sostenere, va detto esplicitamente. Se invece il cliente sceglie consapevolmente un’opzione valida diversa dalla mia preferenza, il lavoro è implementarla bene.

Per me l’onestà professionale si vede qui: spiegare ciò che sappiamo, ciò che manca e quali conseguenze hanno le scelte. Non serve costruire un racconto in cui il cliente sbaglia e torna a darci ragione mesi dopo.