Quello che siamo arrivati a pensare come il progetto Peopleware è iniziato per noi nel corso di un lungo volo notturno sul Pacifico più di trent'anni fa. Stavamo volando insieme da Los Angeles a Sydney per insegnare la nostra serie di lezioni di ingegneria del software. Incapaci di dormire, abbiamo chiacchierato tutta la notte sulle profonde complessità che stavamo incontrando nei nostri progetti di sistemi e in quelli relativi a noi dai nostri clienti. Uno di noi, nessuno dei due riesce a ricordare quale fosse, ha riflettuto su ciò di cui stavamo discutendo e ha offerto questo riassunto: “Forse . . . i maggiori problemi di funzionamento dei sistemi non sono tanto tecnologici quanto sociologici”. C'è voluto un po' di tempo per farcela perché era così contrario a quello che era stato il nostro pensiero prima. Noi, insieme a quasi tutti gli altri coinvolti negli sforzi high-tech, eravamo convinti che la tecnologia fosse tutto, che qualunque fossero i tuoi problemi, doveva esserci una soluzione tecnologica migliore per loro. Ma se quello a cui ti trovavi di fronte era intrinsecamente sociologico, sembrava improbabile che una tecnologia migliore potesse essere di grande aiuto. Se un gruppo di persone che doveva lavorare insieme non si fidava l'uno dell'altro, ad esempio, nessun pacchetto software o aggeggio intelligente avrebbe fatto la differenza. Una volta che l'idea è stata aperta, abbiamo iniziato a pensare ad esempi, e presto è diventato chiaro a entrambi che le complessità sociali sulla maggior parte dei progetti che avevamo conosciuto semplicemente sminuivano qualsiasi vera sfida tecnologica che i progetti avevano dovuto affrontare. affrontare. E poi, inevitabilmente, abbiamo dovuto affrontare qualcosa di molto più sconvolgente: mentre probabilmente sapevamo nelle nostre ossa da molto tempo che la sociologia contava più della tecnologia, nessuno di noi due ci era mai riuscito. Sì, di tanto in tanto avevamo fatto cose che aiutavano i team a lavorare meglio insieme o che rilassavano le tensioni del gruppo, ma quelle cose non erano mai sembrate l'essenza del nostro lavoro. Come avremmo fatto diversamente se ci fossimo resi conto prima che il lato umano contava molto più del lato tecnologico? Abbiamo iniziato a fare liste. Avevamo a portata di mano acetati vergini e penne a stagnola, quindi abbiamo messo alcuni degli elenchi su diapositive dall'alto e abbiamo pensato vertiginosamente di presentare effettivamente alcune di queste idee al nostro pubblico di Sydney. Che diavolo! Sydney era a mezzo globo di distanza dagli Stati Uniti e dall'Europa; se avessimo bombardato in Australia, chi l'avrebbe mai saputo a casa? Il nostro pubblico di Sydney la settimana successiva è stato immediatamente coinvolto dal materiale del peopleware, e un po' dispiaciuto (evidentemente non eravamo gli unici ad aver gestito come se solo la tecnologia contasse davvero). La cosa migliore è che le persone sono intervenute con molti esempi propri, di cui ci siamo allegramente appropriati. Ciò che separò quella prima prova fuori città dalla prima edizione del libro nel 1987 fu un sacco di lavoro tra indagini e studi empirici per confermare quelli che erano stati solo sospetti sugli effetti dell'ambiente (Parte II di questo terza edizione) e per convalidare alcuni dei nostri suggerimenti più radicali sulle dinamiche di squadra e sulla comunicazione (la maggior parte del resto del libro). Peopleware nelle sue prime due edizioni ci ha reso una sorta di punto di smistamento delle idee sul lato umano dei progetti tecnologici, e quindi il nostro pensiero ha dovuto espandersi per tenere il passo. Le nuove sezioni di questa terza edizione trattano alcune patologie della leadership che prima non erano state giudicate patologiche, una cultura degli incontri in continua evoluzione, team ibridi composti da persone di generazioni apparentemente incompatibili, e una crescente consapevolezza che, ancora oggi, alcuni dei nostri strumenti più comuni sono più simili ad ancore che a eliche. Per questa terza edizione, siamo in debito con Wendy Eakin di Dorset House e Peter Gordon di Addison-Wesley per aver modificato e modellato il nostro manoscritto. Grazie anche ai nostri colleghi di lunga data dell'Atlantic Systems Guild—Peter Hruschka, Steve McMenamin e James e Suzanne Robertson—per trent'anni di idee, brainstorming, dibattiti, pasti e amicizia.
