SlideShare a Scribd company logo
1 of 153
Download to read offline
PERCHÉ A FARE I PREVENTIVI
FACCIAMO COSÌ SCHIFO?        CRISTIANO RASTELLI
Table of contents

  Flying to the moon
  Una piccola storia
  Coders are special
  My experience
  Let’s play “quote”
  Costi nascosti
  Side-effects
  Alcuni riferimenti
  Conclusioni
Caveat
FLYING TO
THE MOON
Flying to the moon
I progetti “Mercury” e “Gemini”, a cui si riferiscono queste
immagini, sono state due serie di missioni spaziali, condotte
dalla NASA con lo scopo di acquisire il know-how e le
competenze necessarie per portare, in poco meno di dieci
anni, il primo uomo sulla Luna.
Hanno ottenuto risultati mai raggiunti prima d’allora:
   primo equipaggio in orbita attorno alla terra
   prima “camminata” di un astronauta nello spazio
   primo rendez-vous e attracco fra due veicoli spaziali
Flying to the moon


               25 maggio 1961

               “I believe that this nation should
                commit itself to achieving
                 the goal, before this decade is out,
                  of landing a man on the moon
                  and returning him safely to the earth”

                   President John F. Kennedy
Flying to the moon
E’ stato il maggior sforzo economico, tecnologico e
scientifico mai sostenuto dagli USA, assieme al Progetto
Manhattan e alla costruzione dello stretto di Panama.

                Costo del Programma Apollo (miliardi di dollari)
       30

       25

       20

       15

       10

        5

       0
            Stima iniziale   Stima J. Webb   Stima finale   Costo finale
Preventivare
    non si può “andare corti”
    budget stanziati dal committente



Prevedere *
Occorre sapere valutare e analizzare:
    ogni minimo dettaglio (dalla vite allo stadio propulsivo)
    ogni possibile/probabile futura necessità
    tutti i possibili casi, non solo il “best-case scenario”.

* Non significa essere degli indovini o fare oracoli sul futuro...
Flying to the moon




       20 luglio 1969   Buzz Aldrin
UNA
PICCOLA
 STORIA
Cirpo




        “Ma sì, ma quanto vuoi metterci a...”
Una piccola storia / 1
Una sera, mentre stavamo facendo una conference-call via
Skype per l’organizzazione della Node.js Conference, si
stava parlando di totem da piazzare agli ingressi della sala.
Io sostenevo che meno cose c’erano da fare, meglio era
(c’erano altre mille cose da fare, ricordare, organizzare).
A un certo punto Cirpo se ne è uscito con questa frase:
“Ma sì, ma quanto vuoi metterci? Tanto le fa Riccardo”.
E qui mi si è accesa una lampadina: stava completamente
tralasciando tutti gli aspetti collaterali dell’attività che non
fossero la semplice, mera esecuzione materiale.
Una piccola storia / 2
E mi sono fatto questa domanda: ma perché i DEV in
particolare – ma gli esseri umani in generale – sono così
pessimi a fare stime e preventivi?
Forse, ho pensato, c’è un motivo antropologico, qualcosa
che condiziona il nostro cervello e lo induce a sottovalutare
sistematicamente gli sforzi (gli “effort”) per permettere agli
uomini di osare di più, di fare cose che normalmente non
farebbero e “selezionare la specie” più intraprendente?
In ogni caso, mi sono proposto che avrei tenuto un talk su
questo tema, in cui fare “pelo e contropelo” ai DEV.
Perciò, eccomi qui!
CODERS
   ARE
SPECIAL
You’re not that special, devs!
Coders are not special!
Da che mondo e mondo pittori, artisti, artigiani, architetti,
ingegneri, costruttori, tutti quanti hanno dovuto produrre
progetti e stime di costo ex-ante.
Tutti coloro che devono “creare” qualcosa che prima non
esisteva, che disegnano e progettano soluzioni su misura,
che producono e realizzano prodotti “non standardizzati”.
In molti casi (la buona parte?) hanno sbagliato stima.
Noi non facciamo eccezione.

