(...soprattutto nelle aziende di informatica)
Luca Minudel mi sotterrerà... ma dovevo dirlo. Interessante questo post.
Ho sicuramente ancora poca esperienza nel campo ma mi sento di affermare l'inutilità del diagramma di Gantt...
...con le dovute precisazioni.
Partiamo da un contesto di piccola-media azienda. Mi pare abbastanza logico che in una grande azienda, dove normalmente ci sarebbe un grande caos a causa dell'elevato numero di attività e di persone, tutti gli strumenti che cercano di portare ordine e organizzazione sono i benvenuti.
In secondo luogo portiamoci in ambito "progetto". Parlando di progetto intendiamo mettere in evidenza un concetto diverso rispetto a quello di prodotto. Il progetto è tipicamente qualcosa che nasce dal nulla, in base alle esigenze del cliente. Il prodotto, invece, è qualcosa che l'azienda produce in casa e rivende, eventualmente con delle personalizzazioni. Quando si parla di progetto è tipico che un'azienda non viva su un progetto solo, ma su tanti. Nel caso di progetto unico, evidentemente di grandi dimensioni data la sopravvivenza dell'azienda, il diagramma di Gantt può ancora essere utile. In caso contrario, ci si trova davanti a diversi progetti e la situazione si complica.
In terzo luogo aggiungiamo la componente "risorse". Una o più risorse? Il diagramma di Gantt può arrivare a suddividere le attività tra le persone coinvolte. Ancora una volta se si parla di una persona sola l'uso del diagramma di Gantt è più utile poichè controllato. Tipicamente però un'azienda ha più dipendenti e l'uso del diagramma di Gantt è tipico nel caso di progetti a più mani. Inutile dire che tali persone avranno già partecipato a progetti passati e ne avranno altri futuri.
Non è detto, poi, che tutte le persone abbiano le stesse competenze o lo stesso livello a parità di competenza (pur parlando comunque dello stesso tipo di attività, quindi, ad esempio, 3 sviluppatori e non 2 sviluppatori e un grafico)
Possiamo quindi identificare uno scenario tipico di piccola-media impresa con un progetto seguito da più persone che sono coinvolte su più progetti. Non dimentichiamo mai il fattore tempi-costi-qualità: produrre un Gantt e aggiornarlo ha un costo non indifferente. IMHO, il diagramma di Gantt è perfettamente inutile (realismo). Ho visto impiegare mille metodi, dal foglio excel al diagramma di Gantt, appunto, per gestire la suddivisione delle attività e avere un'idea di quanto si impieghi a svolgere un progetto ma anche di come schedularlo nel tempo. Tutto lavoro inutile, per vari motivi.
1. La piccola-media impresa non ha una persona da dedicare al continuo aggiornamento del diagramma di Gantt;
2. Come già detto, il continuo aggiornamento è qualcosa di estremamente costoso: dopo la prima stesura si tende a dimenticarlo;
3. Spesso ci sono delle urgenze che provocano dei cambiamenti nella schedulazione e quindi l'aggiornamento del diagramma di Gantt;
4. Il commerciale spesso vende un numero di ore inferiori a quelle stimate (stimate e necessarie non sono sinonimi);
5. Ci sono vari fattori che anche il più bravo degli schedulatori non può considerare: dalle ferie alla malattia (che potrebbero essere comunque tenute da parte) a un qualsiasi evento che riguarda il dipendente o l'azienda stessa;
6. In caso di ritardi, quali sono le attività dove si può recuperare del tempo? Le ultime! A danno, probabilmente, dei test. Anche in questo caso il diagramma di Gantt viene invalidato.
7. Il cliente può provocare dei ritardi nella consegna dei materiali, nei test o nella pubblicazione con il conseguente aggiornamento del diagramma di Gantt (e ritorno al punto 2)
8. Uno spostamento su un diagramma di Gantt di un progetto provoca il cambiamento dei diagrammi di Gantt degli altri progetti
9. Tutti i costi aggiuntivi del cambiamento del diagramma di Gantt spesso non possono essere addebitati al cliente. Immaginate, ad esempio, un progetto condotto al meglio con i problemi del punto 7 magari di 7000 euro. Pensate sia facile aggiungere un costo di 1000 euro?
A queste considerazioni aggiungete quelle derivanti dall'articolo già citato e inerenti la programmazione agile.
Il mio suggerimento è agire a posteriori: bisogna segnare il tempo impiegato per tutte le attività e basarsi su quello, imparando anche dai propri errori. In sostanza il commerciale andrà dal cliente e capirà quanto potrà chiedergli; tornerà in azienda con le specifiche e chi di dovere farà un'analisi in base alle esperienze precedenti. Da tale analisi si saprà all'incirca quante giornate occorreranno per realizzare il progetto. Se questo numero sarà superiore alle ore che ha ipotizzato il commerciale, si capirà se procedere o meno in base ad opportune valutazioni; in caso contrario si procederà all'offerta. Se il cliente accetterà il preventivo si capirà in base alle attività in essere quando si potrà partire e chi ci potrà lavorare e si farà un calcolo di giornate da impiegare. IMHO quindi conta l'esperienza: più una persona conosce l'azienda, le persone, il modo di lavorare di ognuno, più è probabile che il progetto avrà successo.
(ovviamente tale flusso potrà variare se il cliente avrà bisogno da subito anche di una data di consegna)
Technorati tags:
Gestione progetti