Home
Gestire team di sviluppo

22 Febbraio 2023

Gestire team di sviluppo

di

Chi coordina un team di sviluppo sa quanto sia duro mantenere la puntualità. Sa anche che spesso aggiungere manodopera non risolve un ritardo di produzione?

Le cose da sapere per gestire sapientemente le tempistiche di un team di sviluppo

  1. Quanto è mitico il mese-uomo e quanto è vera la legge di Brooks
  2. Perché organizzare un team di sviluppo come una équipe chirurgica
  3. Perché la Torre di Babele è stata un fallimento
  4. Come progettare per escludere gli errori
  5. Come si organizza un team di sviluppo per un grande progetto di programmazione

1. Quanto è mitico il mese-uomo e quanto è vera la legge di Brooks

Nel corso degli anni, sono stati condotti molti studi quantitativi della produttività del software e dei fattori che la influenzano, in particolare dei compromessi fra numero di persone impegnate in un progetto e calendario.

Lo studio più ampio è quello condotto da Barry Boehm su 63 progetti software, principalmente nel settore aerospaziale, di cui circa 25 alla TRW. Il suo Software Engineering Economics contiene non solo i risultati ma anche un utile gruppo di modelli dei costi di progressiva estensione. Mentre i coefficienti nei modelli sono sicuramente diversi, per il software commerciale e per quello aerospaziale costruito rispettando standard governativi, i suoi modelli sono comunque sostenuti da una quantità immensa di dati.

I suoi risultati confermano saldamente l’affermazione, contenuta nel mio libro, che il compromesso tra persone e mesi è tutt’altro che lineare, che il mese-uomo è effettivamente un mito come misura della produttività. Alcune delle cose che appura, in particolare, sono le seguenti.

  • Esiste un tempo di calendarizzazione ottimale per i costi fino alla prima pubblicazione, T = 2,5 (mesi-uomo)1/3. In altre parole: il tempo ottimale in mesi è proporzionale alla radice cubica dell’impegno atteso in mesi-uomo, un valore derivato dalla stima delle dimensioni e da altri fattori nel suo modello. Come corollario si ottiene una curva della numerosità ottimale dello staff.
  • La curva dei costi sale lentamente quando il calendario previsto si allunga oltre l’ottimo. Persone con più tempo si prendono più tempo.
  • La curva dei costi sale bruscamente quando il calendario previsto diventa più breve dell’ottimo.
  • È molto difficile che un progetto abbia successo in meno dei tre quarti del calendario ottimo calcolato, indipendentemente dal numero delle persone coinvolte. Questo risultato fornisce al manager del software un’arma significativa, quando il management a livelli più alti pretende l’impegno a scadenze impossibili.

Quanto è vera la Legge di Brooks

Ci sono stati studi molto attenti che hanno valutato la verità della Legge di Brooks (volutamente semplicistica), secondo la quale l’aggiunta di manodopera a un progetto software in ritardo lo fa andare ancora più in ritardo. La trattazione migliore è quella che ne hanno fatto Abdel-Hamid e Madnick nel loro ambizioso e prezioso libro Software Project Dynamics: An Integrated Approach. Il libro sviluppa un modello quantitativo della dinamica dei progetti e il capitolo sulla Legge di Brooks fornisce una analisi più dettagliata di quello che succede sotto varie ipotesi relative a quale manodopera viene introdotta e quando. Per studiare la cosa, gli autori estendono il loro modello di un progetto applicativo di medie dimensioni, assumendo che nuove persone hanno una curva di apprendimento e tenendo conto dell’impegno di comunicazione e formazione. Ne concludono che:

Aggiungere più persone a un progetto in ritardo lo rende più costoso, ma non sempre fa sì che venga completato in ritardo. In particolare, l’inserimento di manodopera aggiuntiva nelle fasi iniziali del calendario è una manovra molto più sicura che non inserirla più avanti, perché i nuovi arrivati hanno sempre un effetto negativo immediato, che viene compensato nell’arco di settimane.

Torna all’inizio.

2. Perché organizzare un team di sviluppo come una équipe chirurgica