Il punto qui però è: come fare un preventivo che abbia il
minor margine di errore possibile?
Gli strumenti giusti
Nessuno ti può insegnare
La verità è che fare preventivi è come educare i figli: puoi
trovare manuali ovunque, puoi chiedere consigli a chiunque
ma alla fine qualunque “metodo” deciderai di adottare ti
sembrerà comunque imperfetto, troppo “astratto”, che non
tiene conto del tuo caso particolare/speciale.
Perché, come per i figli, fare un preventivo ti tocca da
vicino, ha a che fare con il tuo “vissuto quotidiano”.
Con le tue esperienze pregresse.
Con il tuo senso di auto-stima.
Con l’amore per il tuo lavoro.
Con il tuo conto in banca.
MY EXPERIENCE
My experience
Quindi non son qui
per darvi nessun
tipo di “lezione”.
Tantomeno per
esporvi teorie su
come elaborare il
preventivo perfetto
e infallibile.
Sono qui per
raccontarvi la
mia esperienza.
3... 2... 1... Via!
Gli inizi
Passato - Tipo A
Passato - Tipo B
Presente - Tipo A
Presente - Tipo B
Futuro
Cosa ho imparato
Cosa ho imparato
  Separare mentalmente (e fisicamente) il ragionamento
  fra le attività da realizzare (quindi il progetto) e il
  tempo che occorre a realizzarle (quindi il preventivo)
  In questo modo si perde meno di vista l’obiettivo del preventivo, che è
  quello di fornire una stima/valutazione economica al proprio cliente dei
  costi di ideazione/progettazione/realizzazione di una determinata attività.

  Ragionare in termini di giorno-uomo ideale (di 8 ore)*
  (poi magari ce ne impieghi 12, ma quello è comunque il tuo parametro di
  riferimento temporale, la tua “unità di misura” di base)

  Tenere sempre a bada la vocina che è in noi.
  Quella che ormai riconosciamo, quella che ci fa dire “ma sì, ma cosa vuoi
  metterci a” oppure “non sarà caro? e se poi per il cliente è troppo?” e alla
  fine ci porta a sottostimare gli effort di un progetto, specie se complesso.
Cosa ho imparato
  Il cliente guarda la cifra in basso a destra.
  Non c’è nulla da fare, è un dato di fatto oggettivo. Come il sole che sorge
  e tramonta. Occorre farsene una ragione e agire di conseguenza.

  Decidere (a seconda del cliente) cosa mostrare e cosa
  invece omettere (o non specificare affatto)
  Ad esempio la suddivisione del progetto in sotto-attività oppure il numero
  di giornate previste per ogni singola voce e/o il costo a giornata.

  Ci sono tipi diversi di clienti.
  A noi il compito di capire chi è l’interlocutore che abbiamo di fronte, cosa
  ci sta chiedendo, che tipo di risposta dare, in che forma comunicargli la
  nostra proposta progettuale/economica.
  A noi il compito di decidere se e quanto del nostro tempo dedicare
  (ovvero investire) nella redazione del preventivo.
LET’S PLAY “QUOTE”
Let’s play “quote”
Let’s play “quote”
  Decidere assieme allo staff se fare le magliette per la conferenza
  • Fare email allo staff + polling/doodle
  Chiedere se qualcuno ha conoscenza/esperienza di stampatori di t-shirt
  Chiedere preventivo a 2 o 3 diversi stampatori di magliette
  • Fare email in cui si spiega cosa serve, come saranno le magliette, ecc.
  Confrontare fra loro i tre preventivi ricevuti
  • Cercare su internet il prezzo medio di una maglietta, per confronto
  • Decidere assieme agli altri membri dello staff quale scegliere
  Preparare le bozze grafiche delle magliette (con diverse soluzioni)
  • Cercare su internet i colori disponibili per le magliette
  • Scegliere il colore e ideare la grafica da far stampare sulle magliette
  • Realizzare i file grafici (vettoriali e/o bitmap alta risoluzione)
Let’s play “quote”
  Decidere la grafica finale delle magliette
  • Sottoporre via email le soluzioni ideate/create ai membri dello staff
  • Leggere risposte/commenti e rispondere a propria volta
  • Modificare la bozza sulla base delle indicazioni ricevute
  • Scegliere soluzione definitiva assieme allo staff (con polling/doodle)
  Raccogliere le prenotazioni per le magliette
  • Creare form online con Google Docs
  • Creare pagina web per embedding e raccolta dati “clienti”
  Decidere quante magliette far stampare
  • Estrarre da foglio di calcolo i numeri aggregati per sesso, taglia, colore
  • Calcolare numero magliette aggiuntive da vendere il giorno della conf
  Ordinare le magliette allo stampatore
  • Mandare numeri e grafica finale allo stampatore per quotazione finale
