The proof of concept.

Poiche’ di questi “proof of concept” ultimanente ne vedi partire parecchi, sto iniziando a sospettare che il mondo delle grandi corporate stia per intraprendere una strada piuttosto inusuale (almeno , inusuale fino a qualche mese fa) , che non fara’ molto piacere a molte persone.

Per capire il problema, occorre capire un semplice concetto: l’overstaffing, cioe’ il sovradimensionamento delle risorse umane, nelle grandi corporate e’ un concetto ricorsivo. Non appena una squadra viene sovradimensionata, occorrera’ fornire mezzi organizzativi superiori, supponiamo per ipotesi piu’ office automation. Una volta fatto questo, occorrera’ assumere qualcuno che se ne curi. A questo punto, il reparto IT e quello , diciamo, “R&D” dovranno comunicare in qualche modo, e avranno bisogno di procedure. Occorrera’ quindi management. Il quale chiedera’ strumenti di management (altro office automation). Poiche’  tutta questa roba va comprata, bisognera’ ingrossare anche il reparto acquisti. Questo pero’ richiede altri flussi di comunicazione, altra office automation, e cosi’ via in un loop che ha come estremo superiore solo il budget complessivo. Se l’azienda e’ in crescita, questo loop puo’ assorbire qualsiasi budget venga concesso ai manager per i loro reparti.

Siccome la quantita’ di azioni possibili in un gruppo di N persone cresce come N al quadrato, e parliamo solo di azioni che non ne producano altre, l’azienda si trova a costruire un gigantesco digrafo colorato , e ogni attivita’ che coinvolge altri settori rischia di avere uno svolgimento di complessita’ “pericolosamente non polinomiale”. Aziende come IBM o Citibank sono arrivate ad usare tecniche markoviane per determinare …. i flussi interni meno inefficienti, tecniche senza le quali rischiavano “successoni” come OS/4 V4(2)

Dico “meno inefficienti”  perche’ in queste condizioni l’efficienza delle aziende e’ catastroficamente bassa. Non appena aumenta esponenzialmente il personale, il lavoro si prcellizza terribilmente, e i tagli dei costi vengono effettuati semplicemente sostituendo personale molto specializzato con impiegati scimmieschi. Poiche’ il personale e’ sempre piu’ scimmiesco, occorre sempre piu’ burocrazia per evitare che si facciano male da soli, e sempre piu’ middle management che spieghi loro ad usare la sedia nel modo giusto.

Quello che mi sembra stia succedendo e’ che gruppi sempre piu’ numerosi di giovani manager sta sfidando le gerarchie dicendo “scommettiamo che con una piccola squadra , senza fare processo, riesco ad ottenere le stesse cose che fate voi?” Sottinteso “a costi che (nonostante il costo degli specialisti sia molto alto) sono sempre attorno al 5% rispetto ai costi normali.”

Mi ritrovo a far parte di uno di questi esperimenti. Il lato umano di questo esperimento e’ devastante, perche’ mi ritrovo (e tutta la squadra che lavora con me si trova) in una situazione che oscilla tra l’odio ben mascherato e il sabotaggio vero e proprio.(3)

Il sistema cui sto facendo da ostetrica prende il posto di una ventina di sistemi, uno per nazione. Ognuno di questi sistemi necessitava di un team in loco e di uno qui, piu’ il management , piu’ tutto. In totale, quasi 500 persone tra interni e consulenti.

Il manager che sta sfidando l’universo intero ha intenzione di dimostrare che con sei persone resce a mettere su un sistema che fa quello che prima necessitava di 500. E non sto scherzando.

Il vero problema e’ che, effettivamente, ci stiamo riuscendo (e ho anche il tempo di badare al blog). Il trucco e’ che non ci serve processo, visto che siamo in un openspace. Non ci servono riunioni, perche’ siamo in un openspace. Non ci servono email, perche’ siamo in un fottuto openspace. Cosi’ facendo, ognuno di noi si occupa di un pezzo, ognuno di noi ha un backup, e in sei (due per frontend, due per middleware, due per outbound) riusciamo a gestire tutto.