I manager da tempo hanno notato ampie variazioni di produttività tra i buoni programmatori e quelli mediocri, ma gli ordini di grandezza effettivamente misurati hanno lasciato tutti a bocca aperta. In uno studio, il rapporto fra le prestazioni migliori e le peggiori era in media di 10:1 per le misurazioni di velocità e produttività e un incredibile 5:1 per le misure di velocità e spazio dei programmi. In breve: il programmatore da 20 mila dollari all’anno può essere dieci volte più produttivo di quello da 10 mila dollari. Può essere vero però anche il contrario. I dati non mostravano alcuna correlazione fra esperienza e performance. (Dubito che questo sia vero in generale.)

In precedenza ho sostenuto che il puro numero delle menti da coordinare incide sul costo del progetto, perché una grande parte dei costi è dovuta alla comunicazione e alla correzione degli effetti negativi della cattiva comunicazione (debug di sistema). Anche questo ci induce a pensare che vorremmo che il sistema venisse costruito dal minor numero possibile di menti. In effetti, la maggior parte dell’esperienza con i grandi sistemi di programmazione dice che l’approccio a forza bruta è costoso, lento, inefficiente e produce sistemi che non sono concettualmente integrati. OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE e così via: l’elenco potrebbe continuare a piacere.

La conclusione è semplice: se un progetto con 200 persone ha 25 manager che sono i programmatori più competenti ed esperti, licenziate la truppa dei 175 e rimettete i manager a programmare.

Esaminiamo questa soluzione. Da un lato, non si avvicina all’ideale del piccolo team in gamba, che per comune consenso non dovrebbe superare le dieci persone. È così ampio che dovrà avere almeno due livelli di management, ovvero circa cinque manager. Inoltre avrà bisogno di supporto di finanza, personale, spazio, segreteria e operatori di macchina.

D’altro lato, l’originale team di 200 persone non era abbastanza grande per costruire sistemi davvero grandi mediante metodi a forza bruta. Prendiamo OS/360, per esempio. Nel punto di massimo impegno vi lavoravano oltre mille persone: programmatori, scrittori, operatori di macchina, impiegati, personale di segreteria, manager, gruppi di supporto e così via. Dal 1963 a tutto il 1966 probabilmente la sua progettazione, costruzione e documentazione ha richiesto 5.000 anni-uomo. Il nostro ipotetico team di 200 persone avrebbe impiegato 25 anni per portare il prodotto al suo stato attuale, se si potessero scambiare alla pari persone e mesi!

Leggi anche: La legge di Brooks è sempre attuale

Questo dunque è il problema dell’idea del piccolo team molto in gamba: è troppo lento per sistemi davvero grandi. Pensiamo al lavoro sull’OS/360 come avrebbe potuto essere affrontato da un piccolo team molto in gamba. Immaginiamo un team di 10 persone. Come condizione, poniamo che quelle dieci persone siano sette volte più produttive di un programmatore mediocre, sia nella programmazione che nella documentazione, perché sono persone davvero in gamba. Ipotizziamo che OS/360 sia stato creato solo da programmatori mediocri (un’assunzione molto lontana dal vero). Come condizione, assumiamo che un altro fattore sette di miglioramento della produttività derivi dalle minori esigenze di comunicazione generale dalle minori dimensioni del team. Assumiamo che lo stesso team segua tutto il lavoro. Bene, 5.000/(10 × 7 × 7) = 10; potrebbero dunque svolgere quel lavoro da 5.000 anni-uomo in dieci anni. Il prodotto sarà ancora interessante a dieci anni di distanza dal suo progetto iniziale? Oppure sarà stato reso obsoleto dall’evoluzione rapida della tecnologia del software?

Il dilemma è crudele. A fini di efficienza e integrità concettuale, si preferirebbe che progettazione e costruzione siano effettuate da poche menti molto in gamba. Per i grandi sistemi però si vorrebbe far lavorare una quantità notevole di persone, in modo che il prodotto possa essere completato tempestivamente. Come si possono riconciliare queste due esigenze?

La proposta di Mills

