Lo sviluppo del software è una attività collaborativa, non ricordo più dove ho letto questa frase, quindi mi dispiace di non saper citare la fonte, e, purtroppo non e mia.
L’ho letta molti anni fa, quando ancora sviluppavo software e forse perché ero una autodidatta e quindi mi approcciavo a mio modo alla programmazione, mi rimase impressa, tanto da ricordarla ancora adesso.
L’idea, forse un po’ romantica, che mi ero fatta entrando nel modo della programmazione era quella di poter risolvere problemi, io, la mia competenza, una tastiera ed una IDE.
Quello che poi ho imparato è che non si è mai da soli. E per fortuna, dal mio punto di vista!
Lo sviluppo del software è una attività collaborativa.
Perché molto spesso si lavora in un team, perché il team ha degli stakeholders che lavorano allo stesso prodotto/progetto/programma, perché, per i più fortunati, c’è anche la possibilità di parlare con il cliente finale!
Non si è mai da soli.
E per alcune persone questo è un bene, per altre è un qualcosa con la quale fare pace.
Questo articolo è per quelle persone che vorrebbero farci pace.
Collaborare è comunicare
Capire i requisiti
Collaborare può avere più accezioni ma presuppone comunque una forma di comunicazione, scritta o orale: non importa se ricevi il documento dei requisiti o se fai un workshop con tutti gli stakeholder in una stanza per una settimana fino a tirare fuori un prototipo.
In tutti e due i casi stai comunicando.
Nel primo, tramite un documento che, nella mia esperienza è il metodo meno efficace, nel secondo lavorando a stretto giro e scambiando feedback nel modo più ravvicinato e veloce possibile.
Quando sarà finito?
Qui tocco un tema tanto caro quanto spinoso: le stime.
Ed anche per questo tema si possono fare in diversi modi, potreste saltarle a piè pari, perché qualcuno le ha già fatte per te e allora forse la comunicazione che dovrete mettere in campo sarà di un altro tipo… oppure potresti doverle comunicare.
E magari anche attivare una sana forma di contrattazione, che secondo me altro non è che una forma più sofisticata di comunicazione, con tecniche specifiche.
Bug in produzione!
Moriremo tutti?
No, ma forse qualcuno salterà la cena.
Anche qui dipende dai processi implementati, se lavori in una startup o in una corporate, se c’è uno o più team dedicati, se c’è una policy per dare priorità ai bug, se c’è un presidio h24…
In tutti i casi, sapere come e a chi comunicare lo stato del problema, risulta utile.
Se hai riconosciuto qualcuno di questi scenari, potresti essere interessato a qualche esperimento da provare.
Per ogni scenario, condivido quello che per me ha funzionato, sia nella mia esperienza di dev sia come facilitatrice.
Capire i requisiti – Non dare per scontato nulla, controlla il contesto
Verifica se esiste il vocabolario comune
Quando scegli di condividere delle informazioni tecniche a chi tecnico non è, potresti cadere nell’errore di dare per scontato un vocabolario comune.
Framework, protocollo, pattern, microservizi… potrebbero essere parole che tu usi abitualmente ma che non fanno parte del vocabolario del tuo interlocutore.
Per avere più possibilità che la comunicazione avvenga, potresti verificare quali parole fanno parte del loro vocabolario e che il significato sia lo stesso o per lo meno molto simile.
Definisci il livello di dettaglio
Se sei una persona attenta al dettaglio, potresti aver bisogno di capire fino all’ultimo bit prima di essere pronta a spiegare qualcosa. Magari ti piace andare in fondo ai problemi, studiare soluzioni diverse ed essere preparato a rispondere anche alle domande più complesse.
Mi ricorda un po’ il famoso schema di Alastair Cockburn sui livelli degli Use Case.
Se nella tua comunicazione riesci a stare a livello del “mare”, potrebbe andare bene, con qualche capatina sopra (kite) e sotto (fish).
Potrebbe essere utile capire il livello di dettaglio di cui hai bisogno, e se ti serve per sentirti bene andare in profondità e poi tornare su e capire quali informazioni sono state utili per te e quali sono quelle essenziali da comunicare.
In questo modo, se ti chiedono più dettagli, li hai, magari messi in appendice.
Il livello di dettaglio di cui hai bisogno potrebbe non servire però alle persone con cui stai comunicando per capire il problema.
Anzi potrebbe creare confusione.
Una volta che hai il livello di dettaglio utile per te, cerca di capire quale potrebbe essere quello utile a Prodotto o a Marketing o al tuo manager.
Lo sviluppo del software è una attività collaborativa, lo avevo detto no?
Schemi, diagrammi ed altri animali fantastici
Se schemi e diagrammi sono il tuo pane quotidiano, ti fanno capire le cose, e sono anche il modo di comunicare con gli altri colleghi del team di sviluppano, perché non funzionano con chi non è tech?
Anche qui, dipende, ci sono diagrammi che potrebbero essere più utili di un documento di 200 pagine!
Ma usare un diagramma presuppone che l’altra persona capisca la notazione, il significato di un quadrato, un cerchio, una freccia.
Sempre di un vocabolario comune si tratta. Quindi usali controllando che siano chiari ed utili per ragionare insieme.
Quando sarà finito? – Numeri più che parole
Ho assistito a lunghe discussioni anche solo per decidere se una storia valeva 2 o 3 punti.
Ho anche partecipato a lunghe discussioni su stime da rivedere, perché non coincidevano con le aspettative che in un altro dipartimento si erano create sulla base di… ecco, non so esattamente sulla base di cosa.
Ed è qui il punto: dati storici!
I dati storici alleggeriscono di molto il problema della comunicazione delle stime, perché si passa dalle stime al forecasting su dati storici.
Sia chiaro, lo sviluppo del software è una attività collaborativa, quindi la comunicazione non diventa meno importante se si utilizza il forecasting invece degli story point.
Dal mio punto di vista però, diventa più interessante perché si sposta sulla affidabilità dei dati che si basa su stabilità del team, conoscenza di dominio, capacità di innovazione, pratiche di programmazione…
Quindi la comunicazione che deve avvenire non è più se una User Story è 3 o 5 o se ce la facciamo a rilasciare 10 funzionalità in 3 mesi, ma come possiamo incrementare l’affidabilità dei team e quindi dei dati.
Bug in produzione! – Manteniamo la calma
Quando ci si rende conto di un problema in produzione la capacità di comunicare in maniera chiara cosa sta succedendo risulta ancora più importante.
Probabilmente, appena scoperto il problema, non si ha una idea chiara di quello che sta succedendo e tutti vogliono saperlo!
Quello che si deve comunicare è proprio questo insieme all’esigenza di avere lo spazio mentale ed il tempo di capire cosa sta succedendo.
Se non esiste un processo collaudato, quello che si può fare è di accordarsi sulla frequenza di update brevi. Anche qui, meno di parla “tecnichese” meglio è.
Di solito quello che si vuole sapere è se il problema è stato individuaro, se la soluzione è stata trovata ed in quanto tempo si potrà risolvere.
Risolto il problema bloccante, si dovrà avere una conversazione più lunga sulle possibili cause per esempio utilizzando la tecnica dei Five Whys per fare una root cause analisys.
Conclusioni
Per fare un buon prodotto servono diverse competenze e comunicare per andare verso un obiettivo comune diventa essenziale.
In ogni fase dello sviluppo del software avere la capacità di comunicare e capire cosa l’interlocutore ha bisogno di sapere sono due elementi essenziali per la collaborazione.
- Controlla se avete un vocabolario comune
- Fai domande per capire cosa per loro è importante sapere
- Usa dati storici ogni volta che puoi
Saper creare un clima di collaborazione è una delle competenze che ti serviranno di più nello sviluppo del software.
