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.