Una proposta avanzata da Harlan Mills ci offre una soluzione originale e creativa. Mills propone che ogni segmento di un lavoro di grandi dimensioni venga affrontato da un team, ma che il team sia organizzato come una équipe chirurgica invece che come una squadra di macellai. Cioè, invece di lasciare che ogni membro tagli via un pezzo del problema, uno solo taglia e gli altri gli forniscono tutto il supporto necessario per rafforzare la sua efficacia e la sua produttività.

Una breve riflessione mostra che quest’idea soddisfa i desiderata, se si può fare in modo che funzioni. Poche menti sono coinvolte nella progettazione e nella costruzione, ma sono molte le mani che vengono chiamate in causa. Può funzionare? Chi sono gli anestesisti e gli infermieri in un team di programmazione, e come si divide il lavoro? Mi prenderò la libertà di mescolare un po’ le metafore per immaginare come possa lavorare un team del genere, se allargato in modo da includere tutto il sostegno concepibile.

  • Il chirurgo. Mills lo definisce un capo programmatore. Definisce personalmente le specifiche funzionali e di performance, progetta il programma, lo codifica, lo testa e ne scrive la documentazione. Scrive in un linguaggio di programmazione strutturato come PL/I e ha accesso effettivo a un sistema di calcolo che non solo esegue i suoi test ma conserva anche le diverse versioni dei suoi programmi, gli consente di aggiornare facilmente i file e gli fornisce le funzioni di redazione dei testi per la documentazione. Deve avere un grande talento, dieci anni di esperienza e una notevole conoscenza di sistemi e applicazioni in matematica applicata, gestione di dati di business o quello che è.
  • Il copilota. È l’alter ego del chirurgo, in grado di svolgere qualsiasi parte del lavoro, ma ha meno esperienza. La sua funzione principale è partecipare alla progettazione come fornitore di idee, interlocutore nella discussione e valutatore. Il chirurgo mette alla prova le sue idee con lui, ma non è vincolato dai suoi pareri. Il copilota spesso rappresenta il suo team nelle discussioni sulle funzioni e l’interfaccia con altri team. Conosce intimamente tutto il codice. Effettua ricerche su strategie progettuali alternative. Ovviamente funge da assicurazione contro i disastri che possono colpire il chirurgo. Può addirittura scrivere del codice, ma non è responsabile di alcuna parte del codice stesso.
  • L’amministratore. Il chirurgo è il capo e deve avere l’ultima parola su personale, aumenti di stipendio, spazio e così via, ma non deve dedicare quasi nulla del suo tempo a queste cose. Perciò ha bisogno di un amministratore di professione che gestisca denaro, persone, spazi e macchine e che si interfacci con la macchina amministrativa del resto dell’organizzazione.
  • Il redattore. Il chirurgo ha la responsabilità di generare la documentazione: per avere il massimo di chiarezza, deve scriverla. Questo è vero per tutte le descrizioni, esterne e interne. Il redattore, però, prende la bozza o il manoscritto dettato prodotto dal chirurgo e lo critica, lo rielabora, lo fornisce di riferimenti e bibliografia, lo segue nelle sue varie versioni e sovrintende alla meccanica della produzione.
  • Due segretari. Tanto l’amministratore quanto il redattore avranno bisogno di un segretario; quello dell’amministratore gestirà la corrispondenza del progetto e i file che non sono di prodotto.
  • L’addetto al programma. Ha la responsabilità di mantenere tutta la documentazione tecnica del team in una biblioteca di prodotto di programmazione. L’addetto è formato come segretario ed è responsabile di tutti i file, sia quelli leggibili dalla macchina, sia quelli leggibili da esseri umani. Tutti gli input per il computer vanno a questo addetto, che accede e li inserisce se richiesto. I listati di ­output tornano a lui per essere archiviati e indicizzati. Le esecuzioni più recenti di qualsiasi modello sono conservate in un diario di stato; tutti i precedenti sono conservati in un archivio cronologico.
  • Il fabbro. I servizi di file editing, text editing e debug interattivo oggi sono facilmente disponibili, perciò un team raramente avrà bisogno di personale di macchina e per l’esercizio delle macchine. Questi servizi però devono essere disponibili con una rapidità di risposta e un’affidabilità senza alcun dubbio soddisfacenti; il chirurgo deve essere l’unico a giudicare dell’adeguatezza del servizio che gli è messo a disposizione. Ha bisogno di un fabbro, che ha la responsabilità di garantire questa adeguatezza del servizio di base e di costruire, manutenere e aggiornare strumenti speciali (principalmente servizi interattivi) di cui il team abbia bisogno. Ogni team avrà bisogno del proprio fabbro, indipendentemente dall’eccellenza e dall’affidabilità del servizio eventualmente fornito centralmente, perché il suo compito è provvedere agli strumenti di cui ha bisogno o che desidera il suo chirurgo, senza tener conto dei bisogni di qualsiasi altro team. Il costruttore di strumenti spesso costruirà utility specializzate, procedure catalogate, librerie di macro.
  • Il collaudatore. Il chirurgo avrà bisogno di un insieme adeguato di casi di test per mettere alla prova i vari pezzi del suo lavoro, a mano a mano che li scrive, e poi per il testing del totale. Il collaudatore è perciò sia un avversario che escogita casi di test del sistema a partire dalle specifiche funzionali, sia un assistente che escogita dati di test per il debug quotidiano. Pianificherà anche le sequenze di test e predisporrà la struttura necessaria per i test dei componenti.
  • L’avvocato del linguaggio. La maggior parte delle installazioni di computer ha una o due persone che si appassionano e padroneggiano gli aspetti più intricati di un linguaggio di programmazione. Questi esperti risultato molto utili e vengono consultati molto spesso. Il loro talento è molto diverso da quello del chirurgo, che è principalmente un progettista di sistema e che pensa in termini di rappresentazioni. L’avvocato del linguaggio può trovare un modo elegante ed efficiente di usare il linguaggio per fare cose difficili, oscure o problematiche. Spesso avrà bisogno di condurre un piccolo studio (due o tre giorni) sulla buona tecnica. Un avvocato del linguaggio può servire due o tre chirurghi.

