organizzazione

Ci sono ancora architetti software che non sviluppano? Sì, nelle organizzazioni ancora influenzate dall'approccio a cascata. Ma il fenomeno è in calo, afferma Philippe Krutchen in IEEE Software, May/June 2011, Walking across the Seam.

"In our industry, I see fewer software architects throwing their designs over the wall to the hordes of programmers. In many organizations, these entities— architects and programmers—are roles, not individuals, and we've known for a long time that the best architects are also implementers; and vice versa, the best programmers understand the function of architecture and respect it.

The architect-programmer dichotomy might still exist, mostly in large organizations, as a sort of remnant of the waterfall approach, where the organization tended to match the phases. But today, the most successful software development organizations are staffed by people with a broad range of competencies, able to embrace multiple roles. We hear calls for more T-shaped individuals and less hyperspecialists."

Perché ci sono poche donne nel mondo del software? Poche, si intende, rispetto a quante potrebbero essercene, costituendo almeno il 50% della popolazione.

Per inclinazione? Per attitudine? Improbabile, sostiene Martin Fowler in questo articolo.

Fowler sottolinea come la compresenza di persone diverse tra loro (per genere, per razza, per cultura) nel settore del software sia estremamente vantaggiosa. E come in Cina, ad esempio, la presenza delle donne nel mondo del software sia, in percentuale, molto più alta che negli USA.

In un mondo complesso come il nostro le specializzazioni sono
necessarie. Il "faccio tutto io" funziona solo in contesti limitati, non
in progetti dove è necessario il contributo di varie conoscenze ed
esperienze.

Lo sviluppo di software, in particolare, richiede competenze
specialistiche in diverse aree: competenze relative alla materia
trattata, agli aspetti relazionali e di comunicazione, all'analisi e
design del software e dei dati, tecnologiche. Quando anche solo una di
queste competenze manca, il prodotto finale ha poca qualità.

Le competenze specialistiche sono necessarie. Ma non sono sufficienti. È
necessario che si integrino e che non facciano a pugni tra loro. Cosa
che a volte capita quando tra specialisti di ambiti diversi non si trova
un linguaggio comune, un terreno d'incontro. Quando ognuno vede le cose
dal proprio punto di vista, e percepisce solo i problemi e le
opportunità legati a quel limitato punto di vista.

Come nella storia dell'elefante, nella quale a un gruppo di persone
cieche viene chiesto di toccare l'elefante e di dire poi a cosa
assomigli ciò che sta toccando. Chi tocca le zampe lo confronta a delle
colonne di un tempio, chi tocca la testa a una caldaia, chi tocca la
coda a una fune, chi tocca le zanne a un aratro. Nessuno riesce a
ottenere una visione d'insieme.

Per superare questo limite è necessario che chi partecipa ai progetti di
sviluppo acquisisca, oltre alla propria competenza specialistica, anche
una conoscenza almeno superficiale delle competenze con cui le sue si
devono integrare. Se sono un esperto di analisi dei requisiti, è utile
che sappia quali sono i problemi principali che gli sviluppatori
software devono di solito affrontare. E viceversa. Non devo diventare
esperto di tutto, ma devo sapere come integrare al meglio il mio lavoro
con quello degli altri, e per farlo devo conoscere il loro punto di
vista e le loro criticità.

Bisogna, in altri termini, sviluppare competenze a T. Come recita
Wikipedia, "Il concetto di competenze a T (T-shaped skills), o di
persone a T (T-shaped persons), è una metafora usata nelle assunzioni
del personale per descrivere le abilità delle persone".

La linea verticale della T rappresenta la profondità delle competenze e
delle esperienze in uno specifico settore, mentre la linea orizzontale
rappresenta l'abilità di collaborare con esperti di altre aree, e di
usare in modo appropriato concetti propri degli altri settori.
Un'abilità indispensabile.

Su questo argomento, anche:
http://www.core77.com/hack2work/2009/09/on_being_tshaped.asp
http://www.noop.nl/2010/06/t-shaped-people.html
http://www.alfonsofuggetta.org/?p=9422

Sergio Bologna, Dario Banfi:
Vita da freelance. I lavoratori della conoscenza e il loro futuro.
Feltrinelli 2011

"Lavoratori della conoscenza" nel sottotitolo è limitativo e fuorviante. Il libro parla in generale di autonomi e partite iva, e dei relativi problemi: di identità, sociali e previdenziali. Molti spunti interessanti anche in merito allo specifico ICT.

ACM (Association for Computing Machinery) è la maggiore organizzazione professionale IT a livello internazionale.

Tra i benefici per i soci, ha recentemente inaugurato i "Tech Pack", pacchetti di letture selezionate per guidare nell'apprendimento di concetti rilevanti dell'informatica. Ai primi due, relativi al Cloud Computing e al Parallel Computing, se ne è ora aggiunto uno sulla Enterprise Architecture.

Cosa è un Product Manager, cosa deve fare, in quale posizione organizzativa può essere collocato (anche nell'IT, perché no). Una buona sintesi in Time to assign owners to your applications di Tom Grant su SD Times.

Freelance significa lance libere, e viene dal romanzo storico Ivanoe, segnala Luca De Biase. Che pubblica anche una interessante infografica su chi sono, dove sono, quanto guadagnano e cosa vogliono i freelance.

È vero che l'informatica riduce posti di lavoro? Se sì, quali tipi di lavoro riduce? Il tema è trattato in modo approfondito in un testo del 2005 di Frank Levy e Richard Murnane: “The New Division of Labor. How Computers Are Creating the Next Job Market”.

Secondo gli autori, l'informatica riduce l'occupazione per i lavori, manuali e non, in cui l'attività è basata sul seguire delle regole e delle procedure. Non ha al contrario alcun effetto negativo, anzi, sui tipi di lavoro che richiedono essenzialmente competenze intellettuali (“expert thinking”) e capacità di comunicazione (“complex communication”).

Da notare il peso che gli autori attribuiscono alla necessità di formazione sulle competenze linguistiche - comunicative (“literacy”) e matematiche: maggiore il tasso di cambiamento in una società, maggiore l'esigenza di leggere e interpretare i cambiamenti in atto per adeguarsi senza esserne travolti.
Ne consegue che le capacità di capire e intervenire sulla realtà (“problem solving”) e di comunicare efficacemente non devono venire insegnate solo nei tipi di scuola più prestigiosi, come i nostri licei, ma anche negli indirizzi tecnici e professionali, in quanto critiche per la sopravvivenza nel mercato del lavoro.