Come valutare una stima dei costi del software (per persone non tecniche)

Come valutare una stima dei costi del software (per persone non tecniche)

È piuttosto difficile valutare un progetto software e metterci un prezzo.

Nell’articolo alcune sfide e come fare per valutare le stime dei costi del software.

introduzione

Secondo il rapporto sul caos, spesso citato, circa il 30 percento di tutti i progetti software fallisce. Ciò significa che la durata del progetto sta diventando troppo lunga o il budget non viene mantenuto.

Ecco alcune sfide nei progetti software:

1) Difficile verificare i requisiti esatti

Se si desidera costruire una grande casa su misura, il prezzo può essere fissato solo se ogni parte del lavoro viene valutata correttamente. Fino all’ultima vite, che verrà utilizzata.

L’architetto creerà un piano con un piano esatto, in cui l’intera casa viene replicata su carta o spesso al giorno d’oggi come modello 3D. E in questi programmi si può calcolare quante viti, ecc. saranno necessarie per costruire la casa.

Con queste informazioni è possibile fornire una stima esatta per il progetto di costruzione della casa.

Ma sappiamo anche: nei progetti di costruzione molto grandi, le stime dei prezzi di solito non sono corrette. E quello che doveva costare 500 milioni di euro, finirà per costare 5 miliardi di euro o più. L’aeroporto di Berlino, l’Elbphilharmonie di Amburgo e la stazione ferroviaria principale di Stoccarda, in Germania, sono tre esempi, nella maggior parte dei casi il costo è stato ridotto di un miliardo di euro o più.

Nel caso della stazione ferroviaria principale di Stoccarda, il compenso per l’architetto è stato di circa 36 milioni di euro. Anche se l’architetto è stato pagato una cifra così alta. La stima dei costi del progetto è stata sfalsata di circa 1 miliardo di euro.

Sfide simili possono essere viste nei progetti software.

Soprattutto quando sono coinvolte persone non tecniche nella trasmissione dei requisiti per il software o il progetto web. Di solito le descrizioni del progetto saranno solo poche righe all’interno di un’e-mail. Oppure una telefonata in cui viene delineata la soluzione richiesta.

Alcuni siti web di esempio verranno forniti per riferimento. Non di rado questi siti web di esempio sono stati costruiti in molti anni costando centinaia di migliaia di euro, a volte milioni.

Ma il budget per l’applicazione web o la soluzione software sarà di circa 4’000-40’000 Euro e dovrebbe essere costruito entro 2 mesi, massimo 3 mesi. (Questo è il desiderio di solito della persona non IT che chiede il prezzo).

La realtà è questa: senza un documento di richiesta dettagliato da parte del cliente, che sarà di circa 10-50 pagine e una proposta dettagliata creata dalla società IT, basata su tale documento richiesto, non è possibile determinare un prezzo per il progetto.

E anche se c’è un documento di proposta esatto. Di solito i requisiti cambiano durante il progetto, il che rende questo esercizio di creazione di proposte, che può richiedere settimane, un compito non necessario.

2) Modifica dei requisiti durante il progetto

Non esiste quasi nessun progetto IT, in cui il progetto software inizialmente quotato rimane lo stesso durante il progetto.

Il motivo è che solo una volta che il software inizia a prendere forma, il cliente riconosce che mancano alcune cose importanti, senza le quali il progetto non può avere successo e il software non aiuterebbe i processi aziendali.

Ma cosa succede se è stato concordato un prezzo fisso? In che modo il fornitore di servizi IT può consentire modifiche durante il progetto. Questo è quasi impossibile, perché in tal caso il fornitore di servizi IT non trarrà alcun profitto.

Dall’altro lato, il cliente insisterà sul prezzo fisso, dicendo che “Per questo piccolo cambiamento non c’è bisogno di cambiare il budget. Questa piccola richiesta di modifica la puoi inserire nel preventivo iniziale”.

E qui di solito inizia il dilemma. Questa discussione sulle richieste di modifica andrà avanti all’infinito. E il progetto si bloccherà.

Quindi è sempre meglio mantenere fluido il budget del progetto. Dove il cliente paga tanto quanto lo sviluppo del software richiede. -> Naturalmente, questo può sembrare “un paradiso per l’azienda di software” per il cliente, perché penserà che farà più ore del necessario.

Ma confrontalo con un ristorante. Se ordini una coca cola extra o una bistecca extra, dovresti anche pagare per quella cosa extra. Perché dovrebbe essere diverso nello sviluppo del software? Soprattutto nell’IT, dove le tariffe orarie sono generalmente molto più elevate.

3) Difficoltà a comprendere le complessità dello sviluppo del software da parte della persona non IT

Di solito è molto difficile capire per una persona non IT comprendere le complessità dello sviluppo del software.

“Il mio amico ha creato questo sito Web in un giorno e ha molte funzionalità, perché hai bisogno, come esperto, di più di 6 mesi per sviluppare queste funzionalità?”

Molto probabilmente l’amico ha utilizzato un sistema di gestione dei contenuti come WordPress o Drupal e ha utilizzato alcuni plug-in standard, che di solito offrono molte funzionalità. Ma queste non sono soluzioni software personalizzate fatte per l’amico. Questi sono sistemi e plugin utilizzati di solito da migliaia e centinaia di migliaia di persone, con requisiti simili. Non sono soluzioni su misura.