Ovviamente anche i tempi di progetto sono drammaticamente brevi: a parte la qualita’ infima del software che viene sviluppato in maniera “eggiail”, il tempo di deploy sono “Uriel sta mettendo in piedi preproduzione oggi, e domani passa a produzione”. mentre prima erano “sei sette mesi per preproduzione, fino ad un anno per produzione”.

Il trucco non e’ che noi sei siamo magici. Il trucco e’ che siamo solo sei. Poiche’ esplorare un digrafo colorato aziendale e’ NP , la differenza tra 6 e 500 e’ enorme. L’altro trucco e’ che non siamo scimmie, ma questo lo spiego adesso quando parlo dell’interazione con i futuri trombati.

Il primo scontro avviene con quelli che “fanno processo”. Ecco una conversazione tipo:

• Ho bisogno di sapere chi ti triggera.
• Mah, certe volte Sarenna Lee mi “triggera” abbastanza. Che cos’e’ “triggera”?
• Intendo dire – con aria spazientita- chi ti dice cosa devi fare.
• Io SO cosa devo fare. Perche’ me lo dovrebbe dire qualcuno?
• Ma chi decide che le cose vanno fatte?
• Ci sono le pianificazioni. Nel piano la tl cosa va fatta per domani. E io la faccio per domani.
• E per le modifiche?
• Mi chiedono di farle.
• Chi?
• I PM del progetto: tizio, caio e sempronio.
• Solo loro tre?
• Ovvio, mica posso accettare richieste da chiunque.
• Non ricevi ticket?
• Ci mancherebbe altro che io passi ore davanti al sistema di ticketing.

Questo e’ il primo tipo di scontro che ho ogni giorno. Devo fare delle cose e le vado a fare. La conseguenza e’ che se rispetto i piani, tutto va bene. Siccome SO come si fa, non ho bisogno di qualcuno che me lo dica. E il risultato e’ che non ho bisogno di una decina di persone. Il guaio viene sul concetto di responsabilita’. Arriva un tizio dello stesso servizio che “ggestisce ” e “fa processo”, e la discussione e’ cosi’:

• Chi ti ha detto di chiedere a security l’auditing del software?
• Nessuno. Devo metterlo sui frontend, e SO che ci sta la sicurezza di mezzo. E’ corretto.
• Chi ha preso la decisione di coinvolgere security?
• Io ho parlato con il capo di security, e lui ha accettato il task.
• Ma chi ti ha detto di chiedere a loro?
• E’ UN FATTO generale che , in qualsivoglia sistema, il frontend e’ anche un elemento di separazione. Dunque, sicurezza.
• Chi l’ha detto?
• Le cose stanno cosi’ per chiunque faccia IT e abbia un Qi superiore a 15. E’ un fatto: frontend => sicurezza. Ti faccio un powerpoint?
• Si, grazie.(4) Ma rimane il fatto che nessuno ti ha detto di farlo.
• Sono SPOC di questo servizio. Non necessito di autorizzazioni.
• E se va male?
• Vae victis. As usual. Siamo consulenti, non piramidi egizie: possiamo venire rimossi.

Il secondo problema viene cioe’ dal fatto che la struttura elefantiaca e’ consepita per scimmie incompetenti e prive di visione di insieme. Io SO che se faccio cambiamenti sui frontend DEVO chiedere un qualche tipo di auditing alla sicurezza. Che il mio cliente si chiami Pluto , Paperino o Basettoni, che usi la tal cosa o la talaltra, il concetto e’ “non farai cambiamenti al frontend tuo senza chiedere alla sicurezza”.  Sempre. Punto.

Il problema e’ che per la scimmia incompetente “frontend” e’ una parola come un’altra. Esse soffrono di uno strano analfabetismo di secondo ordine, per il quale conoscono le parole del loro lavoro, ma non sanno che cosa significhino. Tutti sanno cosa sia un frontend, ma il loro livello di comprensione e di astrazione non arriva a classificarlo come “elemento di separazione” , per cui non riescono ad associarlo a “sicurezza”. Cosi’ come “framework”: essi sono capaci di fare riunioni e presentazioni parlando del proprio “framework”, ma non sanno veramente che cosa significhi, con il risultato che chiedono agli sviluppatori delle modifiche le quali potrebbero essere ottenute modificando la configurazione del framework stesso. Sanno che il loro sistema sia un “framework”, sanno che devono chiamarlo cosi’, ma non hanno idea del significato logico di questa parola: non sanno, cioe’, che se una cosa si chiama “framework” e’ possibile ricombinare la logica di servizio gia’ a livello di configurazione.