Questo, dunque, è il modo in cui dieci persone possono contribuire in ruoli ben differenziati e specializzati a un team di programmazione costruito in base al modello chirurgico.

Torna all’inizio.

3. Perché la Torre di Babele è stata un fallimento

Tutta la terra aveva un’unica lingua e uniche parole. Emigrando dall’oriente, gli uomini capitarono in una pianura nella regione di Sinar e vi si stabilirono. Si dissero l’un l’altro: “Venite, facciamoci mattoni e cuociamoli al fuoco”. Il mattone servì loro da pietra e il bitume da malta. Poi dissero: “Venite, costruiamoci una città e una torre, la cui cima tocchi il cielo, e facciamoci un nome, per non disperderci su tutta la terra”. Ma il Signore scese a vedere la città e la torre che i figli degli uomini stavano costruendo. Il Signore disse: “Ecco, essi sono un unico popolo e hanno tutti un’unica lingua; questo è l’inizio della loro opera, e ora quanto avranno in progetto di fare non sarà loro impossibile. Scendiamo dunque e confondiamo la loro lingua, perché non comprendano più l’uno la lingua dell’altro”. Il Signore li disperse di là su tutta la terra ed essi cessarono di costruire la città.
– Genesi 11:1-8

Una verifica manageriale del progetto Babele

Secondo il racconto della Genesi, la Torre di Babele è stata la seconda intrapresa ingegneristica dell’umanità, dopo l’arca di Noè. Babele fu il primo fiasco ingegneristico.

