Il Manager di Star Trek (post nerd)

Talvolta si ha come l'impressione, che a fare il Manager siano buoni tutti.

Certo è solo l'impressione, perchè la capacità di cogliere criticità e opportunità, di capire le persone e organizzare i tempi per la realizzazione, accordarsi con il cliente, tenere sotto controllo i margini di guadagno... sono cose per cui serve una preparazione accurata...
O forse no?

Avete mai la sensazione che il Manager sia come un personaggio della serie di Star Trek?
Tutto in Star Trek è ragionevole: la fisica, i veicoli, le procedure, le strumentazioni...
E anche il manager sembra sempre capire cosa fare, quando farlo e quanto tempo metterci, anche quando non si sa in realtà COSA bisogna fare!

Ti attacca una nave da guerra Klingon, tu sei risucchiato in un buco nero con lo scafo in avaria? Beh, metti tutta l'antimateria rimasta sugli scudi, e fai un lancio nell'iperspazio utilizzando i siluri fotonici! ... Dubbi? Noooooooo! Certo che funzionerà!

Quando un Manager parla ho sempre la sensazione di avvertire questa frase nella testa: "Metti tutta l'antimateria sugli scudi". Sembra una cosa che nei film di Star Trek funziona sempre, ti cava d'impaccio e non ti fa arrivare tardi agli appuntamenti e ovviamente ha quel suono dolce del plausibile... Certo a volte serve che l'ingegnere capo annodi i condotti di antimateria con lo scotch, ma una soluzione nei momenti critici si trova sempre!!!

Technical Manager: Vanno realizzati dei servizi per accettare richieste da tutte le imprese italiane? Questa è la richiesta del cliente? E come facciamo?
Manager: Usiamo un cluster di macchine e realizziamo una architettura scalabile all'infinito
Technical Manager: Ma ci sono cose che non si possono parallelizzare: le funzioni di contabilità va eseguita nell'ordine di arrivo!
Manager: Creiamo allora delle strutture condivise di gestione intelligente del parallelismo
Technical Manager: Ma non abbiamo questa infrastruttura!
Manager: Le sviluppiamo da zero
Technical Manager: In due settimane?
Manager: Dimmi quanti sviluppatori servono che li chiamiamo
Technical Manager: Ma questa attività è piuttosto complessa, è praticamente impossibile suddividerla e in così poco tempo... mica stiamo costruendo un muro...
Manager: Metti allora tutta l'antimateria sugli scudi
Technical Manager: Ah, questo non lo avevo considerato: proviamo!

Poi voi imprese che usate i servizi sviluppati per voi in due settimane, senza infrastruttura e creando da zero qualcosa che aziende come Oracle fanno pagare centinaia di migliaia di euro: non vi lamentate!

Deve essere qualche rimasuglio di antimateria che ancora gira nel software con l'amena forma del cetriolo.

Lo sviluppatore/fornitore non può dire di no al cliente

Che titolo inutile è questo: certo che il cliente deve dire la sua... è lui che tira fuori il denaro? Ci mancherebbe solo che non avesse potere decisionale!

Ecco, non è proprio per il fatto che il cliente detta i requisiti il problema.
Il problema è che il cliente (a seconda dei casi) può soffrire di manie di grandezza e voler decidere dell'applicativo sviluppato, anche i nomi delle tabelle.

Ma il problema sta qui?
No, non sta neanche qui il problema.
Il problema è il buco nero che il cliente ha nel cervello... scusate mi sono lasciato andare. Il problema è quando il cliente chiede, propone e insiste che delle incoerenze inconsistenti siano "volontariamente" messe nel software.

Per esempio a noi fu chiesto che fossero levati tutti i controlli sui dati che a ragione avevamo messo. Quando facemmo presente (in modo molto convincente) al cliente che così facendo avremmo permesso l'introduzione di errori che difficilmente avremmo sanato, lui ha glissato dicendo che si prendeva la responsabilità ( ah ah ah, questa è un ossimoro per un dirigente della pubblica amministrazione: nessuno si prende mai la responsabilità!!! era un mero scherzo verbale ) e che "avanti tutta"!