Let’s play “quote”
  Preparare i file grafici definitivi per lo stampatore (in diversi formati)
  • Inviare email allo stampatore con i dettagli tecnici dei file allegati
  Passare dallo stampatore per accordarsi, firmare l’ordine e dare l’acconto
  • Passare da chi ha la cassa per prendere i soldi da dare allo stampatore
  Chiamare stampatore per avere conferma della data di consegna
  Chiamare stampatore per accordarsi sul ritiro delle magliette
  Passare a ritirare le magliette dallo stampatore
  • Verificare la stampa delle magliette, pagare e caricare gli scatoloni
  Consegnare le magliette a chi le “venderà” il giorno della conferenza
  • Preparare foglio excel con la lista delle prenotazioni effettuate
  • Portare scatoloni a casa degli incaricati, per permettergli di suddividere
    le magliette per tipo, colore, taglia, ecc.
COSTI NASCOSTI
Costi nascosti
  Incontri preliminari
  Presentazione, raccolta dei requisiti, redazione del preventivo,
  illustrazione dell’offerta, trattative per definizione budget finale.

  Attività kickoff
  Pianificazione delle attività, boostrap del progetto, attribuzione dei task.

  Riunioni in corso d’opera
  Incontri per richieste di modifiche, attività integrative, raccolta feedback,
  avanzamento lavori, consegna del prodotto, eventuale formazione.

  Gestione del progetto
  Mantenimento delle relazioni con il cliente ed eventuali suoi fornitori di
  servizi, coordinamento delle attività dei propri collaboratori, redazione
  documenti di progetto, lettura/scrittura delle email.
Costi nascosti
  Attività non previste
  Richieste e/o modifiche e/o integrazioni in corso d’opera.
  Variazione degli obiettivi di progetto al mutare degli interlocutori.

  Attività sottovalutate
  “Beh, ma quanto vuoi metterci a...”.
  Tempi di acquisizione di nuove competenze.
  Curve di apprendimento più lunghe del previsto.

  Attività collaterali/a conclusione del progetto
  Registrazione nei motori di ricerca, attivazione statistiche, creazione di
  account e configurazione profili su social network e servizi online.

  Varie ed eventuali
  Tempi di trasferta, anticipi economici (acquisto servizi/prodotti per conto
  del cliente, iva, tasse, ecc.), solleciti dei pagamenti, recupero crediti.
SIDE-EFFECTS
Side-effects
  Ritardo nella consegna

  • (e nell’avvio dei progetti successivi)

  Credibilità personale

  Professionalità dimostrata

  Remuneratività del lavoro

  Qualità complessiva
L’effetto più importante


  Sbagliare l’effort
  di un preventivo
  ha impatto diretto
  sulla qualità
  del lavoro ultimato.
ALCUNI
RIFERIMENTI
“bias cognitivo”
Planning fallacy
“Tendenza delle persone/organizzazioni a sotto-stimare il
tempo che impiegano ad eseguire un determinato task,
anche se hanno già avuto esperienze pregresse di ritardo
per task simili”. (fonte: wikipedia, as usual)
Un effetto di “blind spot”


  Sottostima
  di tempo, costi
  e rischi

  Sovrastima
  dei benefici
Possibili spiegazioni


   1
          Focus sul best-case scenario: *

          Wishful-thinking



   2
          Mancanza di analisi puntuale:

          No-Breakdown

          * “Massì, ma quanto vuoi metterci a...”
E’una questione di dettagli




http://www.quora.com/Engineering-Management/Why-are-software-
development-task-estimations-regularly-off-by-a-factor-of-2-3
“breakdown”
Work Breakdown Structure
E’ una metodologia di project-management, introdotta
dalla difesa americana e poi adottata e sviluppata proprio
dalla NASA per la gestione dei progetti Mercury e Gemini:

       prodotto (“deliverable”), non attività
           cosa, non come o in quanto!

       decomposizione del problema
           albero gerarchico
                                        misurabilità
       singoli elementi discreti
            migliore stima di tempi e costi
Work Breakdown Structure
“cost overrun”
Non siamo soli...
 Sydney Opera House
 Canale di Suez
 Concorde
 Canale sotto la Manica
 Eurofighter
 Denver International Airport
 Millennium Dome
 Telescopio Hubble
 and more...