La storia è profonda e istruttiva a vari livelli. Proviamo però a esaminarla puramente come un progetto tecnico, e vediamo quali insegnamenti se ne possano ricavare sul piano del management. Il progetto aveva i prerequisiti per il successo?

  1. Aveva una missione chiara? Sì, anche se ingenuamente impossibile. Il progetto è fallito molto prima di incappare in questo limite fondamentale.
  2. Aveva forza lavoro? In grande quantità.
  3. Aveva i materiali? Argilla e bitume sono abbondanti in Mesopotamia.
  4. Aveva abbastanza tempo? Sì, non ci sono indicazioni di scadenze prestabilite.
  5. Aveva una tecnologia adeguata? Sì, la struttura piramidale o conica è intrinsecamente stabile e scarica bene le sollecitazioni per compressione. Chiaramente le tecniche edilizie erano ben conosciute. Il progetto è fallito prima di raggiungere i suoi limiti tecnologici.

Bene, se aveva tutte queste cose, perché il progetto è fallito? Dove stavano le sue carenze? In due aspetti: la comunicazione e, di conseguenza, l’organizzazione. Le persone che ci lavoravano non erano in grado di parlare le une con le altre; perciò non hanno saputo coordinarsi. Quando il coordinamento fallisce, il lavoro si blocca. Leggendo fra le righe immaginiamo che la mancanza di comunicazione abbia portato a dispute, risentimenti e gelosie fra gruppi. In breve tempo i clan hanno iniziato a separarsi, preferendo l’isolamento ai diverbi.

Comunicazione nel grande progetto di programmazione

Succede lo stesso anche oggi. Disastri di calendarizzazione, inadeguatezze funzionali ed errori di sistema si presentano tutti perché la mano sinistra non sa quello che sta facendo la destra. Con il procedere del lavoro, i diversi team pian piano cambiano le funzioni, le dimensioni e le velocità dei loro programmi e, esplicitamente o implicitamente, modificano i presupposti in merito agli input disponibili e agli usi che verranno fatti degli output.

Team di sviluppo - il mito delle giornate-uomo

La chiave per gestire efficacemente team di sviluppo, dedicati alla programmazione ma non solo.

Per esempio, l’implementatore di una funzione di overlay può incappare in qualche problema e ridurre la velocità, facendo affidamento su statistiche che mostrano quanto raramente questa funzione verrà attivata nei programmi applicativi. Nel frattempo, il suo vicino magari progetta una parte importante del supervisore in modo che dipenda criticamente dalla velocità di quella funzione. Il cambiamento di velocità diventa una modifica importante delle specifiche e deve essere dichiarato pubblicamente e valutato dal punto di vista del sistema.

Allora, come devono comunicare fra loro i team? Nel maggior numero possibile di modi.

  • Informalmente. Un buon servizio telefonico e una definizione chiara delle dipendenze fra gruppi incoraggeranno le centinaia di telefonate da cui dipende l’interpretazione comune dei documenti scritti.
  • Con le riunioni. Riunioni di progetto regolari, in ogni un team dopo l’altro offre un resoconto tecnico del proprio lavoro, sono preziosissime. Centinaia di piccoli fraintendimenti si possono spazzar via in questo modo.
  • Con una guida di lavoro. Sin dall’inizio bisogna avviare un manuale formale del progetto. È un aspetto che merita un paragrafo a sé.

Torna all’inizio.

4. Come progettare per escludere gli errori

Definizioni a prova di bug

I bug più dannosi e sfuggenti sono bug di sistema che derivano da assunzioni discordanti effettuate dagli autori di componenti diversi. Il modo di affrontare l’integrità concettuale affronta questi problemi direttamente. In breve: l’integrità concettuale del prodotto non solo lo rende più facile da usare, ma anche più facile da costruire e meno soggetto a bug.

La stessa considerazione vale per l’impegno architettonico dettagliato e pignolo che questo approccio comporta. Dice V.A. Vyssotsky del Safeguard Project dei Bell Telephone Laboratories:

Il compito cruciale è definire il prodotto. Molti, molti fallimenti sono dovuti esattamente a quegli aspetti che non sono stati mai specificati adeguatamente.

La definizione funzionale attenta, una specifica attenta e l’esorcizzazione disciplinata di fronzoli nelle funzioni e di voli pindarici nella tecnica riducono il numero degli errori di sistema che bisogna individuare.

Test delle specifiche