Ma: la creazione di questi plugin molto probabilmente richiedeva da 2 a 5 o più sviluppatori a tempo pieno per diversi mesi o addirittura anni. Quindi, anche se l’amico sta usando soluzioni apparentemente semplici. Sono stati creati in uno sviluppo software molto complesso.

Quindi, nel caso in cui il cliente abbia qualche requisito che può essere soddisfatto da quei plugin e “soluzioni già pronte”. Allora è meglio usarli. Ma nella maggior parte dei casi, questi sistemi software “pronti all’uso” non sono ciò che il cliente richiede.

Il miglior esempio è il motore di ricerca Google. Sul front-end (ciò che vede l’utente) c’è solo una barra di ricerca e due pulsanti. Quindi una persona non IT direbbe “potrebbe volerci solo una settimana per svilupparlo. C’è solo una barra di ricerca e due pulsanti”. In realtà ci sono molte funzionalità di backend “nascoste”, che vengono sviluppate da migliaia e migliaia di sviluppatori e che per molti anni.

A seconda della complessità, delle esigenze di scalabilità, ecc. del progetto del cliente, lo sviluppo del software potrebbe richiedere più tempo del previsto.

Possibili soluzioni

Ci sono alcune soluzioni su come una persona non IT potrebbe affrontare la richiesta al fornitore di servizi IT.

1) Coinvolgere uno sviluppatore di software

Idealmente ci sarebbe uno sviluppatore di software interno o un esperto IT, che potrebbe verificare la stima da parte della società di servizi IT.

Di solito lo sviluppatore del software consiglia di mantenere flessibile l’ambito del progetto, in modo che le modifiche possano essere adattate.

Se la stima della società di software è plausibile, lo sviluppatore del software darà il via libera.

In questo modo, mentre un dipendente interno valuta il progetto, anche la persona non IT sarà convinta degli sforzi necessari per lo sviluppo.

2) Utilizzo di sviluppatori dedicati

Uno sviluppatore dedicato, è uno sviluppatore che viene fornito al cliente a tempo pieno.

Il vantaggio di questo è che lo sviluppatore lavora a stretto contatto con il cliente e anche con il team del cliente. Ciò aumenta la trasparenza. E il cliente o il team possono porre domande e ottenere risposte in tempo reale.

Questo modello funziona in diversi modi:

• Sul posto: La società di servizi IT chiede allo sviluppatore di recarsi presso la sede del cliente e di lavorare presso la sede del cliente.
• Esternalizzazione IT: Un team di sviluppatori lavora presso la sede della società di servizi IT.
• Outsourcing vicino alla costa: Lo sviluppatore dedicato lavora presso la sede di un fornitore di servizi IT in un paese vicino. Per la Svezia, sarebbe la Polonia o l’Ucraina. Per il Giappone sarebbe la Malesia o la Cina.
• Delocalizzazione oltre confine: Qui lo sviluppatore siede nei locali di un’azienda di software in un paese lontano. Esempi sono l’India, il Pakistan, ecc. Ma le parole Nearshore o Offshore possono essere usate in modo intercambiabile. Dipende da dove si trova il cliente. Se il cliente è in Giappone, l’India è una destinazione di Nearshore Outsourcing.

Il cliente può utilizzare lo sviluppatore dedicato per tutto il tempo che desidera. Fino alla fine del progetto. Nel caso in cui il progetto richieda troppo tempo. Il cliente e il team possono discutere con lo sviluppatore su quale strada seguire per raggiungere gli obiettivi più velocemente.

3) Evita progetti rigidi a prezzo fisso

Un prezzo fisso di solito non è una buona idea. Solo se il progetto è molto piccolo. Come un sito Web di una pagina o simile.

I prezzi fissi possono portare a una falsa speranza che tutto sarà fatto, all’interno di quel prezzo. (Anche All-You-Can-Eat non funziona in questo modo. Puoi mangiare quanto vuoi, ma solo per un pasto. Non per giorni interi. Ma questo è ciò che i clienti si aspettano, quando ottengono un prezzo fisso in sviluppo software)

Meglio optare per un prezzo agile, in cui il tempo e lo sforzo del fornitore di software sono remunerati, in base a quanto impegno va nello sviluppo.

Oppure usa uno sviluppatore dedicato o un team di professionisti del software dedicati, per lavorare al tuo progetto.

Conclusione

Molti progetti software falliscono semplicemente perché non si comprende cosa comporta lo sviluppo di software personalizzato. Progetti apparentemente facili, possono richiedere settimane e mesi.

Pertanto, è necessario che il cliente faccia una valutazione. Qual è la fascia di costo per lo sviluppo del software e qual è il valore aziendale creato da questo. Il valore di business creato è molto più alto del budget necessario per lo sviluppo del software? Bene, allora è bene andare. Avvia il progetto.

Se il valore aziendale creato e il costo non corrispondono. Allora forse è meglio continuare a utilizzare soluzioni manuali, file Excel o software standard o soluzioni web, che possono essere sottoscritte, pagando un basso canone mensile.

In attesa di una discussione interessante.

Link interessanti:
Perché le stime potrebbero non essere una buona idea
Spiegato il mito delle stime del software

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.