Tempo di crisi: risparmiare deve voler dire spendere meglio

Tempo di crisi e recessione…

In uno scenario di crisi globale come quello attuale, la strada che i principali attori indicano punta in una sola direzione: l’innovazione.

L’innovazione oggi, passa inevitabilmente per il concetto di rete e quindi di Information and Communication Technology: l’ICT.

L’ICT non è mai stata una scienza semplice e alla portata del comune appassionato; l’hobbista, informatico amatoriale, il programmatore cosiddetto “cantinaro”, lo smanettone  o quell’hacker presente nell’immaginario collettivo e così frequentemente rappresentato dalla filmografia degli ultimi tre decenni, che viola sistemi militari, che guadagna milioni scrivendo codice che ruba gli arrotondamenti dei movimenti finanziari, che legge il codice macchina verde a vista e vede un mondo che gli altri non vedono, o non esiste o non è in grado di risolvere i problemi che l’era attuale ci pone. Eppure solo 20, 15 o anche 10 anni fa lo sarebbe potuto essere, ma allora ad essere semplici erano i problemi delle organizzazioni, che erano solo all’inizio della strada dell’informatizzazione.

Oggi l’ICT di cui sempre più le organizzazioni anche di dimensioni medie o piccole o addirittura individuali hanno bisogno è complessa, non è più “tutta” semplice.

Semplice oggi è l’uso dei nuovi dispositivi mobile. Sempre più semplice diventa man mano l’uso di applicazioni di Office Automation. Semplice oggi è usare la posta, acquistare su internet, fare un sito web, pubblicare una video gallery.

Ciò che è complesso è individuare i processi organizzativi che possono beneficiare dell’informatizzazione, calcolarne il costo, valutarne la possibilità di innovazione, trovare i mattoni per costruire un progetto che la porti a compimento ed, infine, realizzare tale progetto con successo. Questo è complesso.

La statistica sui successi e sui fallimenti dei progetti informatici ci insegna che i progetti informatici possono anche fallire; anzi ci insegna che non è così raro che falliscano. E i motivi per cui i progetti falliscono sono ricorrenti. Purtroppo non siamo in grado di imparare da una storia che corre troppo veloce.

New research from CA, conducted by independent research company Loudhouse of 100 IT Directors across the UK and Ireland, reveals that poor visibility of IT project status and a lack of management control over them is costing the UK over a quarter of a billion pounds each year.

Quello che spesso viene a mancare nei progetti informatici non banali, è la capacità di gestirne la complessità, la conoscenza dei complessi temi tecnologici alla base delle soluzioni informatiche, l’inesperienza o la scarsa conoscenza da parte dei livelli direzionali sui temi più avanzati dell’ICT.

Oggi, in condizioni di stagnazione o recessione globale,  si può ad esempio misurare in maniera diretta che la riduzione dei budget destinati ai progetti informatici, aumentano la probabilità di fallimento, rendendo così vano l’impegno stesso del budget.

Se vogliamo fare un esempio utilizzando il classico parallelo tra l’edilizia e l’informatica, possiamo notare che nell’edilizia non è concepibile pensare di affrontare una costruzione senza averne fatto prima la progettazione, l’analisi ambientale, le verifiche legali eccetera. Nell’informatica invece è ancora una pratica diffusa. Nell’edilizia non si pensa che vi sia una sorta di muratore-geometra-ingegnere-architetto così “smart” che sia in grado di realizzare uno stupendo edificio; ci vogliono strumenti, conoscenze, materiali. Nell’informatica invece resiste ancora  l’idea del “programma fai da te”, della soluzione casereccia, del factotum che risolve ogni problema, dalla cartuccia della stampante alla conduzione di un progetto informatico, dalla sicurezza perimetrale al problema con gli allegati della posta, dall’ideazione di un capitolato di acquisto alla scelta delle immagini coordinate per l’azienda.

Questo volantino, ad esempio, sintetizza molto bene il concetto.

Solo un professionista aggiornato ed esperto può aiutare a governare i complessi processi che guidano la realizzazione di un progetto ICT.