Inutile dire che il sistema ebbe un tracollo, la parte di business intelligence rilevò dati dell'anno 1 dopo Cristo, che alcune fatture erano pari al debito pubblico italiano e così via.
Ma chiedere di fare un software con un bug evidente è una cosa: lo sfacelo è visibile da tutti, ma magari anche i fornitori ci godono perchè verranno pagati per risolvere bug (sempre che questi siano risolvibili...); mentre fantasticare sulle interfacce è un'altra ed è una tentazione molto più subdola per il dirigente di turno.

"Possiamo fare una barra laterale attraverso la quale uno sceglie la sua casella?".
Tu che sei un analista funzionale capisci che ormai il cliente parla per analogia di cose già viste. Ti chiedi se pensa all'interfaccia di Gmail o di Outlook, ma tanto sai che non puoi farlo.
L'interfaccia deve avere una coerenza interna, le leggi dell'usabilità sono poche e semplici e se il resto dell'applicativo non ha quella logica, buttarla in quella singola funzionalità impedisce all'utente finale di capire come usarla!

Ma no, a lui piace la barra laterale, e allora "l'ha chiesto il cliente".
Si convince il povero sviluppatore a strappare a morsi pezzi di infrastruttura, accroccare una grafica improbabile e mettere su due procedure che facciano il minimo sindacale per mostrare quella INUTILE BARRA LATERALE!!!

Ma dove è finita la professionalità del programmatore?

E'come se quando mi venisse l'idraulico in casa, io sono quindi il cliente, al momento di smontare la tazza del bagno io gli intimassi di usare il cacciavite da orologiaio, perchè a me piacciono i lavori di fino anzichè lo strumento che sta usando lui.
Secondo voi l'idraulico come reagirebbe?
Perchè il programmatore è trattato peggio di così?

Technical manager buono e Technical manager cattivo

Come nei migliori film, nei migliori progetti per la pubblica amministrazione si gioca al Technical manager buono e Technical manager cattivo.

Dico si gioca perchè a differenza degli Stati Uniti, in Italia non esistono rigide gerarchie di skill ma ognuno si improvvisa quello che può, come può.

Un giorno ti svegli e sei il Project Manager, o il Team Leader, oppure ti capita di dover cambiare il berretto, di sviluppare e/o parlare con il cliente. Il tutto come alla Corrida: "dilettanti allo sbaraglio".

Ma non voglio distruggere come al solito, oggi voglio costruire!
Vorrei volare da sviluppatore nel mondo rosa confetto in cui le cose vanno come vorrei e parlarvi del Technical manager perfetto (ne ho conosciuti)!

Il Technical manager dovrebbe non solo coordinare un team di sviluppo ma anche relazionarsi con il management e capire o trasmettere correttamente i tempi e i costi.

• Capisce di tecnologia a differenza del Project Manager che potenzialmente dovrebbe sapere gestire lo sviluppo di un progetto  software come un cantiere edile