Molto prima ancora che esista del codice, le specifiche devono essere trasmesse a un gruppo esterno di test perché le esamini attentamente e ne valuti completezza e chiarezza. Come dice Vyssotsky, non è una cosa che possano fare gli sviluppatori stessi: Non ti diranno mai che non le capiscono; tranquillamente inventeranno un loro modo per superare lacune e punti oscuri.

Progettazione top-down

In un saggio molto chiaro, Niklaus Wirth ha formalizzato una procedura di progettazione che è utilizzata da anni dai migliori programmatori. Le sue idee, inoltre, anche se formulate per la progettazione di programmi, si applicano perfettamente anche alla progettazione di sistemi complessi di programmi. La suddivisione della costruzione di un sistema in architettura, implementazione e realizzazioni è un’incarnazione di quelle idee; inoltre, il modo migliore per creare architettura, implementazione e realizzazione è utilizzare metodi top-down.

In breve, Wirth identifica la progettazione come una sequenza di passi di perfezionamento. Si abbozzano una prima definizione approssimativa dell’attività e a grandi linee un metodo di risoluzione che permetta di raggiungere il risultato principale. Poi si esamina più da vicino la definizione, per vedere in che cosa il risultato sia diverso da quello che si voleva, e si suddividono in passi più piccoli i grandi passi della soluzione. Ogni perfezionamento della definizione dell’attività diventa un perfezionamento nell’algoritmo per la soluzione ed entrambi possono essere accompagnati da un perfezionamento nella rappresentazione dei dati.

Grazie a questo processo si identificano moduli di soluzione o di dati, il cui ulteriore perfezionamento può avvenire in modo indipendente. Il grado di questa modularità determina l’adattabilità e la modificabilità del programma.

Wirth sostiene l’opportunità di usare il più possibile una notazione di alto livello per ogni passo, esponendo i concetti e nascondendo i dettagli finché non diventa necessario un ulteriore perfezionamento.

Programmazione strutturata

Un altro insieme importante di nuove idee per eliminare dai programmi gli errori in fase di progetto deriva in gran parte da Dijkstra e si basa su una struttura teorica di Böhm e Jacopini.

Fondamentalmente, quello che si richiede è progettare programmi le cui strutture di controllo siano costituite esclusivamente da cicli definiti da enunciati come DO WHILE e clausole condizionali espresse in gruppi di enunciati racchiusi fra parentesi graffe e condizionati da un IF…THEN…ELSE. Böhm e Jacopini mostrano che queste strutture sono sufficienti, sul piano teorico; Dijkstra sostiene che l’alternativa, consentire salti non condizionati mediante GO TO, produce strutture che si prestano facilmente a errori logici.

L’idea di base è sicuramente corretta. Sono state sollevate molte critiche, e ulteriori strutture di controllo, come una diramazione a n vie (il cosiddetto enunciato CASE) per distinguere fra vari casi possibili e una via d’uscita per evitare i disastri (GO TO ABNORMAL END) sono molto comode. Qualcuno, poi, è diventato molto intransigente a proposito dell’evitare tutti i GO TO, e questo sembra eccessivo.

La cosa importante, e determinante per costruire programmi privi di errori, è pensare le strutture di controllo di un sistema come strutture di controllo e non come singoli enunciati di salto. Questo modo di pensare è un grande passo avanti.

Torna all’inizio.

5. Come si organizza un team di sviluppo per un grande progetto di programmazione

Se a un progetto lavorano n persone, ci sono (n2n)/2 interfacce attraverso le quali può esserci comunicazione, e ci sono potenzialmente quasi 2n team all’interno dei quali deve esistere un coordinamento. Lo scopo dell’organizzazione è ridurre la quantità necessaria di comunicazione e coordinamento; quindi, l’organizzazione è una forma radicale di attacco ai problemi di comunicazione visti sopra.

In mezzi con cui si ovvia alla comunicazione sono la divisione del lavoro e la specializzazione delle funzioni. La struttura ad albero delle organizzazioni rispecchia la minore necessità di comunicazioni dettagliate quando vengono applicate la divisione e la specializzazione del lavoro.

