Archivi categoria: outsourcing

Il futuro dell’IT aziendale

“Ricchi premi attendono le aziende che colgono le opportunità digitali; il disonore, al contrario, attende quelle che non ce la fanno. […] In teoria, per il settore IT questa è un’ottima opportunità per collocarsi al centro delle strategie aziendali. In pratica, il resto dell’azienda dubita che la gente dell’IT sia in grado di farcela – e spesso si predispone a comprarsi la propria IT da terze parti, se necessario.”

Surfing a digital wave, or drowning? The Economist, 7 dicembre 2013

L’outsourcing del software sta cambiando

Alcune grandi aziende statunitensi, come General Electric e General Motors, ricostruiscono il proprio settore di sviluppo software, dopo anni di outsourcing, per fornire un supporto più efficace ed efficiente alle proprie strategie. Intanto, le grandi software house indiane assumono sviluppatori negli USA.

Un inserto speciale di The Economist su Outsourcing e Offshoring, con un articolo dedicato allo sviluppo software.

L’immagine sociale del programmatore

Nei paesi più vitali dal punto di vista economico, come Stati Uniti, nord Europa, Cina, India, il ruolo del programmatore software è ben conosciuto, e considerato in modo molto positivo.

Lo sviluppo software è trattato frequentemente dai media non specializzati (giornali e riviste per non addetti ai lavori, televisioni). I programmatori compaiono nelle pubblicità e in fumetti diffusi, come Dilbert. Soprattutto, partiti politici e governi hanno ben chiara l’importanza dello sviluppo software e provano ad incentivarlo il più possibile.

Un esempio: in Estonia è stata appena approvata una legge per insegnare la programmazione nelle scuole, a partire dalle elementari, in quanto la programmazione software è ritenuta un fattore strategico per il paese e in Estonia, dove tra l’altro si sviluppa Skype, mancano programmatori.

In Italia, invece, il ruolo di programmatore software è da sempre poco noto. Se ne parla poco, o per nulla. E laddove è conosciuto, come all’interno dei settori IT delle organizzazioni (grandi e medio-grandi), è considerato come un ruolo di secondo piano.

Almeno dagli anni settanta del ‘900, esistono centinaia di migliaia di persone che operano nel campo del software in Italia. Ma mi occupo di informatica da oltre 30 anni e mi è capitato molto raramente di leggere un articolo sullo sviluppo software in una rivista non specializzata. Sarò stato distratto, forse. Ma sicuramente si è parlato molto di più dei tassisti.

Forse è anche per questo motivo che l’immagine sociale del programmatore software in Italia è così scarsa. In molte organizzazioni italiane il ruolo del programmatore è probabilmente uno di quelli meno considerati. Un ruolo di basso livello, operativo, con basso status sociale. Uno dei primi ruoli da eliminare, da esternalizzare, perché non porta valore aggiunto all’azienda.

Ma forse, invece, a ben guardare, lo sviluppo software porta valore aggiunto. Forse, la programmazione software non è affatto un’attività operativa, ripetitiva, di basso livello intellettuale.

Lo dimostrano i paesi più dinamici e vitali dal punto di vista economico, che hanno bisogno di programmatori e cercano in ogni modo di attrarli dall’estero. E anche molte aziende, come la General Motors, che dopo aver attraversato ed essere uscita da una crisi profonda ha capito che si era spinta troppo in là, con l’outsourcing dello sviluppo software, e sta ora assumendo migliaia di programmatori.

L’arte del negoziato

“L’arte del negoziato” è il titolo con cui venne tradotto in italiano “Getting to Yes – Negotiating Agreement without Giving In”.

Il libro, scritto da Roger Fisher, William Ury e Bruce Patton nel 1991, ebbe un’enorme diffusione internazionale. Descrive una tecnica per la gestione dei conflitti (politici, sociali, familiari) sviluppata nell’Harvard Negotiation Project e usata con successo sia a livello di conflitti tra stati che per affrontare situazioni di degrado e violenza nei territori urbani.

Tecnica efficace anche per la gestione dei contrasti tra clienti e fornitori nell’ambito dell’outsourcing dello sviluppo software.

General Motors assume personale IT

