Un giorno, facendo quattro chiacchiere con un amico, “Analista Programmatore” della vecchia guardia, è scoppiato nella mia testa una specie di A/B testing oltretutto nato dalla coincidenza di aver avuto alcuni clienti in comune per delle consulenze.
Le analisi software del mio amico sono tecnicamente perfette: un team di sviluppo può prenderle in mano e iniziare a lavorare in tempo zero. Ma spesso i suoi progetti non arrivano a questo step e finiscono nel dimenticatoio aziendale.
Lusingatomi durante questo discorso della mia percentuale di successi più alta, mi sono anche interrogato sulle cause, sul mio modo di lavorare nato in oltre 30anni di pratica, enumerando questi punti:
–Ascoltare il cliente.
Che non significa solo intervistarlo riguardo al software che deve fare; significa imparare a conoscere i suoi percorsi, i suoi metodi in azienda, come funziona la sua azienda nel momento zero: prima dell’innovazione.
–Non avere pietà
Il cliente deve essere un soggetto informato. Se degli step della sua idea o del suo status attuale non vanno bene, gli vanno comunicati con ferma gentilezza e si deve pretendere la rimozione degli ostacoli.
–Essere indipendente
Non si deve fornire al cliente la soluzione che porta più soldi al consulente stesso, perché magari ha contatti; un team etc. Gli si deve fornire la soluzione migliore, anche già presente, che risolva quanto prima i problemi aziendali.
–Fornire al cliente gli strumenti
Una oscura analisi informatica testuale, utile ad un Project Manager è un mistero per il cliente. Al cliente occorre mostrare diagrammi e grafici; testi comprensibili a chiunque, e spesso il cliente non decide da solo: a questi materiali conviene aggiungere una presentazione già pronta con i punti salienti che comporterà l’innovazione per l’azienda.
–Uccidi l’alieno
Non deve esserci mai in un progetto una mistery box, un “questa è roba per addetti ai lavori”, l’AI, la BlockChain, la Fuffachemisonoinventatoio. Sei un consulente: sei lì per spiegare ed essere capito a fondo.
–Fatti pagare
L’analisi è un processo creativo molto complesso, che può richiedere grandi sforzi. Deve essere chiaro a te e al cliente che non si può fare gratis. Non è un preventivo: Sei un soggetto indipendente che non guadagna nulla dall’analisi, non c’è per forza il tuo team nascosto alle tue spalle ad incassare.
–Spenditi in prima persona
L’analisi non deve essere un pacchetto di documenti consegnato al cliente e basta; devi includere la possibilità di presentarla tu stesso al board del cliente; sia in videoconferenza ad un costo minimo, sia di persona ad un costo più ragionevole: L’esperto che viene da te e ti presenta un progetto interno come se fosse il suo, fa pendere la bilancia degli investimenti necessari in positivo.
–Fai dei follow-up sui progetti nei vari stage.
Anche se non si fa parte della realizzazione del progetto finale, occorre sempre ricontattare il cliente; sapere come va il lavoro e quali sono le criticità. Non è raro che si scopra che è bloccato e sia necessaria una consulenza per risolvere: ma il cliente magari è sotto choc, sta perdendoci dei soldi, non immagina una soluzione, non ti chiama.
–Resta umile.
Ricordati che non puoi conoscere tutto: cerca anche tu consulenze per approfondire argomenti che non conosci prima di rischiare di consigliare male il cliente.
Puoi approfondire la lettura andando al primo passo del mio metodo:
One thought on “Il mio metodo per l’analisi del software.”