Da un pò di tempo ho iniziato a interessarmi di progetti sofware cercando di raccogliere informazioni circa le esperienze di vari Project Manager che nel tempo sono stati responsabili dell’esecuzione e della messa in opera di vari progetti software. In questo articolo ho cercato di sintetizzare eventi e riflessioni che più di frequente determinano il successo o il fallimento di un progetto software a fronte di varie esperienze maturate sul campo. Ritengo che questo possa essere utile quando affrontiamo l’attuale mondo dello sviluppo software.
Ormai sempre più spesso, noi gente del settore software, proveniamo da un mondo che ci ha fornito un apprendimento strutturato, qualcosa che in alcuni casi chiamiamo scienza e in altri ingegneria. Durante il nostro processo di apprendimento ci può sembrare che giunti nel mondo esterno per lavorare possiamo applicare gli stessi concetti e eseguire le stesse attività; ma molto più importante, ci aspettiamo un alto livello di successo, in modo simile all’esperienza da noi maturata alla fine di progetti e compiti che ci erano stati assegnati durante gli anni accademici. Ma purtroppo, il mondo non si comporta in questo modo.
Le statistiche dicono ben altro: si presume che il 50/80% dei progetti software fallisce. Questo rende il mondo dello sviluppo software alquanto inaffidabile. Un software cattivo di solito irrita le persone, ma un cattivo ingegnere può uccidere; ne sono testimonianza alcuni tra i più noti “software flop”.
Una metrica, per certi versi, più affascinante è la seguente: il 5% dei programmatori sono 20 volte più produttivi del restante 95%. Se questa fosse uan tesi comprovata, potremmo risolvere il problema su come far raggiungere a tutti quanti lo stesso livello.
Lasciatemi dire che questa regola segue la solita regola dell’80-20. In poche parole, l’80% dei programmatori non leggono libri, non vanno alle conferenze, non continuano a studiare, non fanno niente eccetto quello che hanno imparato all’università. Il restante 20% lotta giorno dopo giorno con la sua professione, leggono, provano a imparare nuove cose, ascoltano conferenze su internet (podcast) e qualche volta vanno alle conferenze. L’80% di questo 20% non riscuotono un gran successo. Il restante 20% di questo 20% (diciamo circa il 5% dell’intero) sono i 20 volte più produttivi.
Adesso il punto è: come facciamo a entrare a far parte di questo prodigioso 5%?
Le persone che fanno parte di questo 5% lottano per raggiungere quelle performance e continuano a lottare per rimanerci. E’ il processo del continuo apprendimento che fa la differenza. Leggono molto, sono sempre pronti a affrontare un nuovo concetto se sembra degno di attenzione e molto del loro tempo viene speso nell’essere produttivi e nel risolvere problemi. Essere capaci di analizzare e capire una situazione o scoprire il punto cardine di un problema per loro è essenziale.
Occore quindi innescare un processo di continuo apprendimento; ma non è così semplice. E’ enormemente importante impare di più sulla programmazione, ma non possiamo solo imparare di più sulla programmazione. Per esempio, giusto nel mondo della scrittura del codice esistono due importanti punti:
Il codice viene letto più di quanto venga scritto. Se le persone non potranno leggere il tuo codice, allo stesso modo non potranno apportare dei miglioramenti o fissare i bug. Il codice illegibile ha un costo reale che viene chiamato “debito tecnico”.
La revisione del codice rappresenta il modo più efficace per scovare i difetti e ancora, di solito “non abbiamo tempo per eseguirla”.
Provenendo da un mondo fatto da zero e da uno, ci piacerebbe credere che le cose siano deterministiche, che possiamo fornire un insieme di input e ottenere, ogni volta, lo stesso output. Il nostro è un “business” giovane e per certi versi primitivo. Non sappiamo molto, tra le metodologie da applicare, su cosa funziona e cosa no e continuiamo a pensare, ogni volta che si presenta una nuova metodologia, di aver trovato la panacea a tutti i mali e che possa risolvere tutti i guai dello sviluppo software. In conseguenza di ciò, subiamo le idee su nuovi cicli di sviluppo che arrivano, si diffondono per poi allentare la loro presa e far posto ad altre idee. Secondo la mia opinione esiste un’eccezione; molte idee delle metodologie agili sembrano nel tempo continuare a mantenere il loro vigore. Mostrano di avere un reale impatto nella produttività e nella qualità del software. Questo perché si focalizzano sui problemi delle persone che lavorano insieme e meno sulle tecnologie adottate.
L’esperienza suggerisce: “Ciò che porta al successo o al fallimento di un progetto software sono i problemi che si presentano nei processi e nelle persone conivolte”. Quindi, il modo in cui lavoriamo giorno per giorno. Gli ingredienti che possono formare la miscela esplosiva sono: chi sono i tuoi architetti, chi sono i tuoi manager e chi sono le persone che compongono il team con cui lavoriamo. Come comunichiamo ma soparattutto, come risolvi i problemi di processo e delle persone quando si presentano. Il modo migliore per bloccarsi su queste questioni è pensare che è tutta colpa della tecnologia adottata e credere che noi possiamo sfondare gli ostacoli sfruttando altre vie. Queste altre vie sono quelle che avranno la probabilità più elevata di farti bloccare in modo definitivo.
Certe volte si forma nella nostra mente l’idea che i nostri manager prendano decisioni stupide e logicamente, raggiungiamo la conclusione che i manager e il management è stupido, come se fosse una conseguenza logica. E’ idea diffusa che nel nostro mestiere se non sei abbastanza in gamba per gestire una tecnologia ti dedichi al mangement. In poche parole il ruolo del manager viene da noi sviluppatori “snobbato”. Analizzando con criticità il ruolo che il manager svolge all’interno di un progetto software deduco che il compito del manager non è affatto stupido (fatto salvo che lui stesso non lo sia come persona in sé) e al contrario alquanto difficile. La gestione è più difficile della tecnologia in quanto non coinvolge fattori deterministici. E’ tutto un lavoro da “indovino”. Se non sei dotato di una buona intuizione molto probabilmente prenderai decisioni stupide.
Avendo raggiunto questo punto dell’articolo, quando iniziamo un nuovo lavoro con la testa piena di conoscenze tecniche, derivate dagli ultimi due anni di esperienza e ci guardiamo un pochettino in torno provando a osservare i collegh che ci circondano, possiamo essere tentati ad assumere che ogni persona impiegata nell’azienda ha intrappolato se stessa con pessime idee. Ma a me piace pensare che: “Le cose oggi sono vengono fatte in un certo modo perché i fatti sono andati in quel modo... un passo alla volta”. Dal tuo punto di vista le cose possono sembrare ridicole, ma ricordiamoci che ogni decisione presa fino a oggi è stata presa da qualcuno che ha soppesato il problema e ha scelto quello che sembrava la migliore scelta in quel momemto. Certamente questo punto di vista non risolve i problemi in cui incorriamo ma ci rende più compassionevoli verso le persone che sono impantanate in problemi e concetti di varia natura.
Ci occorrerà fare molti errori al fine di risolvere i problemi. Siamo umili e facciamo domande di continuo.
