La divisione del lavoro nello sviluppo software

Presso gli antichi Egizi, racconta lo storico greco Erodoto (5 secolo a. C.), i medici erano specializzati.
“L’arte della medicina è da loro [Egizi] divisa nel modo seguente: ognuno è medico di una sola malattia e non di più. Ogni luogo perciò è pieno di medici, perché ci sono i medici degli occhi, quelli della testa, dei denti, quelli delle malattie intestinali e quelli delle malattie incerte.” (Erodoto, Storie, libro II, 84).
Proprio come i nostri medici attuali. Anche se non abbiamo una specializzazione in malattie incerte. Se ne occupano i medici di base, i generalisti.
La divisione del lavoro, in termini generali e non specificamente legati allo sviluppo software, ha due ragioni d’essere. Da una parte, la complessità delle conoscenze necessarie per svolgere il lavoro. Dall’altra, le esigenze economiche ed organizzative, che mirano a contenere i costi e migliorare i risultati.

Specializzazioni su specializzazioni
Lo sviluppo software richiede conoscenze complesse, e questo è certamente un fattore che spinge a specializzare i ruoli. Capo progetto, analista, progettista software, specialista di data base, progettista di usabilità, programmatore, tester, sistemista esperto in software di base, eccetera.
Le specializzazioni portano spesso ad ulteriori specializzazioni. Analista? Analista business, analista di processi, analista di sistema, analista funzionale. Programmatore? Programmatore Java, programmatore Php, programmatore C; programmatore di interfacce utente (front-end), programmatore di servizi di back-end.
Ma per realizzare un sistema, per fornire i risultati attesi, sono necessari più tipi di conoscenza. Le diverse competenze, i diversi punti di vista devono incontrarsi e collaborare. Integrarsi. In ogni progettazione esistono conflitti di requisiti, situazioni di stallo, vincoli temporali ed economici, e bisogna prendere delle decisioni. E per prendere decisioni serve una visione d’insieme. Generale.
Negli ultimi anni è emersa, nelle organizzazioni IT più complesse, la figura dell’architetto software, come figura esperta e con un ampio spettro di competenze. L’architetto software deve riuscire a comprendere le diverse esigenze che provengono dagli stakeholder, le opportunità di business ed i vincoli tecnologici, ed è in grado di risolvere i conflitti e prendere decisioni grazie alla propria esperienza e capacità di sintesi.
Idealmente, si ispira alla descrizione dell’architetto (non software) fornita dal romano Vitruvio.
“L’architetto ideale dovrebbe essere una persona di lettere, un matematico, familiare con gli studi storici, uno studioso appassionato di filosofia, con conoscenze di musica, non ignorante di medicina, istruito sugli aspetti legali, familiare con l’astronomia ed i calcoli astronomici.” – Vitruvio, circa 25 a.C.
Non banale… Ma se guardiamo ad un’altra figura rilevante per i progetti di sviluppo software, l’analista, lo spettro delle conoscenze necessarie è anche qui molto ampio. L’analista può doversi occupare di problematiche di business, come di vincoli tecnologici e di aspetti legati alla sicurezza ed all’usabilità. Conoscere tecniche di analisi dei processi, progettazione dati, e notazioni varie (Uml, Bpmn, e così via). Padroneggiare tecniche di comunicazione, orali e scritte.

Unità basate su ruoli specialistici
La complessità dello sviluppo software può far ritenere che una forte specializzazione sia di fatto inevitabile.
Agli albori dell’informatica non era così. I primi programmatori lavoravano alla definizione del problema, progettavano la soluzione, la implementavano, la testavano, con poca o nulla divisione del lavoro. Come in molte piccole realtà di oggi. Massima flessibilità, niente burocrazia, contenimento dei costi.
Ma quando le piccole realtà hanno successo avviene, naturale, una crisi di crescita. Aumentano il carico di lavoro e il numero delle persone, diventa difficile tenere sott’occhio gli avanzamenti complessivi, si corre il rischio di perdere il controllo.
La risposta tipica è una nuova organizzazione del lavoro. Che a livello potenziale può essere effettuata in modi diversi. Ma spesso, nel software, consiste in una specializzazione dei ruoli.
Dal punto di vista di chi deve gestire un’organizzazione complessa, la specializzazione comporta dei vantaggi. Se definisco con precisione i singoli ruoli, posso anche definire procedure standardizzate e misurabili per chi deve svolgerli, individuare percorsi formativi specifici, effettuare selezioni professionali mirate.
Il problema sta nel come far interagire al meglio i ruoli distinti, per contenere i costi e massimizzare i risultati.
Una scelta possibile è quella di definire delle unità organizzative basate sui ruoli: l’unità dei capi progetto, quella degli analisti, quella degli sviluppatori. Il rischio è che queste unità omogenee si cristallizzino in silos organizzativi, ciascuno dei quali tende ad ottimizzare localmente le proprie attività (il “proprio orticello”), a scapito dell’ottimizzazione globale. I silos tendono di solito a rapportarsi tra loro in modi formalizzati, basati soprattutto sulla produzione di documenti formalizzati, in una logica seriale di catena di montaggio che nel mondo dello sviluppo software corrisponde ai processi a cascata, fortemente burocratici.

Gruppi multifunzionali e competenze a T
Una risposta alternativa al crescere della complessità organizzativa è quella della ri-composizione dei ruoli, come nel caso di extreme programming, dove l’unico ruolo riconoscibile all’interno dei team è quello di sviluppatore (programmer).
Un’altra possibile soluzione ai rischi dell’iper-specializzazione consiste nella costituzione di gruppi di lavoro multifunzionali, in cui partecipino i diversi ruoli specialistici, e in politiche di gestione delle risorse che favoriscano lo sviluppo di “competenze a T”, metafora usata nelle assunzioni del personale per descrivere le abilità delle persone”. La linea verticale della T rappresenta la profondità delle competenze e delle esperienze in uno specifico settore, mentre la linea orizzontale rappresenta l’abilità di cooperare con esperti di altre aree, e di usare in modo appropriato concetti propri degli altri settori. Un’abilità indispensabile per portare i partecipanti ai team a farsi carico, quando necessario, anche di compiti non strettamente legati al proprio ruolo. E a perseguire il successo dei progetti con un modo di operare collaborativo e integrato.

* Adriano Comai, esperto in metodologie di sviluppo software, www.analisi-disegno.com