Lo sviluppo di software è creazione di nuova conoscenza. L’azienda vuole evolvere il proprio know-how?

Con questo articolo cerco di rispondere ad alcune domande.

  • L’azienda vuole evolvere il proprio know-how?
  • Che cosa sta uccidendo molte aziende che si occupano di sviluppo?

I problemi delle grandi aziende IT è spesso ricercato nel settore sviluppo, tanto che più è grande l’azienda e piu’ si cerca di esternalizzare proprio lo sviluppo. In alcuni casi si cerca di manterenere il controllo sul know-how internalizzando i settori funzionali a scapito del development.
Detto questo non penso lontanamente che ci possa essere un problema nell’IT a causa dell’assenza di capacità professionali d’eccellenza all’interno dell’azienda, piuttosto sono convinto che il settore sviluppo sia proprio quello che concentra più cervelli interessanti; chi si dedica allo sviluppo lo fa quasi sempre per la passione nell’approfondire la conoscenza.
Per questo motivo vedo il problema dello sviluppo incentrato su come gli sviluppatori vengono messi assieme in azienda, come vengono gestiti e per quale motivo vengono assunti e con quale criterio gli vengono affidati i ruoli.

Nella  esperienza avuta ho potuto vedere risultati d’eccellenza e di qualità internazionale solo in brevi momenti  , solo in determate “isole felici” che il mercato era pronto ad assorbire. Questi gruppi di sviluppo sono evaporati nel tempo in molte delle aziende che ho conosciuto.

Le ipotesi che stanno dietro il recruiting di sviluppatori.

Per spiegare questa situazione ho intenzione di rendere espliciti alcuni dei presupposti taciti che spesso in una grande azienda sono alla base del recruiting di un team del settore sviluppo. Questo è un punto cruciale poichè, nella gran parte delle organizzazioni, chi influenza queste decisioni il più delle volte non potrà mai essere ritenuto responsabile.

Basandomi sulle idee di Ash Moran, i presupposti dell’organizzazione in questione sembrano essere i seguenti:

  1. Gli sviluppatori sono fungibili
  2. La produttività è proporzionale alle ore di  sviluppo
  3.  I requisiti sono tutti necessari

1. Gli sviluppatori sono fungibili

Tom de Marco, nel suo “Slack – manuale per manager, imprenditori e Ceo“,  definisce “Il mito della risorsa fungibile“. Molti posti di lavoro in fabbrica e in magazzino sono ampiamente fungibili, nel senso che il tempo di portare qualcuno fino alla piena produttività è pressoché irrilevante (ore o giorni). Questo non è vero quando si parla di sviluppo, dove anche se un neo assunto conosce il linguaggio di programmazione, dato il contesto, ci vorrà  molto tempo per  l’apprendimento del codice di base e delle metodologie aziendali.

Non credo che gli sviluppatori  siano fungibili (almeno nella stragrande maggioranza dei casi), ma ho partecipato a innumerevoli meeting in cui i decision maker si comportavano come se questa ipotesi fosse valida. Ogni volta , stime alla mano, la stragrande maggioranza dei managers agisce come se un nuovo sviluppatore possa immediatamente aumentare la produttività del team.
Questa assunzione è in contraddizione con ciò che gli sviluppatori pensano espressamente in merito alla natura del proprio lavoro.

2. La produttività è proporzionale alle ore di sviluppo

Ci sono due forme degenerative di pensiero per questa ipotesi:

1) L’idea che uno sviluppatore che lavora 10 ore al giorno sarà il 25% più produttivo di uno sviluppatore di lavoro di 8 ore al dì

2) La convinzione che un team di 10 sviluppatori è del 25% più produttivo di un team di 8.

Ho parlato di degenerazione in quanto sono convinto, come Ash, che la natura dello sviluppo del software sia la creazione di nuova conoscenza, concetto che ho descrito in un precedente articolo.
Dobbiamo pensare agli svilppatori come figure che affrontano un compito creativo. Un lavoro che coinvolge costantemente il programmatore, chiamato sempre più spesso a prendere decisioni logiche.

