In questi giorni ho molto tempo per pensare, bloccato a letto dopo l’incidente, fra quel poco di lavoro che riesco a svolgere con la sola mano sinistra e gli esercizi di fisioterapia spicciola che ho cominciato a fare.
Quando penso troppo è un dramma perchè tendo ad essere logorroico anche con me stesso. In particolare oggi mi sono soffermato a pensare che cosa sia in realtà la nostra professione, sarà colpa della torta di mele in doppia razione di ieri sera.
Spesso, soprattutto se liberi professionisti, ci paragoniamo a degli artigiani, ma onestamente credo che sia estremamente riduttivo. Soffermiamoci un attimo su quelli che sono gli skill che ci vengono richiesti, in alcuni casi anche dalla normativa ISO (mica il primo pirla che passa per strada):
- definizione dei requisiti funzionali e non funzionali a fronte di un’esigenza di business che ci viene presentata
- definizione dei confini del progetto, delle stime di rischio e delle strategie di mitigazione, stima dei tempi e dei costi (indipendentemente dalla metodologia di conduzione del progetto, sia essa waterfall, agile, ibrida, ecc.)
- capacità di individuazione dei chenge request e di conseguente negoziazione (anche in questo caso nella sua accezione più generica)
- conoscenza dei principi dello sviluppo software, dal design all’implementazione, adatti ad ogni scenario richiesto
- conoscenza degli strumenti di software engineering: versionamento del codice sorgente, automazione del processo di build, bug/issue/workitem tracking
- conoscenza delle tecniche e degli strumenti per la definizione e il perseguimento della software quality (qualunque sia il livello concordato con il cliente)
- un certo livello di conoscenza sistemistica sia sul fronte della system integration che del deployment
Dimentico certamente qualcosa, altri aspetti invece sono impliciti come ad esempio la continua necessità di autoformazione e ricerca, senza contare che ognuno dei punti che ho indicato portano con se tutta una serie di aspetti e conoscenze che un professionista “dovrebbe” possedere. E possiamo nasconderci che spesso tutto questo è applicabile a diverse tecnologie e piattaforme (windows, web, mobile)? Ovviamente no…
Decisamente sono propenso a credere che stiamo pesantemente sottovalutando in generale quelle che normalmente sono le nostre qualifiche professionali. Attenzione, la mia non è una considerazione sull’eccessiva modestia che il nostro ambiente dimostra, tutto il contrario. La mia è una considerazione su quanto spesso ci “dimentichiamo” di quello che comporta fare il nostro lavoro.
Non siamo artigiani, e credo dobbiamo smetterla di considerarci tali perchè troppo spesso questa diventa la chiave di lettura per un approccio al nostro lavoro un po’ naif, bohemienne. Un po’ genietto, un po’ scanzonato, un po’ fuori dalle righe.
Oppure soffriamo della sindrome da Dr. House, sindrome di cui ho pesantemente sofferto pure io, e da cui spero di guarire, ovvero quella che ti rende il polo indispensabile del team, ma ovviamente anche il maggior problema di efficienza ed efficacia per quanto riguarda la produttività dello stesso.
Siamo ancora in una fase edonistica della nostra professione? Io credo di sì onestamente. Credo che non abbiamo ancora fatto quel necessario passo per considerare in maniera maledettamente seria i pillar della nostra attività lavorativa. Ci portiamo dietro ancora troppo spesso l’indole giocosa per il nuovo giocattolo, per la nuova buzzword, e troppo spesso sottovalutiamo aspetti fondamentali di ciò che il mondo del business si aspetta da noi.
La chiave di lettura deve essere questa: calarsi anima e corpo in una realtà in cui dobbiamo essere consapevoli di quale dovrebbe essere il nostro ruolo “effettivo” e non quello “desiderato” ( da noi stessi ovviamente").
Faccio un esempio: quando un cliente ci interpella per un nuovo progetto troppo spesso ci limitiamo ad essere dei driver tecnologici, che è solo uno dei nostri compiti. Ma quanti di noi, io in primis, durante la fase di start-up di un progetto promuovono con il proprio cliente fronti di discussione come quello della definizione di una policy di software quality, o quello sulle strategie di deployment, o quello su strategie di analisi condivise, ecc., ecc.?
A volte autolimitiamo lo scope delle nostre competenze professionali e questo spesso ci si ritorce contro contribuendo a creare lo stereotipo del tecnicone sviluppatore di codice. Non dico che sia solo colpa nostra, ma accade più spesso di quanto si pensi.