In effetti un’organizzazione ad albero nasce come struttura di autorità e responsabilità. Il principio che un essere umano non possa servire due padroni determina la struttura ad albero dell’autorità. La struttura della comunicazione però non è così ristretta e l’albero è un’approssimazione a malapena accettabile per quella struttura, che è una rete. Le inadeguatezze dell’albero come approssimazione danno poi origine ai gruppi di staff, alle task force, ai comitati e addirittura all’organizzazione a matrice utilizzata in molti laboratori tecnici.

Proviamo a considerare un’organizzazione ad albero per la programmazione ed esaminiamo le caratteristiche essenziali che deve possedere ogni sottoalbero per poter essere efficace. Sono:

  1. una mission;
  2. un produttore;
  3. un direttore tecnico o architetto;
  4. un calendario;
  5. una definizione del lavoro;
  6. definizioni delle interfacce fra le parti.

Tutto questo è ovvio e convenzionale, tranne la distinzione fra produttore e direttore tecnico. Consideriamo prima i due ruoli, poi la loro relazione.

Qual è il ruolo del produttore? Costituisce il team, divide il lavoro, stabilisce il calendario. Acquisisce e continua ad acquisire le risorse necessarie. Questo significa che una parte importante del suo ruolo è la comunicazione all’esterno del team, verso l’alto e lateralmente. Stabilisce gli schemi di comunicazione e di reporting all’interno del team. Infine, garantisce che le scadenze vengano rispettate, spostando le risorse e l’organizzazione in risposta a cambiamenti delle circostanze.

E il direttore tecnico? Concepisce il progetto da costruire, ne identifica le sottoparti, specifica l’aspetto che presenterà all’esterno e ne schizza la struttura interna. Dà unità e integrità concettuale al progetto nella sua totalità; quindi funge da limite alla complessità del sistema. Quando sorgono singoli problemi tecnici, inventa delle soluzioni oppure modifica il progetto del sistema secondo necessità. Per usare la bella frase di Al Capp, è lo inside-man at the skunk works, l’infiltrato nelle segrete cose. Le sue comunicazioni sono principalmente all’interno del team e il suo lavoro è quasi completamente tecnico.

Ora è chiaro che i talenti necessari per questi due ruoli sono molto diversi. I talenti si presentano in molte combinazioni diverse e la particolare combinazione incarnata nel produttore e nel direttore deve governare la relazione fra loro. Le organizzazioni devono essere progettate intorno alle persone disponibili, non bisogna infilare a forza le persone nelle organizzazioni puramente teoriche.

Sono possibili tre tipi di relazioni e tutti si possono incontrare in attività pratiche di successo.

Il produttore e il direttore tecnico possono essere la stessa persona. Può funzionare bene in team molto piccoli, forse da tre a sei programmatori. Molto raramente può funzionare per progetti di dimensioni maggiori, e per due motivi. In primo luogo, si trova raramente la persona con un forte talento manageriale e un forte talento tecnico. Le persone che pensano sono rare; quelle che fanno sono più rare; quelle che pensano e fanno sono le più rare di tutte.

In secondo luogo, in un progetto di maggiori dimensioni ciascuno dei ruoli è necessariamente un lavoro a tempo pieno, o peggio. È difficile per il produttore delegare una quantità sufficiente dei propri compiti per liberare del tempo per gli aspetti tecnici. È impossibile per il direttore delegare i propri senza compromettere l’integrità concettuale del progetto.

Il produttore può essere il capo, il direttore il suo braccio destro. La difficoltà qui è stabilire l’autorità del direttore di prendere decisioni tecniche, senza incidere sul suo tempo come inciderebbe invece inquadrarlo nella catena di comando del management.

Ovviamente il produttore deve affermare l’autorità tecnica del direttore, e deve sostenerla in una proporzione estremamente elevata dei casi di test che si presenteranno. Perché questo sia possibile, il produttore e il direttore devono essere d’accordo sulla filosofia tecnica fondamentale; devono discutere i problemi tecnici principali in privato, prima che diventino davvero urgenti; e il produttore deve avere un grande rispetto per le capacità tecniche del direttore.

