Perché le stime delle attività di sviluppo software sono regolarmente sfasate di un fattore 2-3?

Questa è una risposta alla domanda di Quora: Perché le stime non sono esatte?

Ci sono diversi fattori per questo. Ecco alcuni comuni:

1) Il cliente non è tecnico e sente che “tutto è facile”

Sviluppare un software non è così facile come sembra.

Anche se sembra facile, a volte è meglio omettere determinate attività.

  • Per fare un’analogia:

C’è un’enorme collina e dobbiamo costruire una ferrovia. Gli sviluppatori consiglieranno: “Meglio evitare la collina e costruire la pista intorno alla collina. In questo modo risparmieremo 5 mesi di lavoro aggiuntivo”.

Qui sarebbe ovvio che ci vorrà molto più tempo per perforare un tunnel attraverso la collina e il cliente accetterebbe il “lavorare intorno”.

  • Passiamo ora allo sviluppo del software:

Lo sviluppatore afferma: “Sarebbe meglio avere solo una versione mobile con una dimensione dello schermo e una versione desktop con una dimensione dello schermo. Dovremmo evitare di avere un’app mobile ed evitare anche un design completamente responsive, perché non sembrerà buono”.

Qui il cliente molto probabilmente dirà: “Perché? Anche altri siti Web sono reattivi e possono cambiare in tutte le dimensioni dello schermo. È un compito facile».

Ma: potrebbero esserci diverse e buone ragioni per cui lo sviluppatore ha suggerito questo. Forse un design reattivo non avrà un bell’aspetto o non sarà professionale. Soprattutto alcuni pulsanti possono facilmente diffamare, ecc. ecc.
Quindi ora quello che accadrà è che lo sviluppatore lo farà 1) costruisci la pagina responsive e 2) aumenterà le ore.

  • Per l’aumento delle ore non ci sarà accettazione da parte del cliente: “Perché più ore? È facile vero?”
  • Al termine dell’attività, il cliente guarderà il sito Web con il suo cellulare e dirà: “Tutto è disallineato quando controllo il sito sul cellulare. Perché? Ho pagato molto di più e ora questo?”.

Se il cliente avesse accettato il modo precedente di farlo (non reattivo, con solo due versioni), il sito Web sarebbe stato più economico (meno ore) e sarebbe andato bene su quasi tutti gli schermi mobili e i browser desktop.

Il problema principale qui è anche: Non va bene litigare con nessuno. Soprattutto litigare con il cliente non è una buona idea. Quindi lo sviluppatore/il fornitore di servizi diranno sempre “Sì, hai ragione, facciamo così”.

E una volta che il cliente non è veramente soddisfatto, allora lo sviluppatore dovrebbe assumersi nuovamente la colpa (anche se sa che non è stata colpa sua, ma che il requisito era tale).

2) Non è possibile impiegare molto tempo per stimare esattamente

Nel mondo reale, un’azienda di software riceverà richieste di applicazioni software su base giornaliera o settimanale.

Se ogni richiesta fosse stimata esattamente, gli sviluppatori non avrebbero altro da fare se non creare stime esatte. Non sarebbero in grado di lavorare su progetti reali, perché la creazione di tali stime esatte richiede molto tempo.

Quindi ciò che effettivamente accade è: esamineranno il progetto e “stimeranno” il tempo necessario. Ecco perché si chiama “stima”, perché non è esatta.

Inoltre: il cliente stesso non è interessato ad aspettare una o più settimane per specificare il requisito. Verrà creato al massimo un documento di 5 pagine che sarà la base per lo sviluppo.

3) Ogni requisito cambia durante il progetto

mi piace citare Andrea Rosa dal thread/link di Quora dall’inizio di questo articolo:

“Non importa quanto grande o piccolo sia un progetto, ci sarà sempre qualcosa che verrà fuori dopo che inizi il progetto. Più probabilmente, verranno fuori molte cose. È solo la natura della bestia. In qualità di Product Manager, il tuo compito è lavorare con i tuoi clienti per trovare ciò di cui hanno bisogno e per cui sono disposti a pagare. Devi anche trovare ciò che puoi ragionevolmente fornire con l’assistenza dei tuoi sviluppatori. Mentre lavori per soddisfare quegli obiettivi, ti imbatti in cambiamenti nell’ambito, stime di tempo errate e, a volte, cambiamenti nelle persone che stanno lavorando per completare il progetto.

Molte cose cambiano durante il progetto. Come ha detto Andrew, non cambieranno solo i requisiti. Anche le persone potrebbero entrare in altri progetti prima del completamento del progetto in corso.

Qui un’analogia:

Un velocista di 100 metri si allena per 10 anni per correre i 100 metri in meno di 10 secondi.

Il giorno dello sprint, dice il cliente, servono anche 5 ostacoli lungo il percorso.

Quindi il velocista dirà: “ma allora non sarò in grado di correre sotto i 10 secondi” e il cliente dirà “per cosa ti sei allenato negli ultimi 10 anni, gentilmente fallo sotto i 10 secondi”.

