Progetti di sviluppo software a prezzo fisso: 3 punti importanti da ricordare

Esistono diversi modi per eseguire un progetto di sviluppo software. Questi sono principalmente:

  1. Sviluppatore dedicato: Avrai uno sviluppatore che lavora solo per te e la tua organizzazione. Solitamente viene concordato un prezzo mensile tra il fornitore del servizio e il cliente. Lo sviluppatore lavorerà a tempo pieno (circa 160 ore al mese) per il cliente.
  2. Team Man-and-Material/ Time-and-Material/ Agile/ Development: Qui viene concordato un progetto, ma l’esecuzione sarà eseguita da un team multidisciplinare di project manager, scrum master, analisti aziendali, sviluppatori aziendali, sviluppatori software/web, tester software, ecc. Qui spesso si usa una metodologia Agile e dopo ogni Primavera (un ciclo di sviluppo che dura circa un mese) si adeguano i tempi di sviluppo. Non è un prezzo fisso, ma un budget approssimativo in base al quale verrà sviluppato. Potrebbe essere una cifra approssimativa, ma potrebbe anche essere un multiplo di quella cifra di budget. Nelle grandi organizzazioni, questo approccio è generalmente preferito.
  3. Prezzo fisso: Questo viene solitamente utilizzato in progetti più piccoli, in cui il prezzo E i requisiti sono fissi. Questo articolo riguarda questo tipo di progetto e cosa deve essere considerato quando si esegue un progetto a prezzo fisso.

introduzione

Molte aziende di piccole e medie dimensioni dispongono di un budget per la realizzazione di progetti software. Soprattutto nelle aziende non IT, la conoscenza dei progetti software è limitata. Preferiscono avere un prezzo fisso, in cui il project manager all’interno di quelle aziende può essere facilmente comunicato all’amministratore delegato o al management dell’azienda.

Sarebbe piuttosto difficile dire: “Ci vorranno dai 2 agli 8 mesi per svilupparlo e ogni ora costa 100 dollari USA. Potrebbero essere anche 14 mesi”.

Se la società di servizi IT dice al cliente, “ Ci vogliono 4 mesi e un budget di 30’000 US Dollar ”, il team del cliente può prendere una decisione in merito.

Il grosso problema è -> Questo non è il modo in cui funziona un progetto software. I seguenti sono i motivi:

  1. I requisiti cambiano durante il progetto: Nessuno sa, nemmeno il cliente, cosa deve essere tutto nella soluzione software/web, affinché abbia successo. Solitamente, solo dopo poche settimane, diventeranno visibili la prima versione o le prime interfacce utente web. Questo di solito è quando il cliente scopre “Oops, c’è questa funzionalità, che è della massima importanza. Senza questa funzionalità, il progetto non sarà un successo”. Ma il costo del progetto e l’esecuzione del progetto sono già stati “fissati” da entrambe le parti, il cliente e la società di servizi IT. Questo può essere uno spettacolo.
  2. Nessuno sa esattamente quanto tempo ci vuole per sviluppare una funzionalità: Anche se uno sviluppatore di software può fornire una cifra approssimativa del tempo necessario per sviluppare una funzionalità. Lui o lei non lo sa esattamente. Questo vale anche per lo sviluppatore più esperto. Pertanto: più grande è il progetto, maggiore è il rischio che la stima sia sbagliata. Tuttavia, con un buffer più grande nella stima del progetto, la società di sviluppo software cerca in qualche modo di mitigare questo rischio.

Ciò significa che il fornitore di servizi IT ha già il rischio di non sapere se la stima dello sviluppatore fosse corretta e, inoltre, il cliente potrebbe richiedere modifiche all’interno del progetto.

Questo è anche il motivo per cui, secondo il tanto citato Chaos Report, una grande percentuale (circa il 40-60%) di tutti i progetti IT fallisce.

Perché in un progetto a prezzo fisso, nessuno vuole cedere. Il cliente non vuole pagare un dollaro USA in più “Perché è stato concordato un prezzo fisso” e il fornitore di servizi IT insisterà per costruire solo ciò che è stato concordato “Perché i requisiti sono stati fissati all’inizio del progetto”.

Ecco alcuni punti da ricordare per far funzionare i progetti a prezzo fisso

1) I requisiti sono fissati (e solo dopo aver terminato questi requisiti, vengono aggiunte nuove funzionalità)

Lo sviluppo del software non ha bisogno di fermarsi, una volta sviluppate le funzionalità inizialmente concordate. Una volta terminato il progetto iniziale, il passaggio successivo può essere discusso ed eseguito.

Suggerimento 1: il cliente deve eseguire le seguenti operazioni: Resisti alla tentazione di inserire nuovi requisiti nel progetto in corso. Anche se hai la forte sensazione che il progetto non varrà la pena per i tuoi clienti.

