È impossibile spiegare il perché di DevLeap senza partire da una considerazione più generale sul valore e l’importanza del software (anche se molti dei ragionamenti si applicano, più in generale, all’intero mondo dell’information technology).

Molti progetti di sviluppo (intranet, e-commerce, CRM, ERP, sistemi gestionali personailizzati, e così via) nascono come progetti faraonici, in particolare per la quantità di risorse impegnate.

Una percentuale troppo alta di questi progetti non arriva a una conclusione positiva. Altri non funzionano come dovrebbero, anche se qualche servizio riescono a erogarlo. Altri ancora non generano i ritorni sperati, soprattutto se paragonati agli investimenti sostenuti (con l’aggravante che i primi spesso sono originariamente sovrastimati e i secondi sottostimati).

Purtroppo questo fenomeno è diffuso a molti livelli, nelle piccole come nelle grandi aziende, pur se con dimensioni diverse. È chiaro che le aziende, presto o tardi, reagiscono a questa situazione. E la reazione più scontata è un taglio dei costi, che si tramuta in un taglio agli investimenti di sviluppo: meno consulenti, meno dipendenti, meno incentivi, meno infrastruttura.

Mettetela come volete, ma quando ci si focalizza sull’aspetto economico ignorando le parti di cui è composto, agendo a tutto campo invece che in maniera selettiva, il risultato è che qualcuno scende dal treno. Chi? Di solito i migliori.

Ora, se il software fosse veramente un gadget, qualcosa di non essenziale per la vita e la competitività dell’azienda, ragionare in questi termini sarebbe corretto.

Da un punto di vista pratico, analizzando l’impatto di un “disimpegno” nell’innovazione tecnologica, il risultato nel breve periodo non può che essere positivo: meno costi, maggiori profitti, a volte maggiori ricavi, perché si possono concentrare tutti gli sforzi sul marketing e sulle attività più commerciali.

Ma ragioniamo sul lungo termine, prendendo qualche esempio da un passato neanche troppo distante. È pensabile, oggi, una banca senza informatica? Inimmaginabile. Un check-in all’aeroporto senza terminali? Già così si aspetta troppo, figuriamoci assegnando i posti a mano.

Prendiamo un’assicurazione. Certo, anche se pare assurdo, un’assicurazione potrebbe fare tutto “a mano”. Pratiche su carta, ricerche manuali, copie e fax risolvono il resto. Chiedi un rimborso? Al limite aspetti di più, non è che all’assicurazione dispiaccia. Ma una compagnia del genere che costi sostiene? Quanto può essere concorrenziale sul mercato? Quanto può essere interessante per una persona motivata (potenzialmente più produttiva) andare a lavorare in un posto simile? E non abbiamo ancora accennato alla necessità di analizzare i dati per stabilire politiche di marketing efficaci, prezzi concorrenziali e allo stesso tempo remunerativi, e così via.

Pensare che sul lungo termine un sistema informativo efficace ed efficiente sia un accessorio utile ma non indispensabile è un grave errore. Sarà una questione di sopravvivenza: attualmente lo è già in alcuni settori, in futuro lo sarà per un’area di attività sempre più ampia.

Idee fantasiose? Può darsi. Ma lo scenario appena descritto è quello che, in origine, fa creare i progetti di cui abbiamo parlato all’inizio, progetti che poi non raggiungono sempre gli obiettivi sperati.

Dunque, questi progetti (in cui il software è spesso un elemento decisivo) abortiscono a causa di obiettivi sbagliati? O forse i problemi sono altri?

Beh, diciamo le cose come stanno. Quando un progetto va male, spesso la colpa è del team, che comprende analisti, sviluppatori, persone che si occupano di controllo qualità e di documentazione. I motivi per cui il team non funziona possono essere diversi, ma essenzialmente ce ne sono due molto più importanti di altri: la dimensione del team e le competenze delle persone che lo costituiscono.

A rischio di dire cose ovvie: è molto, molto, molto meglio avere poche persone brave che tante un po’ meno brave (per non dire di peggio). Vale praticamente per qualsiasi attività lavorativa, ma nel software assume un’importanza ancora più grande. È noto (o dovrebbe esserlo) che i migliori prodotti software sono realizzati da team di sviluppo limitati in quantità ma non certo in capacità. Ovviamente, quello che non si può chiedere è di rispettare scadenze impossibili: spesso è proprio questa necessità che porta ad aumentare la dimensione di un team, il più delle volte inutilmente.

Ora, creare un team con queste caratteristiche non è facile ma non è neanche impossibile. Bisogna puntare sulle persone, purché abbiano motivazione, capacità e attitudine. Poi, però, un team va tenuto in piedi e va mantenuta la sua capacità di eccellenza: questo è più difficile. Bisogna fornire un ambiente stimolante, un’infrastruttura efficiente (non date a un bravo sviluppatore una macchina lenta, con poca RAM e un disco quasi pieno) e la possibilità di aggiornarsi.

In tutte queste considerazioni, in realtà, non c’è nulla di nuovo. Sono stati scritti articoli e libri su questi argomenti. Noi di DevLeap ci concentriamo sulla necessità di formazione continua che è propria di chi vuole restare “in prima linea”.

La formazione è importante, ma per formazione non intendiamo solo il classico “corso”. Formazione significa tenersi aggiornati, leggere, studiare, comprendere a fondo la tecnologia che si sta usando. Formazione significa anche partecipare a un corso o a una conferenza, occasioni di incontro e di scambio che integrano, ma non sostituiscono, l’attività quasi quotidiana di “mantenimento degli skill”.

In ultima analisi, le persone sono in qualche modo responsabili del loro “percorso formativo”. Per vari motivi, alcune aziende in Italia si sobbarcano dei costi formativi molto elevati; non è però corretto pensare, da parte di nessuno, né che la responsabilità dell’azienda si esaurisca nel fornire la partecipazione a un corso o due all’anno, né tanto meno che la responsabilità dello sviluppatore si esaurisca con la partecipazione “fisica” in aula. L’azienda deve fornire un ambiente stimolante e gli strumenti necessari (per esempio libri e altro materiale di studio), lo sviluppatore deve essere cosciente che le competenze che possiede sono l’unico patrimonio “vero” che può farlo stare sul mercato (il curriculum, nell’informatica, quando parla di tecnologie che hanno più di tre o quattro anni parla di cose spesso obsolete).

Noi di DevLeap crediamo nel valore competitivo dell’information technology, crediamo nella qualità del software, crediamo nell’innovazione, crediamo nella formazione, crediamo nel valore della qualità in senso più ampio.

Insomma, noi di DevLeap “ci crediamo”.

Per questo abbiamo realizzato un sito internet in cui pubblicare contenuti “di qualità”. Per questo vogliamo attirare l’attenzione e farci seguire da persone che condividono questa nostra visione.

Per questo, dunque, stiamo creando una comunità di persone che “ci credono”.

Bridge the gap!