Otto piccole regole da seguire quando si lavora con un team di programmatori

(4) Troppi o pochi compiti assegnati

Il sottodimensionamento del numero di dipendenti può provocare una ridotta motivazione, troppi incarichi ne provocano l’esaurimento. Contrariamente anche avere pochi compiti da svolgere potrebbe demotivare il programmatore facendolo sentire poco apprezzato.

Una buona azienda può evitare questa problematica implementando una corretta gestione delle risorse. Strumenti come Teamdeck (https://teamdeck.io/) possono sicuramente contribuire a mantenere il giusto flusso di risorse tra i progetti e l’utilizzo del team.

(5) Le interruzioni

Ci vogliono fino a 35’ – 40’ minuti per un programmatore per entrare nella cosiddetta “zona”, che è uno stato di massima concentrazione che assicura la massima produttività. Purtroppo però uscirne è molto più veloce. A volte tutto ciò che serve, per interrompere il programmatore, è una domanda posta di persona oppure tramite messaggi di posta o chat.

Un’altra forma di interruzione è la commutazione del contesto. Succede ad esempio quando uno sviluppatore lavora su differenti progetti durante il giorno. La commutazione del contesto non ben concertata può causare perdita di tempo o ritardi di progetto per l’azienda, poiché i dipendenti hanno bisogno materialmente di tempo per passare da un progetto all’altro.

Durante la gestione del progetto, cercate di pianificare ogni dettaglio di esso e di evitare di interrompere gli sviluppatori durante il loro lavoro.

Le piccole interruzioni relative al lavoro da eseguire durante il giorno, riguardanti il progetto, cercate di affrontarle durante i Daily Scrum Meeting: è per questo che ci sono. Il programmatore farà il suo lavoro in maniera meno stressante e più efficiente.

(6) Le riunioni inutili

Non ogni riunione dovrebbe effettivamente svolgersi. In Italia ho transitato in aziende “meeting-centriche” (lasciatemi passare il fantasioso neologismo) poco produttive. Quasi certamente non c’è bisogno di avere tutti gli sviluppatori coinvolti nella maggioranza delle riunioni.

Tuttavia, ci sono incontri che richiedono una presenza di sviluppatori, come pianificazioni, revisioni di progetti, etc. Qui possono rispondere a domande tecniche oppure commentare il processo di sviluppo.

Quando si pianifica una riunione, decidere se gli sviluppatori dovrebbero veramente farne parte e quali/quanti debbano partecipare. Altrimenti, possono trascorrere il loro tempo in modo più efficace lavorando sul progresso di un determinato progetto.