Inizializzo l’ __init__ method della classe Tk  con la funzione built-in super() 

example2

Ingegneri e sviluppatori dovrebbero evitare il gergo tecnico task-oriented quando comunicano con il business. Dovrebbero invece sforzarsi di esprimere concetti anche complessi previlegiando sempre gli impatti sul business e sul cliente.

Il problema

Capita che gli sviluppatori, specie se con poca seniority, cerchino di comunicare con i product owner, i clienti, o in generale con il business utilizzando il gergo tecnico tipico del proprio dominio di expertise. Di solito il risultato della comunicazione tende ad essere se va bene mediocre, con frustrazione ed insoddisfazione per developer, business e cliente.

E non è solo un problema di flussi di comunicazione Business/Tech. Nuove tecnologie emergono costantemente e la comunicazione “tecnica” può risultare incomprensibile anche tra specialisti con skillset differenti. Ad esempio potresti essere un Java Dev Senior, e magari ti risulta incomprensibile se dico “Ho definito il CamelContext usando la sintassi XML custom, ma senza la definizione delle route” perchè non conosci Camel, che pure è un framework Java.

Ma torniamo alla comunicazione Business/Dev. I product owner dovrebbero avere la comprensione delle implicazioni di business delle tecnologie utilizzate, i dev dovrebbero invece essere in grado di comunicare chiaramente le ragioni e i relativi impatti di business delle loro attività giornaliere.

Gli sviluppatori affrontano e devono comunicare task difficili, con dati e processi complessi. L’attention span delle persone del business è sempre più breve, e la situazione è peggiorata ulteriormente con il lavoro a distanza. Quindi, in che modo i tecnici possono tradurre le loro attività in concetti brevi e comprensibili? Alcuni sviluppatori sono più inclini di altri a comunicare, ma quello che suggerisco qui è un semplice processo in due passaggi che può essere adottato da chiunque.

Ecco l’approccio.

  1. Conosci la tua Audience. Quali sono le attitudini, i bisogni e le aspettative della tua audience? A seconda della persona con cui parli, la tua comunicazione deve essere focalizzata con:
    • Un approccio diretto e deduttivo con cui comunichi immediatamente l’impatto di business (ed esempio, miglioriamo l’esperienza d’acquisto). Se serve, maggiori dettagli possono essere dati in seguito. Se il Business ha fiducia nelle competenze tecniche del team, questo è l’appproccio migliore.
    • Un approccio indiretto e induttivo. Si parte descrivendo il problema dal punto di vista tecnico (Non riusciamo a deployare su Nexus) e poi si descrivono gli step della soluzione. Questo approccio è corretto in presenza di un’audience tecnica, che condivide lo stesso skillset, ma è più rischioso davanti ad un’audience business.
  2. Un messaggio chiaro, conciso e focalizzato. Se parli al business, focus sull’impatto per il business (es. non possiamo testare il prodotto) piuttosto che sul problema tecnico (es. non riusciamo a deployare con Gradle).

Vediamo un esempio pratico con protagonisti fittizi. Marco, junior developer, Gianni, product owner, e Marcello il cliente. Il codice è adattato da Tkinter GUI Application Development Cookbook, di Alejandro Rodas de Paz.

Il planning meeting

Immaginiamo di essere al backlog refinement meeting di uno Scrum Team. Gianni, il nuovo Product Owner, ha un forte background di marketing, ma comprensione limitata della tecnologia.

Marco chiede di poter mettere una nuova storia “tecnica” nel backlog per rivedere la funzionalità dell’app “Ciao Marcello”. Il Product Owner Gianni è confuso: l’app esiste già e funziona bene: cliccando sul bottone “click me!” viene stampato a video il messaggio “Ciao Marcello” e il cliente è soddisfatto

Gianni chiede quindi quale sia il razionale della nuova richiesta del team. Ecco la risposta di Marco.

OK, la storia che vorrei fare per l’app “Ciao Marcello”. Vorrei definire una classe per wrappare le variabili globali, includendole in uno scope specifico. Sposto anche anche la command in un metodo specifico, e rimpiazzo l’import star con la sintassi “import …as” . Poi definirò una classe App come subclasse della Tk, referenziata sul namespace tk. Inizializzerò il metodo __init__ della Tk con la funzione super()..

Cosa c’è di sbagliato nella descrizione di Marco? Nulla, tranne il fatto che manca totlamente l’impatto di business delle attivbità descritte. Non è quindi chiara la ragione per cui Gianni dovrebbe dare priorità a una storia di cui non vede il valore. Il modo in cui i task sono descritti dice poco o nulla al product owner, così come al cliente. Gianni comincia a pensare che Marco abbia una sua agenda non del tutto allineata con gli obiettivi di Business.

Proviamo quindi a riscrivere la risposta di marco in termini più business oriented.

Task orientedBusiness oriented
Non è stato comunicato il contenuto di business della storia Voglio migliorare la qualità e la solidità dell’app, pur mantenendo le funzionalità esistenti.
1a. Vorrei definire una classe per wrappare le variabili globali, i1b. Miglioro la qualità e la modularità.
1c. Ti spiego il problema con le variabili globali. Ogni variabile aggiunge un poco di complessità, ma quelle globali l’aggiungono a tutta l’app, mentre quello locali aggiungono complessità solo dove vengono definite. Così la manutenzione sarà più semplice, e avremo meno errori.
2a. Includo le variabili globali in uno scope specifico. Sposto anche anche la command in un metodo specifico2b. Voglio evitare che cambiamenti futuri in una parte del codice creino problemi in altre parti del codice, e viceversa.
3a. rimpiazzo l’import star con la sintassi “import …as” . 3b. E’ una best practice per evitare errori per conflitti con altri moduli/funzioni
4a. Poi definirò una classe App come subclasse della Tk, referenziata sul namespace tk. Inizializzerò il metodo __init__ della Tk con la funzione super()4b. Voglio poter riutilizzare al meglio le funzioni che scrivo.

Gli impatti di business sono ora molto più chiari. Spiegando la storia in termini di valore, Marco ha convinto Gianni a dare priorità al refactoring della storia, che è stata poi affrontata nello sprint successivo. Nell’immagine il codice dell’app, rifattorizzato.

La comunicazione nel team è migliorata, il valore del’attività è chiaro, il cliente ha un’app di maggiore qualità. Ottimo lavoro!

Ho presentato qui un semplice approccio per strutturare argomenti tecniche. L’approccio può essere utilizzato anche da chi non sia sicuro delle proprie skill di comunicazione e porta in definitiva alla creazione di maggior valore per il cliente e per l’organizzazione.


Marcello is coaching and leading Agile Teams, supporting Transformation programs. He has multi-year experience as a Product Owner, Scrum Master and Agile Coach in e-commerce, IT, Marketing and Decision Support Systems in Media, Telco, Finance, Fashion industries.

Contact him on LinkedIn.