CONCLUSIONI
Consigli
1. Prevedere. Non solo preventivare.

2. Numeri. Non solo funzionalità.

3. Non sottovalutate gli effort.

4. Non mettetevi nei panni del cliente, ma nei vostri!

5. E’ un processo “trial & error”, rassegnatevi.

6. Non perdete mai di vista la qualità finale del prodotto.

7. Piuttosto meno cose, se dovete stare in un budget.
Grazie!
CrSIo RaTl



 www.didoo.net
    @areaweb
Credits




   http://www.nasa.gov/   http://tothemoon.ser.asu.edu

More Related Content

Similar to Perché a fare i preventivi facciamo così schifo? @CodemotionRoma 2102

Kolbe 2012 ven20gennaio_ok
Kolbe 2012 ven20gennaio_okKolbe 2012 ven20gennaio_ok
Kolbe 2012 ven20gennaio_okmacripur
 
Ldb Make Your Own Collaborative place_Elaborazione e analisi di uno speech - ...
Ldb Make Your Own Collaborative place_Elaborazione e analisi di uno speech - ...Ldb Make Your Own Collaborative place_Elaborazione e analisi di uno speech - ...
Ldb Make Your Own Collaborative place_Elaborazione e analisi di uno speech - ...laboratoridalbasso
 
Brainstorming
BrainstormingBrainstorming
Brainstormingbrunocip
 
Smau Bologna|R2B 2019 Giovanni Battista Coiante
Smau Bologna|R2B 2019 Giovanni Battista CoianteSmau Bologna|R2B 2019 Giovanni Battista Coiante
Smau Bologna|R2B 2019 Giovanni Battista CoianteSMAU
 
IL CROWDFUNDING PER LE ICC - 14 MARZO 2023.pdf
IL CROWDFUNDING PER LE ICC - 14 MARZO 2023.pdfIL CROWDFUNDING PER LE ICC - 14 MARZO 2023.pdf
IL CROWDFUNDING PER LE ICC - 14 MARZO 2023.pdfAntonio Lepore ✔ ✈
 
Premio pa sostenibile_2019_template_word inps sardegna ultima
Premio pa sostenibile_2019_template_word inps sardegna ultimaPremio pa sostenibile_2019_template_word inps sardegna ultima
Premio pa sostenibile_2019_template_word inps sardegna ultimaGianFrancoOnnis1
 
Design thinking: Redesign the school-to-work transition
Design thinking: Redesign the school-to-work transitionDesign thinking: Redesign the school-to-work transition
Design thinking: Redesign the school-to-work transitionDaniele Iori
 
Zero budget marketing. Quando le idee contano più del portafogli
Zero budget marketing. Quando le idee contano più del portafogliZero budget marketing. Quando le idee contano più del portafogli
Zero budget marketing. Quando le idee contano più del portafogliSimone Moriconi
 
Perdere il controllo (con note)
Perdere il controllo (con note)Perdere il controllo (con note)
Perdere il controllo (con note)Cristiano Rastelli
 
eBook-Copywriting-Madri
eBook-Copywriting-MadrieBook-Copywriting-Madri
eBook-Copywriting-MadriLuca Catania
 
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16Hoang Huynh
 
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16PRSD
 
OneBookOnePage #3 - Talent is Overrated
OneBookOnePage #3 - Talent is OverratedOneBookOnePage #3 - Talent is Overrated
OneBookOnePage #3 - Talent is OverratedMauro Massironi
 

Similar to Perché a fare i preventivi facciamo così schifo? @CodemotionRoma 2102 (20)

Kolbe 2012 ven20gennaio_ok
Kolbe 2012 ven20gennaio_okKolbe 2012 ven20gennaio_ok
Kolbe 2012 ven20gennaio_ok
 
Ldb Make Your Own Collaborative place_Elaborazione e analisi di uno speech - ...
Ldb Make Your Own Collaborative place_Elaborazione e analisi di uno speech - ...Ldb Make Your Own Collaborative place_Elaborazione e analisi di uno speech - ...
Ldb Make Your Own Collaborative place_Elaborazione e analisi di uno speech - ...
 
Lab2 Lecture, 7 march 2017
Lab2 Lecture, 7 march 2017 Lab2 Lecture, 7 march 2017
Lab2 Lecture, 7 march 2017
 
Catalog of the fair
Catalog of the fair Catalog of the fair
Catalog of the fair
 