Cosi’, per loro il fatto che di fronte ad una modifica su un frontend io chieda l’auditing del software alla sicurezza e’ una “decisione” , dal momento che non ne vedono l’evidente necessita’. Il fatto che per chi non e’ del mestiere alcune azioni appaiano come “decisioni”, cioe’ come qualcosa che potevi fare o non fare, e quindi responsabilita’, e’ il primo tra i disastri che si ottengono quando si mette gente che non ha la preparazione tecnica adeguata a gestire il lavoro dei tecnici: cose del tutto banali e scontate sono, per loro, decisioni. E necessitano di tutto l’iter (riunioni, comunicazione, documentazione, flussi) per essere prese.

Questo ci riporta a bomba: una volta creato un overtsaffing, esso produce overstaffing, e la crescita dello staff produce altro staff, sino a quando il lavoro e’ cosi’ parcellizzato ed irresponsabilizzato che il CEO stesso si chiede “ma che cazzo devo fare, dare IO l’ordine di fare un auditing con la sicurezza?”.

Questo problema e’ noto come “micromanagement”, ovvero come la continua richiesta di tecnici poco preparati a middle managers poco preparati di produrre decisioni che non dovrebbero essere prese a livelli cosi’ alti. Il tecnico dovrebbe essere abbastanza esperto da saper comunicare da solo. Quando non lo e’, chiede ad un middle manager di venire “micromanaged”, cioe’ di ricevere da fuori le istruzioni che dovrebbe generare lui stesso. Il middle manger, che non sa prendere la decisione perche’ non ha idea dell’attivita’ e dei suoi risvolti tecnici, a sua volta deve far affidamento ad un flusso gia’ deciso che non capisce (”il processo di deploy di software sui frontend comprende un auditing alla sicurezza”) , oppure necessita di scalare ancora piu’ in alto la domanda, finche’ qualcuno non prende la decisione, fosse anche il CEO.

In una simile azienda, il livello di incompetenza non puo’ che scendere, perche’ a mano a mano che il numero di decisioni automatiche sale, diminuisce la necessita’ di decisioni personali. Questo permette di realizzare tagli al budget semplicemente assumendo personale sempre meno competente. Finche’ nessuno sa come fare a muovere una sedia, e si chiama un consulente esterno. Che e’ troppo competente er il piccolo management locale, e per gestirlo occorre un middle management a sua volta preso da aziende di consulenza. E alla fine, l’overstaffing produce DUE ovestaffing, uno di dipendenti ed uno di consulenti esterni.

Per questo, alcune aziende stanno facendo dei “piccoli test”, delle “proof of concept”: vogliono capire se il problema sia che serve piu’ gente (come sostengono le aziende di consulenza -per ovvi motivi- e il management interno -per motivi altrettanto ovvi- ) , oppure ne serva di meno.

In genere questa cosa non si nota, se non c’e’ nessun sindacalista o ex sindacalista in giro. Se c’e’ uno di questi elementi (e purtroppo io ne ho uno nelle vicinanze, un ex Ver.de)  la proof of concept viene immediatamente identificata come tale. A questo punto, il sindacalista fa il sindacalista, ovvero si mette a spargere voci di tagli per creare agitazione. La voce di tagli fa si’ che tutti si innervosiscano, e iniziino a cercare un capro espiatorio. E cosi’, piano piano cresce l’odio.

Sono “reperibile” giorno e notte da lunedi’, e nell’ordine:

• “Qualcuno” ha spento i DNS del mio servizio.
• “Qualcuno” e’ entrato nei sistemi e mi ha cancellato pezzi di software.
• I miei colleghi subiscono problemi del tutto analoghi.
• “Qualcuno” continua a rimuovere probes dal mio sistema di monitoraggio, per evitare che i guasti vengano individuati sul nascere.

