Andrea Vincenzi Consulenza Datawarehouse

olap.it The N° 1 site for Data Warehousing Professionals	Business Intelligence & Data Warehouse Resource Center
Home Servizi di consulenza Siti e Risorse Definizioni Libri Recensioni Articoli Prodotti Soc Consulenza News Progetti Italiani Altre Info

Torna a Home Page Servizi di Consulenza

Perchè conviene affidarsi ad un consulente indipendente

1) Come lavorano le società di software - 2) La mia metodologia di lavoro - 3) Una famosa storiella sui consulenti

andrea.vincenzi@olap.it

Tel. (+39) 347 3853617

Download CV formato pdf

Download CV formato Word

L'affidamento di un progetto software ad un consulente indipendente è una pratica poco diffusa, ma in realtà essa presenta molti vantaggi e pochi svantaggi; vediamo perchè, in base ad alcune semplici considerazioni.

Lo sviluppo di progetti software è un'attività complessa che richiede competenze, esperienza e disciplina. Molto spesso clienti anche di grandi dimensioni tendono a dare importanza solo ai tempi di sviluppo ed ai costi, tralasciando la qualità del software prodotto in termini di struttura, documentazione ed utilizzo delle "best practice", ma questo è un errore che prima o poi viene pagato a caro prezzo.

Affidando la realizzazione di un progetto ad una società di consulenza, sia essa piccola, media o grande, si ha uno scarso controllo su chi effettivamente realizzerà il software; succede spesso che lo sviluppo venga affidato a persone inesperte e senza una formazione adeguata, magari reclutate sul mercato per uno specifico progetto richiedendo unicamente la conoscenza di un linguaggio o di un prodotto software e badando più ad un contenimento dei costi che alla qualità.

In realtà la conoscenza degli strumenti di programmazione non è sufficiente per ottenere un prodotto finito di qualità; è indispensabile possedere anche molte altre competenze come software engineering, data modeling, architetture di rete e di sistema, project management e analisi di processi, accompagnate preferibilmente una solida formazione ingegneristica di base; difficilmente però queste competenze sono distribuite in maniera ottimale in un team di progetto.
Questi concetti non sono naturalmente frutto di un'esperienza personale, essendo ampiamente trattati in alcuni testi classici di software engineering, come "The mythical man month", dove si dice ad esempio che in un team di progetto esiste molto spesso una persona che svolge la maggior parte del lavoro, mentre il resto del team crea sostanzialmente un overhead che serve solo a dilatare tempi e costi.

Io faccio progetti software da 25 anni e continuo a farlo con passione e con un'attenzione maniacale alla qualità. A volte partecipo a progetti che per le loro dimensioni hanno bisogno di un team di sviluppo composto da molte persone, altre volte lavorando per imprese del settore PMI posso svolgere buona parte del lavoro da solo, nel qual caso si realizzano le condizioni per offrire al cliente alcuni innegabili vantaggi:

Concentrazione in una persona di tutte le competenze necessarie per sviluppare software di qualità, dall'analisi al progetto completo. Nessuna inefficienza derivante dal coordinamento di un team di lavoro, dal trasferimento di informazioni e da un processo decisionale farraginoso.

Pieno controllo da parte del cliente su chi realizzerà il software, tramite un rapporto diretto.

Costi e tempi contenuti grazie alla eliminazione di intermediari e dell'overhead derivante dal coordinamento di un team di lavoro

La mia metodologia di lavoro si fonda su alcuni principi imparati nel corso degli anni sui testi di engineering, nonchè dalle persone e dalle aziende con le quali ho preso parte a molti progetti, tra i quali:

	Porre grande attenzione alla qualità in tutte le fasi del progetto: documentare adeguatamente i requisiti, l'analisi e le soluzioni adottate, progettare l’interfaccia utente includendo possibilmente quel “qualcosa in più” che rende il software facile e piacevole da utilizzare
	Studiare molto e seguire sempre le best practice, resistendo alla tentazione di improvvisare o di inventare soluzioni e metodologie proprie a meno di casi eccezionali. Seguire una metodologia (nel mio caso Kimball per progetti di DW e Yourdon per progetti di sviluppo software) adattandola alle dimensioni del progetto.
	Conoscere bene il mercato e i prodotti per essere in grado di effettuare una software selection che crei valore per il cliente. Non limitare la scelta ai prodotti più famosi, cercando il prodotto che fornisce il miglior rapporto prezzo/prestazioni e che meglio si adatta alle caratteristiche del progetto.
	Partecipare ai principali forum online per tenersi aggiornati e scambiare opinioni con altri professionisti. Internet ha cambiato radicalmente il modo di lavorare e permette di sottoporre problemi o validare le proprie soluzioni utilizzando il contributo di esperti internazionali. Non approfittarne significa semplicemente limitare la qualità del proprio lavoro di progettista.
	Disporre di una vasta biblioteca di testi e articoli specializzati, sia cartacea che online. Da molti anni raccolgo il materiale migliore e lo catalogo, con la possibilità di effettuare ricerche full text ed ottenere risposte immediate alla maggior parte dei quesiti. La mia biblioteca è composta attualmente da circa 50 libri e oltre 8000 articoli.

Per finire, se amate vedere il lato ironico delle cose e se non l'avete ancora letta, vi consiglio caldamente la storiella del consulente e le pecore