Catalogo della Fiera - V200915
Catalogo della Fiera - V200915Catalogo della Fiera - V200915
Catalogo della Fiera - V200915
 
Catalogo Fiera - V201001
Catalogo Fiera - V201001Catalogo Fiera - V201001
Catalogo Fiera - V201001
 
Brainstorming
BrainstormingBrainstorming
Brainstorming
 
Smau Bologna|R2B 2019 Giovanni Battista Coiante
Smau Bologna|R2B 2019 Giovanni Battista CoianteSmau Bologna|R2B 2019 Giovanni Battista Coiante
Smau Bologna|R2B 2019 Giovanni Battista Coiante
 
Compiti di realtà
Compiti di realtàCompiti di realtà
Compiti di realtà
 
IL CROWDFUNDING PER LE ICC - 14 MARZO 2023.pdf
IL CROWDFUNDING PER LE ICC - 14 MARZO 2023.pdfIL CROWDFUNDING PER LE ICC - 14 MARZO 2023.pdf
IL CROWDFUNDING PER LE ICC - 14 MARZO 2023.pdf
 
Premio pa sostenibile_2019_template_word inps sardegna ultima
Premio pa sostenibile_2019_template_word inps sardegna ultimaPremio pa sostenibile_2019_template_word inps sardegna ultima
Premio pa sostenibile_2019_template_word inps sardegna ultima
 
Design thinking: Redesign the school-to-work transition
Design thinking: Redesign the school-to-work transitionDesign thinking: Redesign the school-to-work transition
Design thinking: Redesign the school-to-work transition
 
Zero budget marketing. Quando le idee contano più del portafogli
Zero budget marketing. Quando le idee contano più del portafogliZero budget marketing. Quando le idee contano più del portafogli
Zero budget marketing. Quando le idee contano più del portafogli
 
Un anno di startup
Un anno di startupUn anno di startup
Un anno di startup
 
Perdere il controllo (con note)
Perdere il controllo (con note)Perdere il controllo (con note)
Perdere il controllo (con note)
 
eBook-Copywriting-Madri
eBook-Copywriting-MadrieBook-Copywriting-Madri
eBook-Copywriting-Madri
 
Ppt lumsa 2
Ppt lumsa 2Ppt lumsa 2
Ppt lumsa 2
 
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
 
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
Riconoscere e Gestire il Debito UX - Agile Business Day 2016 #ABD16
 
OneBookOnePage #3 - Talent is Overrated
OneBookOnePage #3 - Talent is OverratedOneBookOnePage #3 - Talent is Overrated
OneBookOnePage #3 - Talent is Overrated
 

More from Codemotion

Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...Codemotion
 
Pompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending storyPompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending storyCodemotion
 
Pastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storiaPastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storiaCodemotion
 
Pennisi - Essere Richard Altwasser
Pennisi - Essere Richard AltwasserPennisi - Essere Richard Altwasser
Pennisi - Essere Richard AltwasserCodemotion
 
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...Codemotion
 
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019Codemotion
 
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019Codemotion
 
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 - Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 - Codemotion
 
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...Codemotion
 
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...Codemotion
 
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...Codemotion
 
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Codemotion
 
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019Codemotion
 
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019Codemotion
 
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019Codemotion
 
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...Codemotion
 
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...Codemotion
 
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019Codemotion
 
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019Codemotion
 
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Codemotion
 

More from Codemotion (20)

Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
 
Pompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending storyPompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending story
 
Pastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storiaPastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storia
 
Pennisi - Essere Richard Altwasser
Pennisi - Essere Richard AltwasserPennisi - Essere Richard Altwasser
Pennisi - Essere Richard Altwasser
 
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
 
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
 
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
 
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 - Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 -
 
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
 
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
 
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
 
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
 
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
 
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
 
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
 
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
 
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
 
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
 
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
 
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
 

