{"id":10625,"date":"2021-06-30T14:49:49","date_gmt":"2021-06-30T12:49:49","guid":{"rendered":"https:\/\/www.software-developer-india.com\/progetti-di-sviluppo-software-a-prezzo-fisso-3-punti-importanti-da-ricordare\/"},"modified":"2025-01-02T07:05:16","modified_gmt":"2025-01-02T05:05:16","slug":"progetti-di-sviluppo-software-a-prezzo-fisso-3-punti-importanti-da-ricordare","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/it\/progetti-di-sviluppo-software-a-prezzo-fisso-3-punti-importanti-da-ricordare\/","title":{"rendered":"Progetti di sviluppo software a prezzo fisso: 3 punti importanti da ricordare"},"content":{"rendered":"\n

Progetti di sviluppo software a prezzo fisso: 3 punti importanti da ricordare<\/h2>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n

Esistono diversi modi per eseguire un progetto di sviluppo software. Questi sono principalmente:<\/p>\n\n

    \n
  1. Sviluppatore dedicato:<\/strong> 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\u00e0 a tempo pieno (circa 160 ore al mese) per il cliente.<\/li>\n\n\n\n
  2. Team Man-and-Material\/ Time-and-Material\/ Agile\/ Development:<\/strong> Qui viene concordato un progetto, ma l’esecuzione sar\u00e0 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 \u00e8 un prezzo fisso, ma un budget approssimativo in base al quale verr\u00e0 sviluppato. Potrebbe essere una cifra approssimativa, ma potrebbe anche essere un multiplo di quella cifra di budget. Nelle grandi organizzazioni, questo approccio \u00e8 generalmente preferito.<\/li>\n\n\n\n
  3. Prezzo fisso:<\/strong> Questo viene solitamente utilizzato in progetti pi\u00f9 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.<\/li>\n<\/ol>\n\n

    introduzione<\/strong><\/h3>\n\n

    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 \u00e8 limitata. Preferiscono avere un prezzo fisso, in cui il project manager all’interno di quelle aziende pu\u00f2 essere facilmente comunicato all’amministratore delegato o al management dell’azienda.<\/p>\n\n

    Sarebbe piuttosto difficile dire: \u201cCi vorranno dai 2 agli 8 mesi per svilupparlo e ogni ora costa 100 dollari USA. Potrebbero essere anche 14 mesi<\/i>\u201d.<\/p>\n\n

    Se la societ\u00e0 di servizi IT dice al cliente, “ Ci vogliono 4 mesi e un budget di 30’000 US Dollar<\/i> \u201d, il team del cliente pu\u00f2 prendere una decisione in merito.<\/p>\n\n

    Il grosso problema \u00e8 -> Questo non \u00e8 il modo in cui funziona un progetto software. I seguenti sono i motivi:<\/p>\n\n

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

      Ci\u00f2 significa che il fornitore di servizi IT ha gi\u00e0 il rischio di non sapere se la stima dello sviluppatore fosse corretta e, inoltre, il cliente potrebbe richiedere modifiche all’interno del progetto.<\/p>\n\n

      Questo \u00e8 anche il motivo per cui, secondo il tanto citato Chaos Report, una grande percentuale (circa il 40-60%) di tutti i progetti IT fallisce.<\/p>\n\n

      Perch\u00e9 in un progetto a prezzo fisso, nessuno vuole cedere. Il cliente non vuole pagare un dollaro USA in pi\u00f9 “Perch\u00e9 \u00e8 stato concordato un prezzo fisso” e il fornitore di servizi IT insister\u00e0 per costruire solo ci\u00f2 che \u00e8 stato concordato “Perch\u00e9 i requisiti sono stati fissati all’inizio del progetto”.<\/p>\n\n

      Ecco alcuni punti da ricordare per far funzionare i progetti a prezzo fisso<\/h3>\n\n

      1) I requisiti sono fissati (e solo dopo aver terminato questi requisiti, vengono aggiunte nuove funzionalit\u00e0)<\/strong><\/h3>\n\n

      Lo sviluppo del software non ha bisogno di fermarsi, una volta sviluppate le funzionalit\u00e0 inizialmente concordate. Una volta terminato il progetto iniziale, il passaggio successivo pu\u00f2 essere discusso ed eseguito.<\/p>\n\n

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

      Sar\u00e0 abbastanza difficile far funzionare i requisiti iniziali. Non aggiungere a questo.<\/p>\n\n

      2) Disponibilit\u00e0 del cliente durante il periodo di sviluppo<\/strong><\/h3>\n\n

      In un progetto a prezzo fisso, la societ\u00e0 di servizi IT allocher\u00e0 (in progetti pi\u00f9 piccoli) da uno a tre sviluppatori, un team leader, un project manager e un designer.<\/p>\n\n

      Una volta avviato il progetto, le cose andranno veloci e il tempo non dovrebbe essere sprecato.<\/p>\n\n

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

      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\u00e0 nel tempo rimanente. Che di solito non \u00e8 una buona idea, ma forse l’unico modo per andare avanti.<\/p>\n\n

      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.<\/p>\n\n

      Suggerimento 2: la soluzione migliore per questo sarebbe:<\/strong> 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\u00e0 disponibile dal 01. luglio al 30. Agosto. In questo periodo John Smith sar\u00e0 disponibile tramite Skype o Slack Chat e potr\u00e0 rispondere alle domande del team di sviluppo.<\/p>\n

      \n
      \"\"<\/a><\/figure>\n<\/div>\n

      3) Fornire contenuti in tempo<\/strong><\/h3>\n\n

      In alcuni casi, il cliente \u00e8 tenuto a fornire testi, video, immagini e altri tipi di contenuti o materiali.<\/p>\n\n

      Questo contenuto pre-concordato dovrebbe essere fornito in tempo.<\/p>\n\n

      In alcuni casi, la societ\u00e0 di sviluppo ha la possibilit\u00e0 di utilizzare testi o contenuti fittizi per il momento.<\/p>\n\n

      Ma per un output corretto, in alcuni casi \u00e8 necessario il contenuto.<\/p>\n\n

      Suggerimento 3: assicurati di avere il contenuto (come testi o immagini) pronto, quando il team di sviluppo lo richiede.<\/strong><\/p>\n\n

      Nota: potrebbe anche essere correlato all’approvazione, all’esecuzione di un compito o a un documento di progetto che deve essere firmato.<\/p>\n\n

      4) Evita: “Ma questo faceva parte del requisito” Argomenti (Suggerimento importante aggiuntivo)<\/strong><\/h3>\n\n

      In realt\u00e0, i requisiti non possono mai essere pienamente compresi o annotati all’inizio del progetto.<\/p>\n\n

      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.<\/p>\n\n

      Di solito c’\u00e8 una comprensione generale delle funzionalit\u00e0 principali, ma non un’immagine chiara al 100%.<\/p>\n\n

      Questo pu\u00f2 essere usato da entrambi, la societ\u00e0 di sviluppo per dire “ Ma questo non faceva parte del requisito, questo ha un costo aggiuntivo<\/i> \u201d o il cliente per dire \u201c Ma questo faceva parte del requisito iniziale, lo vogliamo sicuramente senza costi aggiuntivi<\/i> \u201d.<\/p>\n\n

      Suggerimento 4: ci deve essere equit\u00e0 generale da entrambe le parti.<\/strong> Il rapporto qualit\u00e0 prezzo dovrebbe esserci. Ma d’altra parte, non dovrebbe essere un compito cos\u00ec irraggiungibile, in modo che la societ\u00e0 di sviluppo non tragga alcun profitto dai progetti.<\/p>\n\n

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

      Conclusione<\/strong><\/h3>\n\n

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

      Pertanto, molte societ\u00e0 di servizi IT offrono l’opzione per progetti a prezzo fisso.<\/p>\n\n

      Per il cliente \u00e8 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, \u00e8 pi\u00f9 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\u00f9.<\/p>\n\n

      Ma anche: lo sviluppo del software e la preparazione dei pasti sono diversi. Perch\u00e9 quando si crea una bistecca, l’input \u00e8 abbastanza chiaro. Nello sviluppo del software, questo non \u00e8 sempre il caso.<\/p>\n\n

      I suggerimenti in questo articolo aiuteranno a rendere i progetti a prezzo fisso un successo.<\/p>\n\n

      Articoli interessanti:<\/p>\n\n

      Come far funzionare i progetti a prezzo fisso per te<\/a><\/p>\n\n

      Come si svolge un progetto a prezzo fisso?<\/a><\/p>\n\n

      Immagini: Canvas<\/p>\n\n

      \n
      \n
      \"\"<\/figure>\n<\/div>\n

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