Sarà abbastanza difficile far funzionare i requisiti iniziali. Non aggiungere a questo.

2) Disponibilità del cliente durante il periodo di sviluppo

In un progetto a prezzo fisso, la società di servizi IT allocherà (in progetti più piccoli) da uno a tre sviluppatori, un team leader, un project manager e un designer.

Una volta avviato il progetto, le cose andranno veloci e il tempo non dovrebbe essere sprecato.

Particolarmente importante: se il team IT ha domande su un’attività o necessita di feedback, dovrebbe essere reso disponibile dal cliente il prima possibile. La cosa peggiore che potrebbe accadere è se il team di sviluppo deve attendere 2 giorni per il feedback del cliente e rimane inattivo per quel tempo.

Se il team di sviluppo rimane inattivo, quel tempo di solito viene detratto dal Budget del tempo fisso e il team cerca di completare le attività nel tempo rimanente. Che di solito non è una buona idea, ma forse l’unico modo per andare avanti.

Pertanto, per beneficiare del team di sviluppo e del loro tempo, il cliente deve essere prontamente disponibile per le domande del fornitore di servizi IT.

Suggerimento 2: la soluzione migliore per questo sarebbe: Il cliente fornisce un punto di contatto dedicato, disponibile durante le ore di sviluppo, durante l’intero periodo di sviluppo. Ad esempio, John Smith dal client sarà disponibile dal 01. luglio al 30. Agosto. In questo periodo John Smith sarà disponibile tramite Skype o Slack Chat e potrà rispondere alle domande del team di sviluppo.

3) Fornire contenuti in tempo

In alcuni casi, il cliente è tenuto a fornire testi, video, immagini e altri tipi di contenuti o materiali.

Questo contenuto pre-concordato dovrebbe essere fornito in tempo.

In alcuni casi, la società di sviluppo ha la possibilità di utilizzare testi o contenuti fittizi per il momento.

Ma per un output corretto, in alcuni casi è necessario il contenuto.

Suggerimento 3: assicurati di avere il contenuto (come testi o immagini) pronto, quando il team di sviluppo lo richiede.

Nota: potrebbe anche essere correlato all’approvazione, all’esecuzione di un compito o a un documento di progetto che deve essere firmato.

4) Evita: “Ma questo faceva parte del requisito” Argomenti (Suggerimento importante aggiuntivo)

In realtà, i requisiti non possono mai essere pienamente compresi o annotati all’inizio del progetto.

Il team di sviluppo del software di solito lavora con alcuni URL di esempio inviati dai clienti, uno o due incontri online e del materiale scritto come e-mail o PDF.

Di solito c’è una comprensione generale delle funzionalità principali, ma non un’immagine chiara al 100%.

Questo può essere usato da entrambi, la società di sviluppo per dire “ Ma questo non faceva parte del requisito, questo ha un costo aggiuntivo ” o il cliente per dire “ Ma questo faceva parte del requisito iniziale, lo vogliamo sicuramente senza costi aggiuntivi ”.

Suggerimento 4: ci deve essere equità generale da entrambe le parti. Il rapporto qualità prezzo dovrebbe esserci. Ma d’altra parte, non dovrebbe essere un compito così irraggiungibile, in modo che la società di sviluppo non tragga alcun profitto dai progetti.

Nota: In generale il cliente (nel caso non sia un esperto IT) dovrebbe fare affidamento sulla procedura di sviluppo suggerita dall’azienda IT.

Conclusione

Il modo migliore per affrontare i progetti software è con lo sviluppatore dedicato o sviluppatore dedicato/approccio Agile. Ma questo non è fattibile per alcune aziende a causa di vincoli di budget.

Pertanto, molte società di servizi IT offrono l’opzione per progetti a prezzo fisso.

Per il cliente è importante notare che quando viene fissato il prezzo, vengono fissati anche i requisiti. Spesso il prezzo fisso viene scambiato con un “All-You-Can-Eat-Buffet”, in cui paghi una volta e puoi mangiare (sviluppare) quanto vuoi. Al contrario, è più simile a un’opzione di menu “A-La-Carte”, dove ordini la bistecca per 5 dollari USA, se vuoi patatine fritte con quella, devi pagare 2 dollari USA in più.

Ma anche: lo sviluppo del software e la preparazione dei pasti sono diversi. Perché quando si crea una bistecca, l’input è abbastanza chiaro. Nello sviluppo del software, questo non è sempre il caso.

I suggerimenti in questo articolo aiuteranno a rendere i progetti a prezzo fisso un successo.

Articoli interessanti:

Come far funzionare i progetti a prezzo fisso per te

Sfide nello sviluppo di software a prezzo fisso

Immagini: Canvas


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.