Gli operai del software

A partire dai primi lavori in gruppo all’università fino all’ultimo progetto per grandi aziende nel settore Energy e Trasporti una delle prime consapevolezze che ho maturato è stata l’importanza di fare squadra. In particolare nello sviluppo del software l’impatto della coesione, della collaborazione e soprattutto della cooperazione assume un valore molto particolare. Lo sviluppo
del software, se paragonato ad un’altra qualsiasi opera dell’ingegno umano, trae subito in inganno chi vuole cimentarsi in analogie e confronti. Quando si deve produrre un nuovo modello di automobile ad esempio, per grandi linee ci si immagina che un team di ingegneri si dedichi alla fase di progettazione, poi un gruppo di operai specializzati si occupa, con l’aiuto delle meraviglie dell’automazione industriale e della catena di montaggio in genere, di realizzare l’auto così com’è stata progettata ed infine il prodotto finale (l’auto appunto) viene immessa sul mercato. L’analogia con lo sviluppo del software che viene spontanea è: così come si progetta l’automobile si progetta il software (magari con strumenti di modellazione come UML o altro), poi un gruppo di professionisti si occupa di realizzare il software (ovvero i programmatori si dedicano all’attività di codifica) ed infine il software viene distribuito (consegnato al cliente oppure venduto attraverso i canali di vendita opportuni). Quindi viene da dire che il progetto dell’automobile è l’analogo dello schema UML, la costruzione dell’auto equivale alla programmazione e l’immissione sul mercato dell’auto alla distribuzione del software sul supporto opportuno (una volta il DVD, ora sempre più download o servizio in cloud).
Ma in realtà l’analogia non è corretta. Nell’ottica della catena di montaggio, il prodotto che si realizza in serie è in un caso l’automobile, nel secondo caso il DVD (ok, il DVD è quasi del tutto sparito, ma è per capirci), ma attenzione NON il software. In realtà l’analogo del progetto è il software, che poi viene distribuito (o reso disponibile) in varie copie. Il prodotto dello scrittore che viene venduto in libreria è il libro, l’opera di ingegno è il contenuto del libro. L’opera di ingegno nel caso dell’auto è il progetto dell’auto, così come l’opera di ingegno nel prodotto per la gestione aziendale è il software.
Da qui il facile errore di considerare le persone che si dedicano alla codifica degli “operai del software” (senza nulla togliere agli operai che fanno un mazzo così). E’ come dire che il circolo di intellettuali, poeti ed in generale artisti messo in piedi da Mecenate era un gruppo di operai dell’arte! All’università si parlava dell’arte della programmazione, oggi si vuole assimilare il programmatore ad un operaio. Eppure, la dizione corretta è sempre stata “analista programmatore”, qualcosa vorrà pur dire.
Un premio Nobel per l’economia del 2009 ha sostenuto che l’informatico non fornisce un bene duraturo, perché si tratta di un servizio, per cui la sua è un’attività esternalizzabile o comunque secondaria rispetto a chi gestisce o produce qualcosa. Quest’affermazione farebbe rabbrividire molti dei miei professori universitari. Anzitutto si confonde chi sviluppa software con chi si occupa
dell’esercizio o manutenzione (il sistemista). E’ come in un’azienda farmaceutica confondere il reparto amministrazione con la divisione ricerca e sviluppo. Ma per qualcuno il termine “informatico” è evidentemente omnicomprensivo.
In ogni caso chi sviluppa software produce eccome. Il sistemista gestisce eccome. Eppure un premio Nobel non riesce a capire che cos’è un informatico. Possiamo stupirci allora se un amministratore delegato si rivolge in una convention di neoassunti dicendogli che li considera gli operai del software?