Questa stessa cosa anche nei progetti software. Clienti e Project Manager porteranno nuovi requisiti perché “Oh, ho dimenticato questa funzionalità molto importante. Deve essere nel software, altrimenti non ci sarà utile”.

Queste modifiche ai requisiti verranno di solito durante il progetto completo. È come aggiungere un laghetto, un muro, una scala, ecc., sulla via del velocista, aspettandosi che lo faccia ancora in meno di 10 secondi.

4) Architettura non verificata correttamente

Soprattutto quando le cose non vengono fatte da zero e vengono utilizzati strumenti di terze parti (WordPress, TYPO3, Drupal, Magento, Shopware e molti altri) e questi dovrebbero essere personalizzati per fare qualcosa di particolare a cui può arrivare stime sbagliate .

In questi strumenti di terze parti non possiamo semplicemente cambiare tutto ciò che vogliamo. È necessario seguire cose semplici come la struttura dell’URL o altre cose.

Come al punto 1) in questo testo, non tutto è di facile attuazione. Una volta scoperto che l’attuale architettura del sistema di terze parti non supporta una funzionalità specifica, è sempre meglio evitare quella specifica funzionalità e utilizzare un’espediente che faccia lo stesso lavoro, ma utilizzando l’architettura esistente.

Nota: questo problema/problema sorgerà anche se il progetto viene eseguito da zero con strumenti come PHP, ASP.NET, Laravel, Zend, Symfony, Java, Ruby on Rails, Node.Js, ecc. e alcuni presupposti iniziali errati sono state fatte sull’architettura del sistema.

5) Il tappo dello spettacolo “una frase” o “una parola”

Avevo già citato l’esempio del documento di 5 pagine, che verrà fornito dal cliente. Una volta che lo sviluppo è quasi terminato o in corso, il cliente dirà: “Manca una funzionalità importante. A pagina 3 alla riga 22 si dice che abbiamo bisogno – di uno strumento di segnalazione -”.

Ma costruire questo strumento di reporting, di cui si parla solo brevemente nel documento, richiederà di per sé la stessa quantità dell’intero progetto. E poiché lo “strumento di segnalazione” è menzionato nel documento, il cliente ovviamente insisterà sulla sua implementazione.

6) Vincere il progetto

Supponiamo che tu abbia la sensazione che molte aziende stiano facendo un’offerta per lo stesso progetto. Ora sicuramente non vuoi essere la proposta che addebita il maggior numero di ore. Vuoi essere quello che mostra il minor numero di ore. Se un cliente può scegliere tra 100 ore e 500 ore, sicuramente tutti opteranno per le 100 ore.

In realtà, in un mondo ideale, tutti hanno bisogno dello stesso numero di ore. Quindi, anche se sono state quotate 100 ore, finirà per essere 500 ore.

7) Incognite/tempi di attesa

Ci sono diverse incognite nei progetti software:

  • a) Cambiamento tecnologico: Se uno degli strumenti di sviluppo (ad es. Android) riceve un aggiornamento importante, è necessario lavorare ancora per incorporare tali cambiamenti tecnologici.
  • b) Esperienza dei membri del team: Se uno sviluppatore senior lavora al progetto, ci vorrà meno tempo, se è uno sviluppatore junior, allora molto probabilmente ci vorrà più tempo.
  • c) Il feedback arriva in ritardo: I clienti di solito non sono molto interessati al progetto, vogliono grandi risultati. Quindi, quando il cliente viene avvicinato durante il progetto, potrebbe non essere disposto a dare una risposta entro un’ora. Potrebbero volerci diversi giorni. Durante quel periodo il progetto resterà inattivo e il fornitore di servizi potrebbe anche addebitare ore durante quel periodo, se gli sviluppatori sono inattivi a causa del ritardo nelle risposte.

8) Il progetto è troppo grande per essere stimato correttamente

Supponiamo che l’attività sia una, che richiede diversi sviluppatori in un periodo di diversi mesi.

È quasi impossibile suddividere i compiti in pezzi di lavoro così piccoli, in modo da ottenere la giusta stima.

Naturalmente anche le altre cose menzionate in questo articolo avranno un ruolo.

Conclusione

L’approccio migliore è:

  • Fai un preventivo approssimativo
  • Indicare che è meglio ridurre le funzionalità, se il progetto impiega troppo tempo e impiega molte ore (ad es. creare un elenco prioritario di funzionalità, eseguire solo quelle più importanti)
  • Utilizza la metodologia agile per lo sviluppo e la fatturazione

Nel caso in cui desideri un prezzo/ore esatti, di solito è possibile solo in progetti più piccoli, che dureranno alcune settimane.

Altri articoli interessanti sull’argomento:
Come stimare realisticamente il progetto di sviluppo software in ore-uomo Man
Perché la stima del tempo di sviluppo del software non funziona e approcci alternativi

Fonte immagine: Flickr.com/ Michael Kappel/ Judit Klein/ Markus Spiske


L’autore: Sascha Thattil lavora presso Software-Developer-India.com che fa parte del gruppo YUHIRO. YUHIRO è un’impresa tedesco-indiana che fornisce programmatori ad aziende IT, agenzie e dipartimenti IT.

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.