• Se le cose vanno male è lui che ci rimette, non gli sviluppatori (lui ha sbagliato i calcoli, lui al più si siede e sviluppa il software nel week end se gli è richiesto o dopo l'orario di lavoro).

• Si prende la responsabilità e (se è magnanimo) ridistribuisce gli onori (in fondo il software non lo ha sviluppato lui). 

• Combatte fianco a fianco del gruppo di sviluppo per riportare il management sulla retta via e far capire (più che semplicemente comunicare) quali sono i tempi reali che ci si può aspettare per fare qualcosa.

• Sa dire di no: se una cosa la si può fare in due settimane, non scende a una settimana; piuttosto dice che non si può fare.

• Delude il management che vende l'anima al cliente salvo poi sentirsi dire che le richieste non sono realizzabili

Se ci penso bene, un buon technical manager altro non è che un buon padre di famiglia!

Documenti inutili

Talvolta sento persone che si preoccupano dell'utilizzo della carta.
Beh, in caso di progetti della pubblica amministrazione, la carta non è un problema.

Ogni progetto software prodotto deve essere accompagnato durante tutto il periodo del ciclo di sviluppo da una serie di documenti: l'analisi, il disegno, i requisiti funzionali, il piano di test, il documento di integrazione, il documento di adeguamento esercizio...

Di per se tutti questi documenti hanno un senso: servono a chi coordina, a chi progetta, a chi sviluppa, a chi deve testare il funzionamento, a chi dovrà un giorno prende in mano il software per correggerlo o evolverlo.
Purtroppo però non è questo che si fa!

Tutto si riduce a riunioni con 37 persone in cui solo 2 persone si parlano (perchè sono le due persone che realmente faranno il lavoro); riunioni interminabili in cui non esce assolutamente nulla se non la data di quando rivedersi; riunioni che sono battaglie politiche fra diversi schieramenti (ne parlerò in un altro post). Da queste riunioni esce una serie di appunti, che poi si tramandano a voce e che il gruppo che sviluppa il software invece non recepisce quasi mai.

A chi produce software si racconta la cosa a voce, magari con schizzi su fogli di carta che vengono poi serbati come gioielli in scrigni (essendo l'unica cosa che spieghi in un qualche modo abbozzato cosa il software debba fare). Le idee cambiano spesso, ma i documenti no, quelli si fa la corsa a scriverli solo quando li si deve consegnare e il software è già bello che fatto da tempo.

I documenti che si producono sono quindi assolutamente inutili.
Il documento dei requisiti è sempre obsoleto e sono chiacchiere (in quanto abbozzato e lasciato così, tanto chi lo deve leggere?).
I piani di test non li vede nessuno, sono uno strumento politico; se un giorno quancosa non funziona, la pubblica amministrazione deve trovare il modo di dimostrare che così non doveva essere quindi, solo allora prenderà il documento e cercherà in tutti i modi di sfruguliare l'applicativo per farlo esplodere.
Il documento di analisi è una chimera; viene scritto alla fine chiedendo proprio a chi ha sviluppato il software come questo funziona (ma allora "l'analista funzionale" che ci sta a fare? ma questo è oggetto di un altro post).
"Scusa ma dopo aver inserito i dati anagrafici, non facevamo firmare qualcosa?", "No, a giugno ci avete detto che bastava cliccare su ok"...
"Va bene allora aggiorno il documento".

Ma del resto come biasimare il dirigente della pubblica amministrazione?
Voi vi leggereste un documento di 200 pagine con un titolo una descrizione, precondizioni e postcondizioni (che il più delle volte fanno ridere)?

titolo: login
precondizione: l'utente va alla pagina login.html
azione 1: l'utente mette username nella casella username
azione 2: l'utente mette la password nella casella password
postcondizione: username e password sono corretti
risultato: l'utente entra nella pagina privata del sito
Maddai!!!!

Immaginatevi di dover leggere e mettere il bollino su 200 pagine così....
Lo fareste?

Il modo in cui viene scritto il software non lo decide il gruppo di Sviluppo, ma il Cliente

La mia società ha sviluppato software per centinaia di migliai di euro per la pubblica amministrazione ma chi ha deciso come dovesse funzionare (non solo le funzionalità che doveva avere), soprattutto quelle più inconsistenti, assurde e balzane è stato il Cliente.

Vi lascio intendere le cose con una scenetta:
Cliente: "Bisogna costruire un razzo"
Analista: "Benissimo, dove lo dobbiamo mandare? Luna? Marte?"
Cliente: "Non saprei, basta che voli, poi vediamo"
Analista: "Abbiamo già una rotta? un centro di controllo? C'è un posto dove possiamo lanciarlo?"
Cliente: "Purtroppo non ho informazioni al momento, ditemi che vi serve e vedo se riesco a procurarlo".
A questo punto l'Analista si sente come un pusher a cui è stata chiesta una qualche non meglio identificata droga all'ultimo grido, di cui non sa nulla e va dallo Sviluppatore che dovrebbe fabbricargliela.
Analista: "Bisogna costruire un razzo che voli"
Sviluppatore: "Usiamo metallo o acciaio? Quanto deve reggere di carico? Dobbiamo trasportare uomini o macchine pesanti?..."
Analista: "Non so dirtelo in questo momento: tu inizia a costruire qualcosa, e non discutiamo troppo: l'ha chiesto il cliente"

La frase "l'ha chiesto il cliente" ha lo stesso tono e valore di quello che in ambito militare significa "è un ordine": si sta zitti e si obbedisce.

Non hai capito?... non importa
Non sai a che serve?... non importa
Non hai gli strumenti giusti?... non importa

La soluzione va accroccata perchè anche la tua società non vuole deludere il cliente e tanto, basta che passi il collaudo, che gli frega se poi gente reale dovrà usare il software...

 Questo è solo uno dei tanti esempi che aiutano a produrre la monnezza che rende inusabile il software, quindi impossibile la vita agli impiegati (che si stressano), quindi impossibile la vita al contribuente (che vorrebbe un servizio semplice, semplice)...

Vi dico solo che quando creammo un software che doveva prendere dei dati, mettemmo dei limiti: per esempio se mi registri una fattura di 100 euro non puoi effettuare pagamenti per 120 euro (su quella fattura).
Il Cliente trovò questo limite insopportabile...
Cliente: "Però se poi uno si è sbagliato a mettere la fattura da 100 ed era invece da 120?"
Sviluppatore: "Gli dite che i dati non erano corretti e vanno reinseriti"
Cliente: "Nooooo, troppo difficile, facciamo che glieli facciamo inserire lo stesso e mettiamo degli avvisi tipo rosso fuoco per far capire che ha messo troppo... ma non lo possiamo bloccare".
Sviluppatore: "Ma così poi sarà impossibile fare i conti bene, far funzionare tutto il resto..."
Cliente: "Capisco ma voglio sia fatto così, grazie!"

Morale

Per risolvere un problema che ha già una soluzione evidente, semplice, sicura, abbordabile e poco costosa viene IMPOSTA dal gradimento del dirigente del Cliente la soluzione stupida, costosa, e che genera altri problemi.

Consegne a Natale e Ferragosto (i premi produzione)

Alcune volte il progetto subisce brusche accelerate: si grida all'urgenza, si proclama che il software va consegnato per quella data, che magari è a Natale, a Ferragosto o durante qualche vacanza...
E tu che sei solo uno sviluppatore software ti chiedi: perchè?
Perchè c'è tutta questa urgenza di uscire con un software rappezzato a Natale? Sono tanti quelli che a Natale lo useranno? In fondo poi la scadenza per utilizzare questa funzione sarà a Giugno... perchè tutta questa fretta? perchè costringere gli sviluppatori a produrre pezze a colori sul software per farlo funzionicchiare?

Non si può aspettare di farlo con calma e bene? Farlo funzionante?
Eh no, si bisbiglia: ci sono i premi produzione...

Un dirigente della pubblica amministrazione prende dei premi se conclude nei termini gli obiettivi; terminare un obiettivo significa molto spesso terminare lo sviluppo di un software, non conta quando questo software viene usato, il premio va consegnato...

Facciamo solo un esempio: immaginate un nuovo software per il pagamento dell'IMU che ha il suo massimo utilizzo a Giugno; immaginate che il dirigente che se ne occupa ha un premio produzione a fine gennaio. Farà fare le notti agli sviluppatori a Natale e capodanno per consegnare un'accrocco che non funziona (e che non si sa ancora bene che deve fare) entro metà gennaio. Il prodotto esce in sordina, lui prende il premio e tutti se ne scordano. Poi 10 giorni prima della scadenza la gente comincia a usare il software, il sistema esplode e in fretta scattano le punizioni corporali per gli sviluppatori, che intanto erano su altri progetti e non sanno manco mettere le mani sull'accrocco che sono stati costretti a produrre; il fuggi fuggi alla ricerca del colpevole; ricerche di email e documenti in cui si spiegava cosa doveva fare il software (nessuno lo sa più) o email in cui si spiegava che certe cose (a causa di scelte del cliente) non avrebbero mai funzionato.

Ma in fondo poi che problema c'è: il dirigente cazzia il fornitore ma ottiene il premio, il fornitore cazzia lo sviluppatore ma guadagna delle MAC (correttive al software che vengono pagate a parte).

In pratica gli sventurati sono solo lo sviluppatore (che avrebbe voluto fare il suo lavoro e produrre software professionale e di qualità) e chi deve pagare l'IMU, che si deve smazzare l'onere di sbattere contro il computer (o al CAF) per la pratica, magari arrivare tardi, poi andare da Equitalia...

Il cerchio della vita!