C’è chi pensa che l’outsourcing dell’informatica (cioè il rivolgersi a ditte esterne per la realizzazione dei servizi IT) sia una tendenza comune a tutte le grandi organizzazioni. Non è così.

Al contrario, aumentano i casi in cui, dopo esperienze pluriennali di outsourcing, le grandi organizzazioni decidono che è meglio riportare al proprio interno (insourcing) le competenze informatiche. Come nel caso di General Motors.

Outsourcing: l’opinione di James Coplien

“Only the ignorant disagree with the claim that most outsourcing sucks”.

James Coplien è uno degli esperti software più attenti agli aspetti organizzativi e sociali dello sviluppo software. Ha scritto l’eccellente “Organizational Patterns of Agile Software Development”, ed è stato uno degli autori più importanti del movimento dei software design pattern.

La sua opinione sull’outsourcing è particolarmente attenta agli aspetti economico-sociali, e non tiene conto delle caratteristiche specifiche degli ambienti in cui l’outsourcing viene effettuato. Ad esempio, in un mercato del lavoro bloccato come quello italiano, non esiste la flessibilità nell’acquisizione di personale che esiste invece in Danimarca e in altre nazioni con un sistema economico funzionante.

Ciò premesso, l’articolo è interessante.

I progetti in ritardo sono tutti uguali

Ottimo articolo di Tom DeMarco, uno tra i più lucidi esperti di sviluppo software (autore tra l’altro, con Tim Lister, dello straordinario Peopleware).

Tutte le cause legali, nei rapporti di outsourcing dello sviluppo software, vanno nello stesso modo:
“By the 1990s, a significant part of my practice was litigation support, which was a natural consequence of raising my rates to the level that only legal departments could afford. Of course, litigation is all about failure, so perhaps I was seeing more than my share of it. Surprisingly, the failures began to look pretty much alike. Company A contracts to build a software system for Company B and is late to finish, or it goes on beyond its contracted delivery date and the work is cancelled. B sues A or vice versa, one of them hires me, and we all obsess over failure for a while and then settle. In the end, A and B are poorer, the lawyers and I are slightly richer, and nothing has changed. ”

E tutti i progetti in ritardo hanno qualcosa in comune… “All projects that finish late have this one thing in common: they started late.”

Meno banale di quanto sembrerebbe a prima vista, come si scopre leggendo le motivazioni di DeMarco nell’articolo “All Late Projects Are the Same”, comparso su IEEE Software Nov/Dec 2011, disponibile gratuitamente.

Outsourcing “rurale”

Aziende con sede in grandi città, dove il costo del lavoro e della vita è elevato, che esternalizzano attività di sviluppo verso altre strutture, ubicate in aree dove il lavoro costa meno e ci sono meno rischi di turnover.

Succede negli Usa, in India, in Cina, in Israele. Può essere più efficace dell’outsourcing all’estero, come descrive un articolo su IEEE Computer (dicembre 2011) di Mary Lacity, Erran Carmel, Joseph Rottman:

“The two biggest drivers are low costs and high retention rates. Rural outsourcers can offer clients lower prices than ITO and BPO providers based in big cities. On the East or West Coast, for example, an IT analyst/programmer can cost $80 to $100 per hour, while rural outsourcing rates are $45 to $65 per hour. Retention rates among rural outsourcers are also high—more than 96 percent for the providers we studied—because there are few, if any, competitors to poach workers in rural communities”

Precisare tutto all’inizio

Come sarebbe bello se all’inizio di un progetto software tutto fosse ben definito: cosa fare, per quando farlo, a che costo…

Fissare tutto all’inizio, dal punto di vista manageriale, riduce i rischi di un progetto. Quindi conviene sforzarsi in tutti i modi per definire progetti in cui tutto è precisato al più presto, per poi affidarne la realizzazione a qualcuno (fornitore esterno o gruppo di sviluppo interno) che sia tenuto a rispettare quanto concordato.

Purtroppo, sostiene Scott Ambler, la riduzione del rischio è una pura illusione. La lezione più certa che arriva dal project management è l’impossibilità di bloccare, all’inizio e contemporaneamente, le tre variabili fondamentali di un progetto software: le cose da fare, i tempi, il budget.