2.1
La programmazione
Nella galassia aziendale di Bangalore, e in particolare nelle imprese di servizio, si riscontra ricorrente una strutturazione fondata su una specializzazione che ruota intorno al settore economico, tipo di prodotto e/o area geografica di riferimento. A prescindere dalla maggiore o minore autonomia delle divisioni (verticals, unità di business) in cui viene articolandosi l’azienda al proprio interno – mediante accentramento ovvero decentramento di determinate funzioni –, si ritrovano comunque ulteriori segmentazioni in strutture di line e di staff: le prime, propriamente produttive; le seconde, concernenti funzioni indirettamente strumentali a quelle. Pressappoco comuni nelle finalità, se non anche nella nomenclatura, ritroviamo nelle multinazionali dell’industria informatica strutture di Presales, Sales, Delivery, Quality (o Support). Le prime due sono funzioni di vendita finalizzate rispettivamente a procacciare nuovi clienti e nuove idee e a gestire le relazioni con questi prima e dopo lo sviluppo del prodotto informatico (esercitando anche la verifica della qualità rispetto alle determinazioni contrattuali assunte). Le ultime due, invece, sono volte alla realizzazione del prodotto in senso stretto e all’assistenza postvendita, durante la sua implementazione presso il cliente.
Ai fini della mia analisi mi concentrerò principalmente sulla fase di Delivery, cioè sul complesso di attività mediante le quali si sviluppa il prodotto informatico, essendo le altre, seppure importanti, in ultima analisi strumentali e secondarie rispetto a quella. Pertanto lambirò le altre solo nella misura in cui risulteranno propedeutiche all’esplicazione dell’avvio e della piena conclusione del processo di sviluppo del software.
Come introdotto nei paragrafi precedenti, nel distretto tecnologico di Bangalore lo sviluppo di programmi informatici ha assunto le dimensioni e l’organizzazione scientifica proprie dell’industria; ragione per cui è venuto a fregiarsi, e non a caso, esplicitamente di questo epiteto. Concretamente questo significa che le procedure inerenti al processo produttivo vengono ad essere estremamente dettagliate, o meglio ancora, standardizzate, al punto da risultare trasversali a tutte le diverse realtà aziendali, a prescindere che si analizzi un’azienda piccola o una grande, una multinazionale straniera o una indiana. Quanto sto per descrivere rappresenta, per l’appunto, un modus operandi diffuso, scontato e condiviso.
La più datata, consolidata e basilare modalità di sviluppo di prodotti informatici, insegnata nelle università come ciclo di sviluppo del software, infatti, è quella conosciuta con il nome di Waterflow methodology. Discover, Define, Design, Coding, Testing, Quality, sono gli step
145 fondamentali in cui si articola, e alla cui analisi – dopo l’introduzione alle fasi che ne precedono l’implementazione – sarà dedicato il paragrafo successivo.
2.1.1. Fase preliminare e ciclo di vita del software
Per la conclusione di un contratto e l’avvio di un nuovo progetto avente come scopo la produzione di un software, vi sono alcuni passaggi preliminari che rinvengono nei team di Presales e Sales le strutture fondamentali. Volendone proporre una distinzione di massima, direi che il primo gruppo ha competenze tecniche e dà luogo al primo contatto con il cliente, in cui espone i suoi servizi e le possibili soluzioni di business funzionali alle esigenze di questi.
Il secondo si compone di personale di natura commerciale incaricato, a fronte di un concreto interesse da parte del cliente, di una corrispondenza documentale con questi e di dare luogo successivamente ai contatti face to face, finalizzati alla conclusione del contratto vero e proprio e dei materiali collaterali.
Schematicamente, quando un potenziale cliente contatta l’azienda, dà luogo alla compilazione e all’invio di particolari documenti predisposti dalla stessa. Il cosiddetto Request for proposal è una richiesta di offerta che il cliente rivolge all’azienda (di solito a diverse contemporaneamente) per ottenere una proposta adatta alle proprie necessità. In seguito all’analisi di quest’ultima, il cliente potrà avviare una transazione, ma anche un'ulteriore negoziazione per definire in modo più chiaro termini e condizioni dell'offerta di fornitura.
Hema, responsabile per la funzione di Sales in Comtech, mi spiega che la risposta dell’azienda propone una soluzione che contempla tempistica, valore commerciale, numero di lavoratori e competenze necessarie per le richieste del cliente.
Segue quindi la fase di negoziazione, al termine della quale è sottoscritto lo statement of work, un contratto a cui si accompagna il non-disclosure agreement, documento in cui ci si vincola alla riservatezza delle informazioni inerenti al cliente. Mentre la proposta della soluzione è appannaggio del team di Presales, la sottoscrizione del contratto e degli allegati spetta al gruppo di Sales.
La conclusione del contratto segna quindi l’individuazione e l’accordo circa una soluzione di massima alle esigenze del cliente, ma per poterla articolare concretamente, si deve procedere ad una serie di incontri finalizzati a scandire in modo puntuale tale progetto sommario. Propedeutica alla fase di programmazione del lavoro da realizzare, quindi, mi spiega in dettaglio Vibha, giovane manager di Comtech, la Waterflow methodology si apre con la fase di «comprensione» delle necessità del cliente, a cui il software dovrà dare soddisfazione: Discover, insomma, è quella parte iniziale del lavoro in cui si chiariscono esattamente tutte le «specifiche» che il programma deve possedere. Specifiche che non sono chiare neppure pienamente al cliente nel momento dell’ingaggio e che, pertanto, devono essere «scoperte» mediante una intensa interazione face to face e telematica – discussioni, interviste, workshop, mail, videoconferenze, ecc. – con il cliente stesso, durante la quale, al di là dei documenti già prodotti, ogni singola richiesta viene tradotta in svariate pagine di spiegazioni.
La produzione di una corposa documentazione esaurisce questo primo momento, aprendo quindi a quello successivo di Define, cioè di definizione tecnica dello scopo del progetto lavorativo.
146 Fine di questo stato del ciclo di vita del software è quello di trasporre tecnicamente le richieste del cliente, dando luogo ad una sua «traduzione informatica».
Mentre nella prima fase vi è la predominanza di figure lavorative di Business consulting, cioè persone che hanno cognizione approfondita del settore di riferimento del cliente (altrimenti come comprendere le specifiche esigenze di questi?), la seconda vede la prevalenza del lavoro di figure tecniche: Software architecht, Software engineer, ecc. In entrambe, prende comunque parte il Delivery e/o il Product manager, figura di connessione tra le attività di Sales e quelle di Delivery, e referente generale per il prodotto.
In questo secondo momento viene, quindi, definita l’infrastruttura generale del software, i suoi vari elementi costitutivi, nonché la strumentazione tecnologica per la sua produzione: il linguaggio informatico scelto e i vari tipi di programmi e tool da impiegarsi in ciascuna fase. Se ciò avviene, sotto il versante produttivo, ad opera delle massime figure tecniche di riferimento, queste sono chiamate a coadiuvare, sotto quello organizzativo, il Delivery manager nella pianificazione dei tempi di realizzazione per ciascun modulo produttivo e ad individuare la necessaria forza lavoro da impiegare.
Di solito, infatti, si dà luogo ad una «lottizzazione» del lavoro totale: il progetto – che può coprire un periodo che va da alcune settimane a uno o più anni –, viene suddiviso in blocchi da realizzarsi sincronicamente, attraverso una divisone orizzontale di questi tra i diversi team, e verticale, nel tempo. Detto in altri termini, viene periodizzata la produzione dei vari pezzi di codice corrispondenti alle diverse funzioni: alcuni saranno scritti prima, altri poi, e, per ogni periodo, un modulo da ciascun sub-team.
La definizione degli elementi tecnici e dell’organizzazione generale del lavoro viene seguita poi dalla fase di dettaglio del lavoro: il Design. Qui, l’infrastruttura individuata dalle figure tecniche superiori viene ad essere ulteriormente articolata da personale, anch’esso tecnico ma di livello medio (i codificatori non partecipano a questa fase, ma principalmente si tratta di Technical lead e/o Team lead), che provvede alla specificazione del cosa deve essere fatto e come.
Sebbene vi tornerò ampiamente in seguito, ritengo utile sottolineare che quanto appena descritto ci lascia già intuire un processo di programmazione e di consustanziale segmentazione dell’attività produttiva nelle sue componenti elementari, che ricalca, proprio per tale ragione, la modalità di organizzazione tayloristica del lavoro.
Procedendo con l’enucleazione degli step del processo di produzione del software, mediante l’esecuzione di quanto elaborato e predisposto nelle fasi precedenti, arriviamo quindi alla fase vera e propria di «produzione» del software: lo sviluppo.
Il Develop è il momento di codifica del programma, cioè di elaborazione delle linee di codice mediante le quali il software sarà in grado di svolgere le funzione per cui è progettato (vengono fisicamente scritti i codici che rispondono alle diverse funzioni). È questa la fase in cui entra in gioco la forza lavoro più massiccia numericamente, codificatori e tester. I primi programmano il codice; i secondi validano la sua funzionalità.
È bene precisare a questo punto che con i termini Testing, validazione, controllo qualità, si intendono più processi, alcuni dei quali possono essere considerati propriamente interni a quello di produzione tout court; altri, successivi e di «garanzia» della validità del software.
Rispetto ai primi abbiamo che oggetto di verifica sono infatti sia il singolo elemento (la parte elementare prodotta da un sub-team in una singola fase temporale), sia il software nel suo insieme, nonché la sua interconnessione con altri portali e programmi – cioè la sua
147 comunicazione con questi ultimi. Nelle realtà aziendali di grandi dimensioni tutto ciò viene svolto dal team di Testing che, laddove riscontri disfunzionalità, è tenuto a rimandare indietro il modulo al team di sviluppo che lo ha prodotto, affinché i cosiddetti bug vengano fissati, e quindi nuovamente rinviati per un successivo controllo, finché ciascun componente non risulti scevro da difetti e quindi risolto nel prodotto finale.
La validazione del software licenziato dall’ambito di produzione implica invece il passaggio del prodotto all’interno di altri due gruppi, di Sales e Quality, chiamati rispettivamente a controllare la rispondenza del programma elaborato alle specifiche richieste del cliente, contrattualmente definite, e a verificare il rispetto degli standard internazionali, se esistenti, per quella tipologia di software (tempo, costo, risorse impiegate, ma anche numero di linee di codice, impiego di determinati programmi, ecc.). Si tratta dunque di un’attività di postproduzione ma precedente alla consegna del prodotto, con il cui avvento viene comunque a garantirsi, per qualsiasi problema, una pronta assistenza.
Quanto appena descritto rappresenta la modalità organizzativa classica e standard del ciclo di sviluppo del software, che però, in tempi più recenti, ha visto l’elaborazione di metodologie alternative che ne rappresentano un’evoluzione. Tra queste si colloca in una posizione privilegiata Agile, che ne rappresenta una variante (Vibha mi dice ad esempio che quando si usa la metodologia Agile, tutte le attività sono replicate settimanalmente su scala ridotta; la scelta della metodologia dipende dalla velocità con cui devi restituire al mercato il software). I passaggi sopra descritti, nella metodologia Agile, anziché svolti una sola volta, si ripetono continuamente per la realizzazione parziale e progressiva dei blocchi del progetto. Se la modularizzazione della produzione è presente anche nella fase di sviluppo della Waterflow methodology, qui la lottizzazione è più marcata perché non concerne solo lo specifico della fase di sviluppo, bensì riguarda anche quelle precedenti, consentendo di consegnare al cliente parti autonome del prodotto complessivo finale, parallelamente al loro progressivo sviluppo.
Hema ha anche una lunga e pluriennale esperienza come Technical lead, in ragione della quale mi spiega che la scelta della metodologia da adottare dipende dal tipo di prodotto da realizzare. La loro più o meno ampia semplicità riflette la maggiore o minore semplicità della metodologia, nel senso che quest’ultima dipende dall’esistenza o meno di pre-packeges: per i prodotti più consolidati sono disponibili pacchetti che contengono già sequenze di codice (eventualmente da integrare e/o modificare, offrendo in pratica un prodotto in parte preconfezionato). Detto in altri termini, per certi prodotti software, abbiamo un livello di consolidamento del processo di produzione, cristallizzato in procedure meticolosamente standardizzate, non come sequenze di fasi da dettagliare, bensì come stadi in cui ogni cosa da fare è esattamente specificata (bisogna solo seguire le istruzioni). Ovviamente, queste ipotesi concernono prodotti informatici molto comuni, collaudati. Laddove si richieda un prodotto molto lungo, complesso, e/o innovativo (per le quali non siano disponibili «istruzioni» da comprare e seguire alla lettera), è preferibile adottare la metodologia Agile.
Dal punto di vista temporale della produzione globale Hema mi dice che in media, e prescindendo dalle procedure di produzione eseguite, il 10-20 per cento del tempo è dedicato ai primi due step, Discover e Define, mentre il 40 per cento è speso in Design. Il Develop e il Testing prendono poi, rispettivamente, il 30 per cento e il 20 per cento del tempo restante. In questo paragrafo ho accennato all’instaurazione del rapporto tra cliente e azienda e introdotto al ciclo di vita del software, ossia alle diverse fasi in cui si articola la sua produzione. Di seguito
148 ne approfondirò alcuni aspetti, focalizzandomi in primis sull’attività endoprocedurale di programmazione dei tempi, assegnazione risorse e segmentazione del lavoro, per proseguire quindi con la descrizione del momento esecutivo vero e proprio.
2.1.2. La programmazione e la selezione dei lavoratori
Subito dopo la conquista del cliente, e prima della produzione in senso stretto, si colloca la fase di programmazione. Ad aprirla, e ai fini dell’attivazione delle risorse umane, tecnologiche e logistiche necessarie, è un breve incontro con diversi stakeholders, competenti per le corrispondenti strutture di supporto. Questo incontro, della durata di trenta-sessanta minuti, prende il nome di Kickoff meeting e vede la partecipazione del capo dell’unità di business, della sezione Finanza, il Central Resource pool del dipartimento HR, e la struttura logistica. Chiamati a prendere visione del progetto, essi concorrono, ciascuno in ragione delle proprie prerogative, a licenziarne sommariamente e collettivamente gli aspetti fondamentali. A questo punto è il Delivery manager a compilare una folta documentazione e ad inserire le informazioni relative al progetto nel sistema informatico aziendale. Al di là dell’irrinunciabile tracciamento informatico di qualsiasi cosa si compia nell’azienda, questa operazione è anche funzionale all’ottenimento di una successiva e necessaria approvazione delle strutture coinvolte nella fase iniziale, rendendosi il loro avallo indispensabile per poter dispiegare la fase esecutiva.
Mentre il responsabile del progetto produce la sua documentazione, le altre strutture coinvolte predispongono parallelamente le attività di loro competenza: oltre all’allestimento dei locali e all’attivazione delle risorse economiche necessarie, vengono individuati i soggetti da coinvolgere nel progetto, mediante reperimento degli stessi dall’interno, ovvero, ove si renda necessario, dall’esterno.
Rispetto a quest’ultima macroattività, si sottolinea che, per il personale interno, è sufficiente consultare un apposito database in cui sono inserite competenze ed esperienze pregresse di tutti i dipendenti a tempo indeterminato, nonché la loro disponibilità immediata ovvero la data di ultimazione del progetto in cui sono impegnati. Laddove si individui la necessità di figure particolari, ovvero per i lavoratori a progetto – che vanno a coprire le fasi della codifica e del Testing –, si ricorre alla selezione esterna o all’outsourcing.
In questi ultimi casi, a fare da guida per l’individuazione del personale da scegliere è sempre la Job description, mentre molteplici sono i canali per ottenere nuovi curricula: direttamente dal proprio sito; mediante Personal referral, cioè referenze da parte di persone che lavorano già per l’azienda; attraverso mega selezioni presso i campus universitari; ricorrendo al network di Head hunting, ossia rivolgendosi ad agenzie specializzate; ovvero assumendo lavoratori interinali. Le tecnologie telematiche, in particolare, semplificando ed espandendo le possibilità e le opportunità per i processi selettivi, rendono molto celere il processo di reperimento della manodopera e del tutto superflue le eventuali distanze geografiche.
Grazie anche agli input di altri soggetti, quali Business analyst e Technical lead, mi spiega Vibha, la redazione del progetto nelle sue linee essenziali richiede solo una settimana per essere elaborato, mentre per il suo dettaglio ci si affiderà all’interazione con il cliente su tempi più lunghi. Il suo team, le persone che dirige, se non con rare eccezioni, non partecipano a nessuna
149 delle attività fin qui svolte. Quanto appena descritto, infatti, è appannaggio esclusivo del manager e di altre figure posizionate in alto nella gerarchia aziendale e rappresenta una fase preliminare e propedeutica all’inizio di quella esecutiva. Così, continua Vibha, una volta dettagliati i piani di lavoro, «ci atteniamo al progetto così come è stato concordato con i vertici aziendali e ci incontriamo periodicamente con un cliente per capire quello che dobbiamo fare giorno per giorno». Dalla prospettiva del Delivery manager la ruotine lavorativa di qui in avanti consiste, insomma, in una diaria valutazione dello stato di avanzamento del lavoro, e, quindi, della corrispondenza di questo con quanto precedentemente pianificato.
Alla luce di ciò, si produce poi un’attività di reporting, states review, su base settimanale, mensile e quadrimestrale (a seconda degli accordi con il cliente e anche con gli altri stakeholders), in favore di vari soggetti interni ed esterni all’azienda.
Se questa è l’organizzazione dell’avvio del progetto in una realtà aziendale strutturata in Unità di Business indipendenti, del tutto simile è l’impostazione del processo lavorativo nelle imprese che adottano un modello a matrice, in cui si producono non solo le stesse dinamiche, ma anche i medesimi ruoli e gerarchie.
Il giovane Rajesh a soli trentasei anni è uno dei Delivery manager per l’unità Healthcare&Lifescience di Hopro. Mi spiega che si occupa del processo che porta alla consegna del prodotto al cliente, e cioè dell’esecuzione del progetto, controllando risorse e tempi, e incontrando i clienti su base periodica. A livello gerarchico sotto di lui ci sono, sul versante tecnico, i Solution architect, e su quello organizzativo, i Project manager, competenti ciascuno per un singolo progetto. Al di sotto di questi ultimi ritroviamo i Team lead, che sovrintendono ad una specifica area di produzione. Complessivamente, Rajesh è responsabile del lavoro di settanta persone coinvolte in diversi progetti, tutti relativi all’ambito farmaceutico e ospedaliero.
Nella sua ricostruzione del processo lavorativo, afferma che il software da sviluppare dipende dalle richieste del cliente. Se ad esempio si tratta di un programma relativo alla Supply chain, in via preliminare due o tre consulenti analizzano la catena del valore e quindi propongono raccomandazioni per lo sviluppo del software (ad esempio ci possono essere attività fatte manualmente che prendono tempo e possono essere automatizzate, oppure il cliente dispone di vecchie applicazioni che necessitano di sostituzione o miglioramenti).
Quando è stato effettuata l’analisi, il lavoro passa al Delivery team. Qui si valuta come approcciare tecnicamente l’intervento e si scelgono le metodologie da impiegare, si trovano le risorse e si creano i team. Fatto ciò, ed individuate le esigenze del cliente, si ricorre alle strutture orizzontali per ottenere le risorse necessarie.
Il gruppo Operation, chiarisce Ramesh, individua le risorse umane, con le skill necessarie, muovendole da un progetto all’altro su richiesta del Delivery manager e valutandone, in un una fase preliminare, l’efficacia in termini di profitto previsto dal progetto elaborato da quest’ultimo e, in itinere, la rispondenza dei costi preventivati a quelli effettivamente sostenuti.
Si noti a questo punto che il Delivery manager predispone in pochi giorni un programma per il progetto e, dato il fatto che i diversi lavori sono molti simili tra loro e che l’azienda detiene una esperienza corposa e registrata di quelli pregressi, risulta che il suo lavoro di programmazione sia poi non troppo sofisticato e complesso, e neppure particolarmente creativo. Oserei dire che quasi risulta essere «routinario», tanto nella fase a monte, quanto in quella a valle della verifica puntuale e costante dell’andamento reale del lavoro. Lo stesso controllo ex ante, in itinere ed ex post del suo lavoro, da parte di altre strutture, tende poi a circoscrive ulteriormente le prerogative
150 e i poteri del suo ruolo. Se così è per lui, a maggior ragione si potrà facilmente intuire come il margine di autonomia e discrezionalità del Project manager non sia particolarmente ampio: il