I professionisti di elevato profilo non sono in grande numero e tipicamente prestano la loro opera per grandi aziende o per società specializzate nella consulenza ICT.

In questo modo chi ha bisogno di acquisire beni IT, si trova nella situazione di dover far fare l’analisi e la programmazione insieme all’offerta al fornitore e di conseguenza dovrà affidare ad esso anche la gestione del progetto: questa non è evidentemente una situazione ideale, ma oggi sul mercato c’è poca scelta dalla parte dell’offerta e poca cultura dalla parte della domanda.

Annunci

Check SW development dept health: personal considerations on “The Joel Test”

SVG version of Bug silk.png by Avatar
Image via Wikipedia

I find The Joel Test useful and quite easy to apply when I have to figure out what’s wrong in the SW development departments I encounter in my job. When I talk about SW depts I met, I talk about little or mid-sized SW houses (from some working units to many tens of working units), from start-ups to mature IT players, from Industry’s internal ITs to dev teams working for IT consulting companies. I have very little experience of product companies that maintains a SW product with a notable market share.

Here are some considerations coming from my experience; with this article I hope to help you beginning to approach this problem seriously.

The Joel Test

1. Do you use source control?

About 15 years ago, my SW Engineering teacher at the college, asked a question: “What’s the very first thing a SW dept got to do to write good code?”. He expected this to be a very easy and obvious question. No one answered that day… The answer was this first check test of Joel’s list. Today I’m not very surprised in finding only half-half SW depts meeting this check.

2. Can you make a build in one step?

This doesn’t mean to click “Build Entire Solution” on your MS Visual Studio Environment; in that meaning it should not be a SW dept process capability, but an IDE feature.
On my PC, for the projects I manage, I can make build in one step with Jenkins either for C# projects or Java projects I work with; conversely, nearly 0% of SW depts I met can say “Yes” to this.

3. Do you make daily builds?

Normally I work by contract, so for a project I can be out of contract for months; so daily builds should be obviously intended for daily running projects. Using Jenkins, I configure it to build every commint to the source control. In this case too, nearly 0% of SW depts I met can say yes.

4. Do you have a bug database?

I have a personal account on FogBugz even for my very personal ultra thin projects. I tried to introduce an issue tracker (such as RedMine) in every SW dept I worked with that didn’t have one; for the SW house I work with almost every day it’s used only on personal or customer attitude basis; it’s not a SW dev process rule. Here I can find more presence of something structured for bugs and requests management.

5. Do you fix bugs before writing new code?

It’s not a strict process rule in SW depts I know, but instinctively it’s at least partially followed.

6. Do you have an up-to-date schedule?

Normally sales depts aren’t able to sell this effort because it’s difficult to make customers understand this value, so contract managers tell PMs to don’t waste time in non-coding operations because they are not paid.

7. Do you have a spec?

Same as number 6, but it’s more frequent to have a spec that an up-to-date schedule. To put me in my expreience exactly in the case six I can ask “Do you have an up-to date spec?”.

8. Do programmers have quiet working conditions?

In my experience I can say definitely No. In the team I haunt overtime it’s considered “normal time” since at least three years. Those who can sometimes go home after their contracted hours are watched as scroungers… These, among other issues such as high bureaucracy levels, are not quiet working conditions.

9. Do you use the best tools money can buy?

Not always. Tools that cost money erode profit in short-term. Almost every contract is short-term so, often, there is not much money in a single contract to buy tools. FLOSS is evil when sales dept talks with customers and is heaven when it’s time to spend money for internal use.

10. Do you have testers?

Sadly I must say no for almost every SW dept I know… Every one is free to test or not his own code. Often, our customers, have dedicated test units to accept SW from suppliers. I write unit tests for my software and let Jenkins report test failures, but it’s so obvious refer again to checks number six and seven…

11. Do new candidates write code during their interview?

Sometimes I have to talk with candidates to join the team I’m working with. New candidates don’t write code during the interview, but they must pass through a “trial period” with objectives adequate to their resume and their future tasks. In this trial period it’s often asked to pass an official certification exam. I think this is a good practice.

12. Do you do hallway usability testing?

This is an interesting method to quickly test software, but I never have the chance to experience it. I wish to!