Lo scopo di queste azioni di sabotaggio (5) e’ quello di dimostrare che il nostro team e’ troppo piccolo, e certamente se ci fosse qualcuno in piu’ a fare la guardia al software, esso non “scomparirebbe” dai dischi. A quel punto, il problema e’: in che modo reagire? Se io chiedessi alla sicurezza di mettere i sistemi sotto auditing, qualcuno della sicurezza riferirebbe al sindacalista di merda, e troverebbero altri modi per sabotare i sistemi.

Cosi’, ho semplicemente fatto una cosa: ho messo sotto auditing i sistemi da solo, prendendo una decisione della quale nessuno sa nulla, neanche “mister Ver.de”. E ho potuto esordire dicendo “fortunatamente i sistemi erano sotto auditing, e a cancellare i files e’ stato tizio”. Ovviamente mister Ver.de mi ha chiesto “chi ti ha dato ordine di accendere l’auditing?” (sottinteso: senza passare per le mie spie”) e ovviamente la mia risposta e’ stata che “se i files scompaiono dai sistemi, e’ un problema di sicurezza e bisogna fare hardening”.

In generale, sia io che il sindacalista sappiamo bene che guerra si stia conducendo qui: se riesco a tenere alzati i sistemi con 6 persone fino a marzo prossimo, quasi 300 persone andranno a casa ad Aprile.

Ecco, se vedete nella vostra azienda un “piccolo progetto”, che e’ “destinato a prendere il posto di quel grosso sistema”, e viene mandato avanti da poche persone, prendetelo pure come uno degli angeli dell’apocalisse. Perche’  e’ il prossimo trend nelle grandi aziende. Fatta la proof of concept, un ambizioso manager andra’ di fronte al CDA a dire “come mai a loro servono 500 persone e io con 6 faccio le stesse cose?”. Ovviamente non otterra’ subito il tagli di 494 persone. Ma in sede politica bisognera’ trovare compromessi, dunque al massimo di tagli ce ne saranno 200. Ma la cosa non cambia.

Vedo, sia nel mio progetto che in altri progetti ove sono finiti ex colleghi, i primi segni di un’inversione di marcia. Puo’ darsi che io mi stia sbagliando, ovviamente.

O forse no.

In ogni caso, sto diventando un esperto dell’arte di schivare coltelli.

Uriel

(1) Non so per quale motivo la mia azienda continui a vendermi per questo genere di attivita’ , non e’ la prima volta.

(2) Il flop di  OS/2 V4 fu un capolavoro di disorganizzazione interna. Mentre il settore sviluppo aveva completato un sistema operativo con le stese caratteristiche di stabilita’ di Windows NT , con un piu’ la completa compatibilita’ all’indietro e un’interfaccia pagaronabile a quella di Windows XP, il marketing aveva speso tutti i soldi per  altre attivita’. I due dipartimenti semplicemente non si parlavano, con l’eccezione del canale di distribuzione al pubblico, che inizio’ a creare una catena di partner per distribuire un prodotto sul territorio, peccato che nessuno sapesse nemmeno della sua esistenza.Sic transeat gloria mundi. Cosi’, decine di negozi (Vobis, Brain technology, etc) distribuivano Os/2 V4 , piu’ centinaia di applicazioni native, ma su nessun giornale , nessuna rivista del settore, niente, si faceva menzione ad esso.

(3) C’e’ gente che mi entra nei sistemi e cancella software che io ho installato, allo scopo di dimostrare che non siamo sufficienti a garantire stabilita’ al sistema. Fortunatamente i sistemi sono sotto auditing, e “misteriosamente” alcune di queste persone non hanno visto rinnovarsi il loro contratto a fine settembre.

(4) Un tempo, “ti faccio un disegnino” era un insulto. Oggi, “ti faccio un powerpoint?” riceve come risposta “si, grazie”.

(5) Il sabotaggio e’ un problema MOLTO SERIO delle aziende, per quanto sembri incredibile.