quando il progetto diventa una guerra interna
Jack Tramiel riassumeva la propria filosofia con una frase brutale: «Business is war. I don’t believe in compromising. I believe in winning», cioè «Gli affari sono guerra. Non credo nei compromessi. Credo nella vittoria».1
La formula descrive bene la guerra dei prezzi con cui Commodore portò i computer nelle case. Contiene anche un avvertimento: quando la metafora supera il confine del mercato ed entra nell’organizzazione, colleghi e responsabili possono cominciare a trattarsi come avversari.
Il Commodore 64 nacque dal lavoro di un gruppo ristretto di persone. Al Charpentier progettò il chip grafico VIC-II, Bob Yannes il chip sonoro SID; il gruppo costruì il prototipo rispettando vincoli severi di costo e di tempo. La produzione richiese poi il contributo di altre funzioni aziendali.2
Fred Brooks, nel 1975 disse che aggiungere persone a un progetto software in ritardo può accrescere il ritardo, perché i nuovi arrivati devono apprendere e chi già lavora deve formarli, ridistribuire le attività e coordinare le dipendenze.3
Infatti, dieci persone formano 45 possibili coppie di comunicazione; venti persone alzano il numero delle possibili combinazioni a 190. La formula misura le relazioni possibili, non il numero delle conversazioni necessarie.
Se ogni informazione deve attraversarle tutte, il difetto riguarda la struttura del lavoro: responsabilità poco definite, decisioni senza titolare, documenti che ripetono dati e riunioni convocate per ricostruire ciò che nessuno ha reso consultabile.
La burocrazia difensiva nasce quando a questo costo si aggiunge la paura della colpa. Una ricerca su 950 dirigenti pubblici ha rilevato decisioni difensive diffuse e ha collegato il fenomeno al modo in cui i gruppi reagiscono agli errori: cercare un colpevole induce scelte personali più sicure, anche quando servono meno all’organizzazione.4
In un progetto accade qualcosa di analogo quando una relazione viene scritta per dimostrare la propria innocenza, quando una riunione distribuisce la responsabilità fra troppi presenti e nessuno si assume alcuna vera responsabilità.
La documentazione diventa utile quando ricorda motivazioni, vincoli e responsabilità. Ma assume una connotazione difensiva se diventa un accumulo di prove per un potenziale processo.
Lo si capisce se il documento permette a qualcuno di comprendere una decisione e compiere il passaggio successivo. Ma se diventa uno scudo in caso di fallimento del progetto?
In questo caso, ecco la guerra evocata da Tramiel: l'organizzazione consuma le proprie forze per difendersi da se stessa.
Jack Tramiel, intervista di Brent Schlender per Fortune, 13 aprile 1998, riprodotta nell’archivio Commodore.ca; la stessa concezione compare in una sua intervista televisiva del 1983 conservata dall’American Archive of Public Broadcasting.↩
Ricostruzione basata sulle testimonianze degli ingegneri raccolte in “The Design Case History of the Commodore 64” e riprodotte nell’archivio MayhemUK. Le fonti distinguono lo sviluppo iniziale dei componenti e del prototipo dal successivo lavoro di industrializzazione.↩
Frederick P. Brooks Jr., The Mythical Man-Month, 1975, cap. 2, copia consultabile presso la Carnegie Mellon University.↩
Florian M. Artinger, Sabrina Artinger e Gerd Gigerenzer, “C. Y. A.: frequency and causes of defensive decisions in public administration”, Business Research, 2019, Springer Nature.↩