Perché a fare i preventivi facciamo così schifo? @CodemotionRoma 2102

  • 1. PERCHÉ A FARE I PREVENTIVI FACCIAMO COSÌ SCHIFO? CRISTIANO RASTELLI
  • 2. Table of contents Flying to the moon Una piccola storia Coders are special My experience Let’s play “quote” Costi nascosti Side-effects Alcuni riferimenti Conclusioni
  • 5. Flying to the moon I progetti “Mercury” e “Gemini”, a cui si riferiscono queste immagini, sono state due serie di missioni spaziali, condotte dalla NASA con lo scopo di acquisire il know-how e le competenze necessarie per portare, in poco meno di dieci anni, il primo uomo sulla Luna. Hanno ottenuto risultati mai raggiunti prima d’allora: primo equipaggio in orbita attorno alla terra prima “camminata” di un astronauta nello spazio primo rendez-vous e attracco fra due veicoli spaziali
  • 6. Flying to the moon 25 maggio 1961 “I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth” President John F. Kennedy
  • 7. Flying to the moon E’ stato il maggior sforzo economico, tecnologico e scientifico mai sostenuto dagli USA, assieme al Progetto Manhattan e alla costruzione dello stretto di Panama. Costo del Programma Apollo (miliardi di dollari) 30 25 20 15 10 5 0 Stima iniziale Stima J. Webb Stima finale Costo finale
  • 8. Preventivare non si può “andare corti” budget stanziati dal committente Prevedere * Occorre sapere valutare e analizzare: ogni minimo dettaglio (dalla vite allo stadio propulsivo) ogni possibile/probabile futura necessità tutti i possibili casi, non solo il “best-case scenario”. * Non significa essere degli indovini o fare oracoli sul futuro...
  • 9. Flying to the moon 20 luglio 1969 Buzz Aldrin
  • 11. Cirpo “Ma sì, ma quanto vuoi metterci a...”
  • 12. Una piccola storia / 1 Una sera, mentre stavamo facendo una conference-call via Skype per l’organizzazione della Node.js Conference, si stava parlando di totem da piazzare agli ingressi della sala. Io sostenevo che meno cose c’erano da fare, meglio era (c’erano altre mille cose da fare, ricordare, organizzare). A un certo punto Cirpo se ne è uscito con questa frase: “Ma sì, ma quanto vuoi metterci? Tanto le fa Riccardo”. E qui mi si è accesa una lampadina: stava completamente tralasciando tutti gli aspetti collaterali dell’attività che non fossero la semplice, mera esecuzione materiale.
  • 13. Una piccola storia / 2 E mi sono fatto questa domanda: ma perché i DEV in particolare – ma gli esseri umani in generale – sono così pessimi a fare stime e preventivi? Forse, ho pensato, c’è un motivo antropologico, qualcosa che condiziona il nostro cervello e lo induce a sottovalutare sistematicamente gli sforzi (gli “effort”) per permettere agli uomini di osare di più, di fare cose che normalmente non farebbero e “selezionare la specie” più intraprendente? In ogni caso, mi sono proposto che avrei tenuto un talk su questo tema, in cui fare “pelo e contropelo” ai DEV. Perciò, eccomi qui!
  • 14. CODERS ARE SPECIAL
  • 15. You’re not that special, devs!
  • 16. Coders are not special! Da che mondo e mondo pittori, artisti, artigiani, architetti, ingegneri, costruttori, tutti quanti hanno dovuto produrre progetti e stime di costo ex-ante. Tutti coloro che devono “creare” qualcosa che prima non esisteva, che disegnano e progettano soluzioni su misura, che producono e realizzano prodotti “non standardizzati”. In molti casi (la buona parte?) hanno sbagliato stima. Noi non facciamo eccezione. Il punto qui però è: come fare un preventivo che abbia il minor margine di errore possibile?
  • 18. Nessuno ti può insegnare La verità è che fare preventivi è come educare i figli: puoi trovare manuali ovunque, puoi chiedere consigli a chiunque ma alla fine qualunque “metodo” deciderai di adottare ti sembrerà comunque imperfetto, troppo “astratto”, che non tiene conto del tuo caso particolare/speciale. Perché, come per i figli, fare un preventivo ti tocca da vicino, ha a che fare con il tuo “vissuto quotidiano”. Con le tue esperienze pregresse. Con il tuo senso di auto-stima. Con l’amore per il tuo lavoro. Con il tuo conto in banca.
  • 20. My experience Quindi non son qui per darvi nessun tipo di “lezione”. Tantomeno per esporvi teorie su come elaborare il preventivo perfetto e infallibile. Sono qui per raccontarvi la mia esperienza.
  • 23.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
  • 40.
  • 41.
  • 42.
  • 43.
  • 44.
  • 45.
  • 46.
  • 47.
  • 48.
  • 49.
  • 50.
  • 51.
  • 52.
  • 53.
  • 54.
  • 55.
  • 56.
  • 57.
  • 58.
  • 59.
  • 60.
  • 61.
  • 62.
  • 63.
  • 64.
  • 65.
  • 66.
  • 67.
  • 68.
  • 69.
  • 70.
  • 71.
  • 72.
  • 73.
  • 74.
  • 75.
  • 76.
  • 77.
  • 78.
  • 79.
  • 80.
  • 81.
  • 82.
  • 83.
  • 84.
  • 85.
  • 86.
  • 87.
  • 88.
  • 89.
  • 90.
  • 91.
  • 92.
  • 93.
  • 94.
  • 95.
  • 96.
  • 97.
  • 98.
  • 99.
  • 100.
  • 101.
  • 102.
  • 103.
  • 104.
  • 105.
  • 106.
  • 108.
  • 109.
  • 110.
  • 111.
  • 113.
  • 114.
  • 115.
  • 116.
  • 117.
  • 118.
  • 119.
  • 120.
  • 121.
  • 122.
  • 123. Futuro
  • 124.
  • 126. Cosa ho imparato Separare mentalmente (e fisicamente) il ragionamento fra le attività da realizzare (quindi il progetto) e il tempo che occorre a realizzarle (quindi il preventivo) In questo modo si perde meno di vista l’obiettivo del preventivo, che è quello di fornire una stima/valutazione economica al proprio cliente dei costi di ideazione/progettazione/realizzazione di una determinata attività. Ragionare in termini di giorno-uomo ideale (di 8 ore)* (poi magari ce ne impieghi 12, ma quello è comunque il tuo parametro di riferimento temporale, la tua “unità di misura” di base) Tenere sempre a bada la vocina che è in noi. Quella che ormai riconosciamo, quella che ci fa dire “ma sì, ma cosa vuoi metterci a” oppure “non sarà caro? e se poi per il cliente è troppo?” e alla fine ci porta a sottostimare gli effort di un progetto, specie se complesso.
  • 127. Cosa ho imparato Il cliente guarda la cifra in basso a destra. Non c’è nulla da fare, è un dato di fatto oggettivo. Come il sole che sorge e tramonta. Occorre farsene una ragione e agire di conseguenza. Decidere (a seconda del cliente) cosa mostrare e cosa invece omettere (o non specificare affatto) Ad esempio la suddivisione del progetto in sotto-attività oppure il numero di giornate previste per ogni singola voce e/o il costo a giornata. Ci sono tipi diversi di clienti. A noi il compito di capire chi è l’interlocutore che abbiamo di fronte, cosa ci sta chiedendo, che tipo di risposta dare, in che forma comunicargli la nostra proposta progettuale/economica. A noi il compito di decidere se e quanto del nostro tempo dedicare (ovvero investire) nella redazione del preventivo.
  • 130. Let’s play “quote” Decidere assieme allo staff se fare le magliette per la conferenza • Fare email allo staff + polling/doodle Chiedere se qualcuno ha conoscenza/esperienza di stampatori di t-shirt Chiedere preventivo a 2 o 3 diversi stampatori di magliette • Fare email in cui si spiega cosa serve, come saranno le magliette, ecc. Confrontare fra loro i tre preventivi ricevuti • Cercare su internet il prezzo medio di una maglietta, per confronto • Decidere assieme agli altri membri dello staff quale scegliere Preparare le bozze grafiche delle magliette (con diverse soluzioni) • Cercare su internet i colori disponibili per le magliette • Scegliere il colore e ideare la grafica da far stampare sulle magliette • Realizzare i file grafici (vettoriali e/o bitmap alta risoluzione)
  • 131. Let’s play “quote” Decidere la grafica finale delle magliette • Sottoporre via email le soluzioni ideate/create ai membri dello staff • Leggere risposte/commenti e rispondere a propria volta • Modificare la bozza sulla base delle indicazioni ricevute • Scegliere soluzione definitiva assieme allo staff (con polling/doodle) Raccogliere le prenotazioni per le magliette • Creare form online con Google Docs • Creare pagina web per embedding e raccolta dati “clienti” Decidere quante magliette far stampare • Estrarre da foglio di calcolo i numeri aggregati per sesso, taglia, colore • Calcolare numero magliette aggiuntive da vendere il giorno della conf Ordinare le magliette allo stampatore • Mandare numeri e grafica finale allo stampatore per quotazione finale
  • 132. Let’s play “quote” Preparare i file grafici definitivi per lo stampatore (in diversi formati) • Inviare email allo stampatore con i dettagli tecnici dei file allegati Passare dallo stampatore per accordarsi, firmare l’ordine e dare l’acconto • Passare da chi ha la cassa per prendere i soldi da dare allo stampatore Chiamare stampatore per avere conferma della data di consegna Chiamare stampatore per accordarsi sul ritiro delle magliette Passare a ritirare le magliette dallo stampatore • Verificare la stampa delle magliette, pagare e caricare gli scatoloni Consegnare le magliette a chi le “venderà” il giorno della conferenza • Preparare foglio excel con la lista delle prenotazioni effettuate • Portare scatoloni a casa degli incaricati, per permettergli di suddividere le magliette per tipo, colore, taglia, ecc.
  • 134. Costi nascosti Incontri preliminari Presentazione, raccolta dei requisiti, redazione del preventivo, illustrazione dell’offerta, trattative per definizione budget finale. Attività kickoff Pianificazione delle attività, boostrap del progetto, attribuzione dei task. Riunioni in corso d’opera Incontri per richieste di modifiche, attività integrative, raccolta feedback, avanzamento lavori, consegna del prodotto, eventuale formazione. Gestione del progetto Mantenimento delle relazioni con il cliente ed eventuali suoi fornitori di servizi, coordinamento delle attività dei propri collaboratori, redazione documenti di progetto, lettura/scrittura delle email.
  • 135. Costi nascosti Attività non previste Richieste e/o modifiche e/o integrazioni in corso d’opera. Variazione degli obiettivi di progetto al mutare degli interlocutori. Attività sottovalutate “Beh, ma quanto vuoi metterci a...”. Tempi di acquisizione di nuove competenze. Curve di apprendimento più lunghe del previsto. Attività collaterali/a conclusione del progetto Registrazione nei motori di ricerca, attivazione statistiche, creazione di account e configurazione profili su social network e servizi online. Varie ed eventuali Tempi di trasferta, anticipi economici (acquisto servizi/prodotti per conto del cliente, iva, tasse, ecc.), solleciti dei pagamenti, recupero crediti.
  • 137. Side-effects Ritardo nella consegna • (e nell’avvio dei progetti successivi) Credibilità personale Professionalità dimostrata Remuneratività del lavoro Qualità complessiva
  • 138. L’effetto più importante Sbagliare l’effort di un preventivo ha impatto diretto sulla qualità del lavoro ultimato.
  • 141. Planning fallacy “Tendenza delle persone/organizzazioni a sotto-stimare il tempo che impiegano ad eseguire un determinato task, anche se hanno già avuto esperienze pregresse di ritardo per task simili”. (fonte: wikipedia, as usual)
  • 142. Un effetto di “blind spot” Sottostima di tempo, costi e rischi Sovrastima dei benefici
  • 143. Possibili spiegazioni 1 Focus sul best-case scenario: * Wishful-thinking 2 Mancanza di analisi puntuale: No-Breakdown * “Massì, ma quanto vuoi metterci a...”
  • 144. E’una questione di dettagli http://www.quora.com/Engineering-Management/Why-are-software- development-task-estimations-regularly-off-by-a-factor-of-2-3
  • 146. Work Breakdown Structure E’ una metodologia di project-management, introdotta dalla difesa americana e poi adottata e sviluppata proprio dalla NASA per la gestione dei progetti Mercury e Gemini: prodotto (“deliverable”), non attività cosa, non come o in quanto! decomposizione del problema albero gerarchico misurabilità singoli elementi discreti migliore stima di tempi e costi
  • 149. Non siamo soli... Sydney Opera House Canale di Suez Concorde Canale sotto la Manica Eurofighter Denver International Airport Millennium Dome Telescopio Hubble and more...
  • 151. Consigli 1. Prevedere. Non solo preventivare. 2. Numeri. Non solo funzionalità. 3. Non sottovalutate gli effort. 4. Non mettetevi nei panni del cliente, ma nei vostri! 5. E’ un processo “trial & error”, rassegnatevi. 6. Non perdete mai di vista la qualità finale del prodotto. 7. Piuttosto meno cose, se dovete stare in un budget.
  • 153. Credits http://www.nasa.gov/ http://tothemoon.ser.asu.edu