Non puoi mai conoscere un prezzo esatto o quasi esatto, poiché dipende da molti fattori. Esempio:
Argomento di studio
Hai una richiesta per un piccolo sito Web basato su WordPress. L'unica cosa che devi fare: lavorare con il tuo designer per creare una grafica accattivante, quindi creare il sito Web stesso (niente di altamente tecnico, solo un set di plugin da aggiungere a WordPress), e quindi distribuirlo. Essendo il lavoro davvero semplice, lo hai citato $ 600.
Il tuo designer ha creato la prima bozza. Il cliente ha spiegato che non lo trova affatto attraente. Lo stesso dicasi per la seconda, la terza e la quarta bozza. Alla fine, dopo due settimane di duro lavoro, il designer ha finalmente ottenuto la bozza che è stata accettata dal cliente.
Ma purtroppo il designer è stato investito da un autobus e l'unica cosa che hai avuto è stato il JPEG che ti ha inviato, ma non i PSD originali, quindi hai dovuto ricominciare da capo con un nuovo designer. Finalmente hai ottenuto la grafica e iniziato il tuo lavoro.
Sorpresa: hai scoperto che il plug-in A è incompatibile con il plug-in B, che il plug-in C non funziona come previsto e che il plug-in D non può essere installato sulla versione più recente di WordPress, mentre il plug-in A può essere installato solo su questa versione più recente. Ora devi fare molto codice PHP a mano, e dato che sei uno sviluppatore Python e non hai mai scritto una singola riga di codice in PHP, non è il compito più semplice.
Nel frattempo, il cliente inizia a inviarti e-mail spaventose, chiedendo perché il lavoro non è già stato fatto, mentre la scadenza era una settimana fa. Finisci finalmente la codifica PHP e tutto funziona perfettamente sulla tua macchina. Il cliente è contento.
Quindi inizi a distribuire il sito Web sul server di hosting per scoprire che non solo il sito Web non riesce con qualche errore criptico, ma anche la società di hosting non supporta una funzionalità di PHP che hai usato molto nel tuo codice.
Alla fine, dopo aver speso più di $ 3.000 per questo progetto, hai il sito Web attivo e funzionante. Il cliente è arrabbiato per le scadenze e perché "nulla funziona come previsto con te". Chiederesti $ 600? $ 3.000?
Perché succede?
Ciò che ho illustrato in questo esempio accade molto più spesso di quanto tu possa credere. Perché? Perché ci sono troppe variabili che non puoi prevedere e che aumentano il rischio. Qui, il rischio è stato aumentato di:
- Le specifiche poco chiare relative al design visivo,
- La morte del designer,
- L'incompatibilità dei plugin che hai selezionato,
- Il cattivo supporto dei plugin che hai selezionato,
- Il fatto che non hai mai usato PHP prima,
- La differenza tra l'ambiente di sviluppo e l'ambiente di produzione e l'assenza di messa in scena.
Si potrebbero risolvere quei problemi con approcci specifici:
- Requisiti funzionali e non funzionali chiari e precisi,
- Gestione degli scenari hit-by-a-bus (ovvero il progettista ha dovuto condividere tutti i documenti con te in modo che potesse essere morto in qualsiasi momento senza compromettere il progetto),
- Conoscenza preliminare di strumenti e lingue da utilizzare (che richiede molto lavoro),
- Messa in scena, test intensivi, ecc.
L'unico problema è che con questo approccio, devi dire al tuo cliente che pagherebbe almeno $ 5.000 in primo luogo, dal momento che in realtà è il prezzo di requisiti, specifiche, design, test, ecc. Possibilità per questo cliente di accettare le tue quotazioni sono estremamente basse.
Quindi non c'è niente da fare?
Se non riesci a fornire un prezzo molto preciso, puoi comunque fornire un'approssimazione, che tiene conto di ogni parte del lavoro da svolgere separatamente, con un indice di rischio influenzato da ogni parte. Maggiore è il rischio prevedibile, maggiore è il prezzo.
Hai due modi per farlo:
1. Modo Watefally
Se lavori su progetti adatti a Waterfall / V-Model, questo potrebbe funzionare:
Elencare i requisiti funzionali e non funzionali di un progetto. Ottieni il documento firmato dal cliente, allo stesso modo in cui firma il contratto.
Una volta ottenuto questo documento, hai già:
Il prezzo che hai già speso per raccogliere i requisiti e creare questo documento. Ciò può rappresentare un'importante quantità di denaro, dal momento che tali documenti possono variare da venti a cento pagine per un normale progetto ed essere centinaia o migliaia di pagine per grandi progetti.
La comprensione chiara, precisa e completa del prodotto che ti viene richiesto di fare.
Segui il tuo team passo dopo passo, analizzando ogni requisito e valutando:
Un prezzo medio di questa parte del progetto,
Un prezzo massimo senza tener conto del rischio,
Un indice di rischio.
Tutti e tre saranno presi in considerazione per determinare il prezzo che darai al cliente.
Assegnare il rischio che non dipende da un requisito specifico, ma piuttosto dalla compatibilità tra i requisiti o il sistema in generale.
Pro di approccio waterfally: il cliente ottiene un prezzo abbastanza preciso, considerando che hai una visione molto chiara del lavoro da svolgere e dei rischi che possono sorgere.
Contro di approccio waterfally: devi scrivere un documento di 200 pagine prima di dare il prezzo. Che cosa succede se il cliente annulla il progetto nel frattempo o si rivolge al tuo concorrente? L'intero processo è anche estremamente pesante e i requisiti non possono cambiare in seguito.
2. Modo agile
Se lavori su progetti adatti a Scrum o ad altri modelli agili:
- o non danno il prezzo complessivo del progetto, ma piuttosto i prezzi di ogni componente,
- oppure puoi indicare un prezzo complessivo molto approssimativo all'inizio, quindi dare quello sempre più preciso.
In entrambi i casi, dovresti avere una forte fiducia tra te e il cliente o avere persone eccellenti nel reparto vendite. Altrimenti,
nel primo caso, la persona crederebbe che stai solo rubando i suoi soldi chiedendo piccoli importi ancora e ancora, e questo non finirà mai,
nel secondo caso, la persona non capirebbe perché stai cambiando il tuo prezzo in ogni momento, specialmente se il prezzo sta aumentando per la maggior parte del tempo.
Pro dell'approccio Agile: il cliente può annullare in qualsiasi momento. Inoltre, se annulla nelle prime fasi, ha ancora del codice sorgente che funziona.
Contro di approccio Agile: il prezzo è troppo impreciso o nemmeno dato. La maggior parte dei clienti non è disposta a fare affari con te se non dici loro quanto dovranno pagare.