PROGETTO GPA

Fabio Aiuto
Federico Bianucci
Irene Bontà
Introduzione

 Lo scopo del progetto è mappare la

realizzazione del preventivo che svolge
l’azienda che noi analizziamo.
L’azienda
 L’azienda in questione è Evidence:
software house di Pisa, con all’incirca
venti sviluppatori, che si occupa
principalmente di implementare
software real-time.
L’azienda
 Evidence realizza progetti complessi,
per cui è facile che durante la stesura
del preventivo vengano trascurati
aspetti che in seguito incideranno
notevolmente sul costo iniziale pattuito.
Il problema
 Come per tutte le software house, la stesura di un
preventivo è un processo critico in quanto non è
facile riuscire a priori a prevedere tempi e costi che
saranno necessari durante il lavoro.
 Quando si realizza un software, gran parte del lavoro
da svolgere è caratterizzato da una forte soggettività
da parte di chi lo svolge e dalle sue capacità
informatiche, sono inoltre necessarie attività di
coordinamento tra i membri di un team e un’accurata
progettazione che riduca il più possibile i potenziali
imprevisti che possono verificarsi.
Obiettivi
 Il nostro compito sarà di revisionare
insieme all’azienda l’attuale iter di
preventivo; su tale procedimento
dovremo evidenziare possibili difetti e
lacune, che portano l’azienda ad avere
uno scostamento sensibile tra ciò che
pensavano fosse il costo del prodotto
software e ciò che in realtà è il costo
effettivo.
Costo risorsa umana
 La base da cui partire è quella di stabilire
quanto costa all’azienda uno sviluppatore
 Su di una risorsa umana incidono costi
diretti di produzione, cioè costi
direttamente imputabili allo sviluppatore, e
costi indiretti, cioè non direttamente
imputabili a colui che programma, ma che
incidono indirettamente sul suo lavoro.
Processo iniziale

Costi diretti
(costo annuale risorsa:
tredicesima,
TFR, tasse, ecc.)

Costi indiretti
(luce, rete, acqua, n° di
affitto, amministrativi,
PC, ecc.) sviluppatori

COSTO ANNUO DI UNO SVILUPPATORE

Processo iniziale
8 ore lavorative giornaliere a persona x
(365 giorni in un anno –
(52 settimane annue x 2 giorni di festa a settimana) –
26 giorni di ferie –
10 giorni di malattia –
10 giorni di festa vari)

NUMERO ORE DI SVILUPPO DI

UNA PERSONA IN UN ANNO
Processo iniziale

COSTO ANNUO NUMERO ORE

DI UNO DI
SVILUPPATORE SVILUPPO

COSTO ORARIO A
PERSONA
Listino
 Una volta fatto il calcolo del costo
orario di una risorsa umana, l’azienda
Evidence tiene un listino non pubblico
come riferimento, nel quale i costi
variano a seconda della difficoltà del
progetto e del tempo che occorre per
svilupparlo
Un esempio
 Esempio di listino
1 settimana 1 mese di 1 anno di
di lavoro lavoro lavoro

Attività facile 35 €/h 28 €/h 25 €/h

Attività media 40 €/h 30 €/h 27 €/h

Attività
50 €/h 35 €/h 30 €/h
difficile

Nel listino è gia considerato il margine di guadagno

 Processo di realizzazione del
preventivo

Livello 0
 Processo di realizzazione del
preventivo

Livello 1
Calcolo giorni/uomo: il team
 Il project manager stima quanti giorni/uomo
sono necessari, ovvero individua
approssimativamente quanto tempo
impiegherebbe una singola persona a
svolgere interamente il lavoro. Sulla base di
tale stima, il project manager decide quante
persone faranno parte del team in modo tale
che il lavoro stimato per una singola persona
venga diviso tra i membri del team e si riesca
così a rispettare la data di consegna al cliente
Calcolo giorni/uomo:lista
attività
 A questo punto il team stabilisce quali
