Thread by @v2Dark

Pensieri notturni da informatico insonne.

Domani mi toccherà riprendere una interminabile conversazione con un cliente che ha richiesto un preventivo per la realizzazione di un software che avrà il compito di svolgere attività relative alla sua azienda, ma a lui sconosciute.

2/ il problema di queste richieste è dato proprio dal fatto che chi le fa non ha quasi mai un'idea chiara di ciò di cui ha bisogno, al punto che quasi vorrebbe che glielo spiegassimo noi (nella fattispecie io): missione pressoché impossibile, come chi lavora nel settore sa bene.

3/ Poiché ovviamente non ho modo di entrare nella loro testa, e loro non riescono mai a rispondere alle mie richieste di chiarimenti nell'unico modo che mi renderebbe possibile aiutarli, la cosa finisce spesso (50% dei casi, a occhio) in un "abbandono" del progetto a metà strada.

4/ Abbandono peraltro raramente indolore: nella migliore delle ipotesi, i tentativi di sciogliere questi nodi gordiani determinano una marea di tempo perso (ovviamente a titolo gratuito) da ambo le parti; nella peggiore costano un sacco di soldi, talvolta privati e talvolta no.

5/ Perché parlo di pubblico e privato? Perché gli appalti informatici pubblici, e le commesse dirette e indirette che ne derivano, sono ad oggi (ed è così da oltre 10 anni) uno dei metodi più redditizi con cui una azienda privata ha modo di arricchirsi, in Italia come altrove.

6/ Torniamo a noi: la peggiore delle ipotesi di cui parlavo prima si verifica quando il progetto parte nonostante il committente non abbia capito un accidenti sulle sue dinamiche e/o di come funzionerà. Ma se il cliente non capisce queste cose come fa a partire, direte voi?

7/ Il problema è proprio quello: parliamo di gente che ne capisce talmente poco da non rendersi neanche conto di non aver capito nulla. Accorgersi di non sapere non è sempre una cosa facile, specie quando l'argomento è tecnico e/o la voglia di applicarsi (aka studiare) è poca.

8/ Sia ben chiaro, il bicchiere non è sempre mezzo vuoto. Quando l'incapacità di accorgersi di non aver capito un accidenti del cliente ha la fortuna di incontrare un tecnico onesto il progetto riesce a non partire, il paracadute si apre e nessuno perde soldi: salvi per un pelo.

9/ Il problema si verifica quando chi non ha capito di non aver capito si scontra con la disonestà intellettuale (e non solo) di chi ha tutto l'interesse a far partire ugualmente i lavori, pur sapendo bene che il progetto è fallato: l'importante è che chi paga non ne abbia idea.

10/ Penso che abbiate capito dove voglio andare a parare, e come mai prima ho parlato di "soldi pubblici". La realtà è che di "MOSE" informatici, mio malgrado, ne ho visti parecchi... Fortunatamente tutti dall'esterno: quelli capitati a me sono riuscito a fermarli in tempo.

11/ Che poi, intendiamoci: quando questi errori di valutazione li fa un'azienda privata, magari perché decide di lesinare sullo studio di fattibilità o sull'analisi dei rischi, il danno c'è comunque. Perché a saltare per aria non è quasi mai chi non capisce di non capire, ahimé.

12/ Torno alla metafora informatica, anche se ormai avete capito che parliamo tristemente di attualità.

Per poter realizzare un software su commissione è fondamentale riuscire a descriverlo in modo pienamente comprensibile sia da chi lo richiede che da chi lo deve realizzare.

13/ Questo lavoro può essere fatto dal committente (stakeholder) o da una persona terza ingaggiata appositamente per farlo (product manager): in nessun caso questa "traduzione" può essere redatta dal prestatore d'opera, il cui giudizio sconta un evidente conflitto di interesse.

14/ A prescindere da chi realizza questa "stele di Rosetta", lo stakeholder non può prescindere da uno "sforzo cognitivo" notevole per comprendere appieno l'entità di ciò che ha chiesto: attività che, sfortunatamente, ben pochi hanno tempo, modo, voglia e/o capacità di fare.

15/ In tutti i casi in cui A) questa traduzione non viene svolta correttamente e B) gli stakeholder non hanno la pazienza (o la decenza, o la capacità) di leggerla con attenzione e comprenderne il significato, questi ultimi resteranno senza soldi e con un pugno di mosche in mano.

16/ Il mancato rispetto di questa semplice ma ineludibile dinamica è alla base di una quantità enorme di progetti falliti e soldi buttati: in ambito IT ne ho visti molti personalmente, ma la storia è la stessa per tutti i settori: molti finiscono sui giornali, come ben sappiamo.

17/ Le responsabilità, neanche a dirlo, sono quasi sempre riconducibili a un management fortemente inadeguato e incapace di mettersi realmente al servizio del progetto, ansioso di ingaggiare le funzioni operative (e allocare soldi e risorse), spesso facendosi scudo del "lavoro".

18/ Ma il lavoro, a differenza dei fiori di De André, non può nascere dal letame prodotto da chi non ha voglia né modo di portare avanti un progetto che non ha compreso. E per inciso, non si tratta di "merito" ma di impegno, passione, studio e senso di responsabilità.