Cosa meno ovvia, il produttore può fare ogni genere di cosa con i simboli di status (dimensioni dell’ufficio, tappeto, mobili, copie carbone e così via) per stabilire chiaramente che il direttore, anche se al di fuori della linea di management, è una fonte di potere decisionale.

Questa combinazione può funzionare con grande efficacia, ma purtroppo viene provata raramente. La scelta meno valida da parte dei project manager è utilizzare il genio tecnico che non è molto dotato di talento manageriale.

Il direttore può essere il capo, e il produttore il suo braccio destro. Robert Heinlein, nel suo L’uomo che vendette la Luna, descrive una combinazione simile in un esempio molto efficace.

Nel romanzo, D.D. Harriman è un ricco imprenditore con il tocco di re Mida, capace di intuire con grande abilità e tempestività le innovazioni che possono rivelarsi eccellenti affari; ora si è fissato sulla possibilità di conquistare la Luna, e decide di investire tutto in quella possibilità. Da un lato inizia a prospettare ad altri, per guadagnarsi appoggi e finanziamenti, incredibili potenzialità (ci sarà uranio, ci saranno diamanti…), nella previsione di poter avere tutto il satellite a propria disposizione; dall’altro affida il compito tecnico di trovare il modo di arrivare sulla Luna a Bob Coster, già collaboratore del Dipartimento della Difesa e da un po’ di tempo dipendente di una delle sue aziende.

Quando, dopo qualche tempo, lo va a trovare nel suo ufficio lo trova quasi disperato: Lo so, so che cosa bisogna fare, ma ogni volta che tento di attaccare un problema tecnico, qualche maledetto cretino vuole che io prenda una decisione sui camion, o sui telefoni o su qualche altra maledetta cosa, gli racconta Coster. Harriman lo capisce al volo: ordina che la scrivania di Coster venga spostata e che tutte le carte che la ingombrano vengano scaricate altrove. Anche il telefono dovrà essere staccato: da quel momento Coster deve occuparsi solo della cosa di cui è stato incaricato, trovare il modo per arrivare sulla Luna. Harrimann convoca un’altra persona, Jack Berkeley, un manager esperto, a cui affida il compito di risolvere tutte le questioni non tecniche. Presentandoglielo, dice a Coster: Lei rimane ingegnere capo e indiscusso direttore. Jack penserà a tutto il resto. Da questo momento non ha assolutamente più nulla di cui preoccuparsi, tranne il piccolo particolare di costruire l’astronave per la Luna. I due si stringono la mano e Berkeley dice a Coster di rifilare a lui tutto quello che vuole: il suo compito è seguire la parte tecnica, ma per favore che documenti tutto, in modo che lui possa sapere che cosa accade. E se le occorre qualcosa che non sia tecnico, non lo faccia lei. Prema il pulsante!.

Non mi sembra ci sia bisogno di un commento analitico. Anche questa combinazione può funzionare efficacemente.

Sospetto che l’ultima combinazione sia la migliore per i piccoli team. Penso che il produttore come capo sia una soluzione più adatta per i sottoalberi più ampi di un progetto davvero grande.

Torna all’inizio.

Questo articolo richiama contenuti da Il mito delle giornate-uomo.

Immagine di apertura di Randy Fath su Unsplash.

L'autore

  • Frederick P. Brooks, Jr.
    Frederick P. Brooks, Jr. è stato docente di Computer Science e direttore del dipartimento di Informatica all'Università del North Carolina per oltre vent'anni. Nella sua lunga carriera ha contribuito allo sviluppo di diverse famiglie di macchine IBM introducendo il cambiamento fondamentale della dimensione di un byte da 6 a 8 bit. Il suo lavoro gli è valso riconoscimenti in tutto il mondo. Il mito delle giornate-uomo è il suo best seller assoluto ed è diventato un must-read senza tempo nella letteratura di settore.

Iscriviti alla newsletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.

Libri che potrebbero interessarti

Tutti i libri

Il mito delle giornate-uomo

Saggi sull'ingegneria del software

29,15

41,89€ -30%

23,66

24,90€ -5%

16,99

di Frederick P. Brooks, Jr.