saranno tutte le attività che si dovranno
fare e verranno stimati quanti
giorni/uomo sono necessari per
completare ciascuna attività
 Calcolo giorni/uomo:
mappatura

Livello 2 – Calcolo
giorni/uomo
Scelta prezzo orario
 Bisogna stabilire con esattezza quanto
costa al cliente un’ora di sviluppo del
progetto commissionato. Per fare ciò si
prendono in considerazione due parametri:
 - La durata del progetto: Ricavata dalla
data di consegna
 - La difficoltà del progetto: Valutata dal
project manager responsabile del progetto
 Scelta prezzo orario:
mappatura

Livello 2 – Decisione
prezzo orario
Costo finale
 Il costo finale del progetto è dato dalla
somma di:
- Prezzo orario scelto
- Spese straordinarie decise dal team
- Giorni/uomo stimati
Un esempio
 Illustriamo qui un esempio di calcolo di
preventivo discusso direttamente in
azienda. Il progetto riguarda lo sviluppo
di un software per un simulatore di volo
 Il cliente fornisce le specifiche. Si decide
di partire il 1 Luglio. Il project manager
valuta, in base al tipo di lavoro, il tempo
di sviluppo nel quale svolgere tutte le
attività necessarie.
Un esempio
 Si stima di completare il lavoro in un
tempo inferiore a quanto realmente ci
vorrebbe per realizzarlo, ovvero
prevedendo un margine temporale in
modo da avere dei giorni necessari per
gestire eventuali imprevisti.
 Si decide dunque che la consegna del
progetto è fissata per il 1 Novembre,
dunque durata lavori: 4 mesi.
Un esempio
 Il project manager, dunque, decide in
maniera del tutto soggettiva che la
stima iniziale per terminare il progetto è
di 12 mesi/uomo cioè una persona
impiegherebbe 12 mesi per sviluppare
tutto il progetto. Per attenersi ai tempi
di consegna che ci si è prefissati ovvero
ai 4mesi di tempo, si forma quindi un
team composto di 3 persone.
Un esempio
 Il team si riunisce per stilare la lista
delle attività
 Per ogni sottoattività il team specifica il
tempo di esecuzione (vengono incluse
anche riunioni, consegne, telefonate,
ecc.)
Un esempio
 Lista delle attività
 Stesura dell’offerta formale per il cliente
(1g x 3)
 Meeting kick-off assieme al cliente (1g x 3)
 Meeting intermedi assieme al cliente una
volta al mese (1g x 3 x 3)
 Acquisto server per lo sviluppo e
installazione SO (1g)
Un esempio
 Design protocollo comunicazione (10g)
 Implementazione protocollo comunicazione
(5g)
 Design interfaccia grafica (5g)
 Implementazione interfaccia grafica (10g)
 Salvataggio su file della configurazione (3g)
 Training al cliente (2g x 1)

51 giorni
Un esempio
51 giorni x 8 ore x 50€/4 +
(4 x 1000€) +
300€ Windows +
1000€ server

≈ 25300 €
Problematiche

 Le problematiche di questo tipo di

approccio sono molteplici:
 Imputazione dei costi indiretti

 Costi commerciali

 Costi nascosti

 Richieste di modifiche/varianti del

progetto
Imputazione dei costi indiretti
 L’azienda imputa i costi indiretti sulle
persone, ovvero considera tali costi
uniformemente divisibili tra gli
sviluppatori come se la loro incidenza
avvenga in maniera omogenea tra tutti.
Imputazione dei costi indiretti
 IN REALTA’
 Bisogna tenere conto della differenza di

produttività tra persone:

 Uno sviluppatore bravo svolge un
determinato compito in un tempo minore ad
un collega meno bravo, che impiegherà molto
più tempo e quindi indirettamente consumerà
più risorse. Colui che è maggiormente
produttivo può utilizzare il tempo risparmiato
per altre mansioni utili all’azienda
Imputazione dei costi indiretti
 Occorre guardare al carico di lavoro di