L’ipotesi produttività-tempo si basa sull’idea che la produttività sia rappresentabile come una bilancia a squadra lineare. Questo non è vero nello sviluppo, per la semplice ragione che la complessità nella gestione di un team non è per forza relativa al numero di persone coinvolte, ma è funzione della natura del coinvolgimento e della quantità di comunicazione necessaria per svolgere un determinato compito.
Basta pensare che a volte è più semplice far svolgere un compito a molte persone, piuttosto che cercare di mettere daccordo 4 persone sulla scelta di quale film andare a vedere dopo cena.
Ovviamente dipende dal compito, così come alcuni importanti progetti informatici si possono svolgere meglio con una piccola squadra di lavoro.

La disattenzione è la causa principale di importanti bug.

Vi segnalo un interessante articolo: Do You Suffer From Decision Fatigue? ; il cervello umano ha una capacità limitata di fare scelte, e una volta stanchi, ci trova spesso a ricercare scorciatoie.

3. I requisiti sono tutti necessari

Nella maggior parte delle grandi aziende informatiche, i requisiti funzionali  vengono definiti al di fuori del team di sviluppo. A meno che il team di sviluppo non stia scrivendo software esclusivamente per se stesso, il cosidetto “Settore Funzionale” (Functionals) sarà coinvolto nel redigere un documento in cui è descritto il lavoro che deve essere svolto dal settore sviluppo. In seguito a volte accade che il 30% delle funzionalità nel software non saranno mai usate o non necessarie, quindi almeno il 30% del tempo di sviluppo diventa puro spreco.  Tuttavia, molte squadre sono contrattualmente obbligate a fornire una specifica (documento funzionale) senza un riferimento al valore delle caratteristiche della specifica stessa, questo può essere una fonte di bugs difficile da sanare.

Il team impegnato

Quando il team di sviluppo non sta funzionando a pieno regime, si perde almeno il 25% del  tempo a rielaborare e a fare manutenzione. Se succede questo la squadra non produce codice di massima qualità, anche se le competenze esistenti del team sono altissime. Alcuni bug vengono introdotti da sviluppatori che sono stanchi e troppo stressati. L’overhead di comunicazione riduce la produttività a breve termine.
Le dimensioni del team
Quanti sviluppatori si dovrebbero assumere?
L’aumento della capacità non è l’unico motivo per cui si consiglia di assumere personale. Un motivo molto valido è la ridondanza. Le squadre molto piccole sono vulnerabili alla legge di Murphy; se il vostro unico sviluppatore viene investito da un autobus, il progetto sarà in gravissimo pericolo. Ma è anche possibile che un team di 10 persone sia devastato da un singolo incidente nello stesso bus. Alcune questioni sulla dimensione di varie squadre di lavoro sono dettagliate in un articolo di Christopher Allen dal titolo Il numero di Dunbar come un limite alla dimensione del gruppo.Un team di piccole dimensioni può essere meno rischioso di quello che appare, dato che  gli sviluppatori sono molto raramente investiti da autobus, come è vero però che vanno gestiti dato che molto raramente lasciano il lavoro a causa della retribuzione.
I programmatori molto frequentemente lasciano il team a causa di condizioni di lavoro insoddisfacenti, condizioni che sono causate quasi sempre dalle decisioni dei manager.
C’è anche una situazione in cui si può desiderare di aumentare la dimensione della tua squadra: quando la persona che stai aggiungendo ha la conoscenza e l’esperienza per contribuire a migliorare l’efficacia di tutti gli altri. In questo caso, però, le loro responsabilità dovranno estendersi ben oltre lo sviluppo puro.
Cosa fare?
La prima cosa è fare un passo indietro e verificare se si sta cercando di risolvere un problema fondamentalmente causato dall’inutilità sistematica di immetere un effort maggiore al team.
Sappiamo che se un capitano di un’imbarcazione, che vedendo una falla, ordinasse a tutti i marinai di svuotare l’acqua piuttosto tenere sotto controllo la situazione e chiamare un singolo ingeniere per riparare la falla, sarebbe inefficace.
Fred Brooks ha espresso la Legge di Brooks più di trent’anni fa: “L’ Aggiunta di manodopera per un progetto software in ritardo porta più ritardo”.
Migliorare la produttività di un team che sviluppa software è difficile. Si tratta di comprendere il business, il team, la storia e gli ostacoli che bloccano il progresso. Si tratta di affrontare un problema complesso, sensibile al contesto.
Noi vediamo il mondo filtrato dalle metafore che siamo in grado di esprimere.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

*