ciascun sviluppatore, imputando i costi
indiretti sulla base del loro orario effettivo
di lavoro.
 Chi lavora di più ha un’incidenza
maggiore sul totale dei costi indiretti
rispetto a chi lavora di meno. Il tutto è
sintetizzabile dalla logica: chi più lavora
più consuma.
Imputazione dei costi indiretti
 Sarebbe opportuno introdurre una sorta di
premialità, di incentivo alle persone.
 Se tutti sono responsabili della stessa
porzione di incidenza sui costi indiretti,
senza alcuna differenza tra loro, allora
non vi è alcun meccanismo di incentivo.
 Bisognerebbe premiare chi si rende utile
all’azienda anche sotto l’aspetto della
spesa economica.
Imputazione dei costi indiretti
 In definitiva l’azienda non si rende
conto di quanto possa avere inciso sui
costi indiretti un progetto piuttosto che
un altro; dunque è facile cadere nel
tranello di valutare in maniera
ottimistica il margine economico di una
commessa in quanto i costi indiretti
sono nascosti e non ben identificati
Costi indiretti: proposta
 La nostra proposta è stata quindi di
riuscire ad avere un sistema di gestione
che abbia come base di imputazione le
ore di lavoro di ogni persona in un
determinato progetto
 Così facendo, in fase di preventivo,
sarebbe più facile riuscire ad avere una
stima più accurata del costo indiretto
del progetto
Costi indiretti: proposta
 Si potrebbe quindi utilizzare un time
sheet personale per ogni sviluppatore,
che si impegna a registrare e tenere
aggiornato il totale delle ore
effettivamente trascorse sul progetto
 Con tale sistema, i membri del team
sarebbero consapevoli che ogni singola
ora del loro lavoro incide sul costo finale
del progetto
Costi indiretti: proposta
 I time sheet, che tengono memoria delle
ore trascorse sul progetto, sono in realtà
utilizzati dall’azienda ma ad essi non viene
data sufficiente importanza perché ogni
risorsa umana tende a riportare sul
personale time sheet di aver lavorato il
massimo delle ore possibili per una
giornata. E’ evidente che il problema non è
il sistema di gestione bensì la mancanza di
controlli su di esso
Costi indiretti: proposta
 La nostra idea proposta all’azienda è di
riuscire periodicamente ad effettuare
delle procedure di review che
consentano di intervistare il project
manager per sapere se i membri del
team hanno realmente lavorato per le
ore che hanno registrato sul time sheet.
Costi commerciali

 Tra le varie attività che vengono stimate

e che vanno a formare il preventivo,
l’azienda trascura le attività commerciali
(trattative con i clienti e con i fonitori).
Costi commerciali

 IN REALTA’
 Il tempo utilizzato per queste attività è
fondamentale e non va trascurato.
 Le attività commerciali sono costi a tutti gli
effetti che l’azienda sostiene e che, quindi,
vanno pattuiti col cliente e messi nel
preventivo
Costi commerciali
 Se tali costi non sono ben identificati,
l’azienda ne tiene in considerazione solo
nella valutazione del margine
economico.

DI CONSEGUENZA...
Costi commerciali
1. Tale margine non è profitto, ma
“nasconde” costi che l’azienda non ha
ben quantificato. Questo meccanismo
dà origine ad una distorsione del
calcolo della redditività, da cui
consegue una valutazione economica
diversa dalla realtà.
Costi commerciali

2. Tale meccanismo non professionalizza

l’aspetto commerciale del progetto, ma
viene trascurato e valutato in maniera
approssimativa, come se non incidesse
sull’economia del progetto.
Costi nascosti
 Spesso non vengono valutati i cosiddetti
costi nascosti (hidden costs o costi della
non-qualità), che rappresentano la
differenza tra i costi di un
prodotto/servizio e i costi dello stesso
prodotto/servizio se non ci fosse alcuna
possibilità di errore nell’approntarli.
Costi nascosti

 IN REALTA’
 L'analisi dei costi deve essere un elemento
fondamentale del controllo di qualità.
 Occorre ridurre il costo totale della qualità.
 Un sistema di controllo dei costi relativi alla
qualità deve essere considerato un
fondamentale strumento di gestione.
Costi nascosti
 Tutte le attività che vengono stimate per
realizzare il preventivo devono essere
esaustive e non tralasciare alcun aspetto che
può incidere sulla qualità del prodotto
software e di conseguenza sul prezzo finale.
Tutti gli imprevisti che si verificano in fase di
sviluppo creano uno scostamento tra il valore
stimato in preventivo e l’effettivo costo del
progetto. Bisognerebbe riuscire a prevedere
gli imprevisti in modo da evitare spese
aggiuntive non considerate a priori
Costi nascosti: proposta
 Abbiamo chiesto (senza esito postivo)
all’azienda Evidence di analizzare un
progetto che hanno precedentemente
svolto. L’idea era quella di creare una
check-list con possibili attività del team in
quella specifica commessa e chiedere ad
ogni sviluppatore quali difficoltà o
situazioni anomale gli si fossero presentate
e se avessero causato un cambiamento di
programmi rispetto a quanto prefissato
Costi nascosti: proposta
 Una raccolta di queste informazioni può
essere utile all’azienda per mettere in
atto un sistema di gestione che metta il
Project Manager in allerta con dei
warning qualora il team proceda in una
direzione diversa dalla rotta che si è
deciso di seguire fin dall’inizio
Modifiche/varianti
 L’accettazione di richieste di modifiche o
varianti al progetto da parte del cliente
non viene gestita in maniera
sistematica, ma di volta in volta viene
valutata la situazione
Modifiche/varianti
 IN REALTA’
 Occorre attuare uno stretto controllo delle
varianti, per limitare al massimo gli
imprevisti.
 Il mancato controllo indebolisce le
trattative con i clienti.
Modifiche/varianti
 Se tali modifiche implicano una variazione
sostanziale di prezzo rispetto al
preventivo, è necessario chiedere al cliente
un meeting per decidere il da farsi: si
convoca il cliente, si discute insieme a lui
delle modifiche da apportare, si propone
una variazione di prezzo necessaria per le
nuove attività da fare ed, infine, si chiede
al cliente l’autorizzazione a procedere
Casi di studio
 Abbiamo quindi analizzato in
particolare un caso di studio
riguardante una situazione che
si è presentata in passato e la
relativa soluzione al problema.
Software per aeronavigazione
 INTRODUZIONE
 Un'azienda ci commissiona lo sviluppo di
una soluzione hardware/software con
sensori per la risoluzione di problemi legati
alla logistica del traffico. Presentiamo
un'offerta unica che comprenda anche lo
sviluppo dell'hardware, per il quale ci
affidiamo al nostro fornitore di fiducia
mediante accordi verbali.
Software per aeronavigazione

 PROBLEMI RISCONTRATI
 Il fornitore fornisce l’hardware in ritardo.
 La parte in Radio-Frequenza sull’hardware
non funziona.
 Il fornitore cambia completamente
l’hardware dopo la prima milestone.
Software per aeronavigazione
 LEZIONI IMPARATE
 Occorre avere sempre accordi formali e per iscritto
anche con i fornitori/clienti di fiducia.
 Gli accordi devono prevedere una specifica chiara
di ciò che verrà fornito ed i tempi massimi di
consegna.
 Il cliente ha dovuto per forza di cose interagire
con il progettista hardware, che con il tempo ha
guadagnato la simpatia del cliente, facendo
risultare ai suoi occhi molti dei problemi del
sistema come causati unicamente dallo sviluppo
software.