Come faccio a sapere quanto fatturare e quanto tempo impiegherà un progetto di sviluppo software, prima dell'analisi? [chiuso]

5

Nello sviluppo del software di solito facciamo una fase di analisi in cui i requisiti sono presi, le interfacce utente sono progettate (per software con ui), ecc. Dopo la fase di analisi sai cosa fare e puoi stimare (aprox) lo sforzo e il costo per le attività future. Ma di solito ho notato in alcune aziende, la fase di analisi è stata fatta dopo che il progetto era già stato venduto. Ma non so come posso negoziare un budget (più profitti) e tempo con solo una carta del progetto o una semplice analisi, almeno per un prodotto software complesso. Di solito è il modo in cui vengono fatte le offerte di sviluppo del software? O è solo una cattiva pratica? Se è possibile condividere, come si stima budget e tempo per la prima negoziazione con il cliente.

    
posta joel 27.01.2017 - 23:23
fonte

3 risposte

6

Una cosa che rende speciali i progetti software è che una volta che hai analizzato completamente tutto , hai praticamente finito con il lavoro. Ovviamente non puoi permetterti di farlo finché non è chiaro se otterrai il lavoro.

Pertanto è normalmente richiesto di assumersi il rischio e fare un preventivo con pochissima conoscenza. Spesso è possibile confrontare la complessità dei requisiti con un progetto che hai già fatto per ottenere una stima approssimativa.

Ci sono alcuni modi per ridurre il rischio:

  1. Convinci il cliente a considerare l'analisi e le specifiche come un progetto separato che produce una specifica dettagliata e magari un prototipo come output. Quindi ottenere un feedback dal cliente e stimare l'implementazione. Questo è ancora molto vicino alla cascata ma offre alcune opzioni aggiuntive se la stima supera il budget

    • Adatta l'ambito eliminando i requisiti meno importanti.

    • Se il cliente decide di abbandonare il progetto, verrai pagato per ciò che hai fatto finora.

    • Il cliente ha la possibilità di consentire a qualcun altro di eseguire l'implementazione.

  2. Utilizza un metodo di sviluppo agile e procedi in piccole iterazioni. Non pianificare e stimare un'iterazione prima che sia terminata la precedente e hai ricevuto un feedback dal cliente.

Sono d'accordo sul fatto che può essere difficile convincere i clienti con una mentalità a budget fisso / a cascata a procedere in uno di questi modi.

    
risposta data 27.01.2017 - 23:58
fonte
2

Come altri hanno già detto, è almeno in parte una congettura, anche se le tue ipotesi dovrebbero basarsi su (sperabilmente estese) esperienze precedenti. Se rimani totalmente all'oscuro, ma comunque interessato, offri di fare il lavoro a ore piuttosto che come un contratto a prezzo fisso. Ma se fai le cose per bene, il prezzo fisso può finire molto più redditizio (mi piacerebbe avere un punteggio di tre volte in media) rispetto a ogni ora. Inoltre, anche se finiscono per pagare di più, i clienti spesso finiscono per essere più felici - hanno avuto un costo up-front noto.

Ma una cosa in più che posso dirti per certo - non è richiesta alcuna congettura. Su qualsiasi progetto non banale, gli utenti / clienti / etc stanno per cambiare idea, avere nuove idee, ecc. Ecc. Prima di passare alla produzione.

Alcuni sviluppatori si arrabbiano molto per questo sviluppo assolutamente inevitabile. Ma è davvero una buona cosa. Solo un cliente che è un idiota completo non avrà idee nuove / modificate / ecc. Mentre legge le specifiche funzionali, gioca con i prototipi, parla agli utenti, si siede e pensa, ecc. Ecc. Tutto ciò aiuta solo a fornire un sistema migliore . Lo sviluppo è, per sua natura, un obiettivo in movimento. Non essere arrabbiato, sii preparato.

Ma i clienti devono essere preparati per il ritardo e il costo aggiuntivi delle loro idee nuove / modificate. Verifica che lo siano già, oppure spiega i fatti della vita il più delicatamente possibile. Ho un gentile detto di introdurre tali conversazioni, che condividerò con voi qui (ma non dirlo a nessun altro): è " TTT " che significa T h < strong> T ake T ime. Abbastanza carino quindi non è intimidatorio (dillo con un sorriso), ma aiuta a ottenere il punto generale all'inizio di una discussione.

E durante lo sviluppo, quando vengono richieste le inevitabili modifiche, la discussione più sensibile sta negoziando le modifiche del contratto corrispondenti (ovvero più denaro). I clienti inizieranno inevitabilmente a spiegarti come ciò che stanno chiedendo è in realtà già nel contratto originale. Circa il 20% delle volte avranno un punto discutibile. Assicurati di riconoscere quelle occasioni occasionali e di essere più che imminente quando si verificano. Ma circa l'80% delle volte soffia il fumo (sai dove :), e devi essere solido ma amichevole - le buone relazioni con i clienti sono tutto. Qualunque cosa. Qualunque cosa. Ecco perché ho iniziato questo paragrafo enfatizzando "la discussione più sensazionale". Devi essere pagato, ma non puoi rendere i clienti arrabbiati per questo.

A volte il tempo richiesto non è preventivato, o porta a scadenza, ecc. In questi casi, e in tutti i casi, le specifiche funzionali dovrebbero avere una sezione più o meno intitolata "Revisioni pianificate per la versione 2.0" . Infatti, a volte le cose che avevi programmato per la versione 1.0 finiscono in quella sezione.

    
risposta data 28.01.2017 - 09:36
fonte
1

Analizzare completamente qualcosa prima di iniziare a lavorare su di esso è molto difficile, se non impossibile. Provare sarà molto costoso e probabilmente porterà a paralisi dell'analisi . D'altra parte, impegnarsi in un progetto senza alcun piano è una ricetta per il disastro. Non so perché alcune aziende sembrano gravitare verso un estremo o l'altro. Certamente ci vuole tutta la gioia dello sviluppo del software.

Se non hai esperienza nel fare le stime di tempi e costi, puoi affidarti all'esperienza combinata del team di sviluppo. Ciò implica che non fornirai al cliente un preventivo alla tua prima riunione.

  1. Discutere i requisiti di base con il cliente. Confrontate due liste: requisiti per la versione 1.0 e simpatiche.
  2. Esegui entrambi gli elenchi dal team di sviluppo, o almeno dagli sviluppatori più esperti.
  3. Come gruppo, fai stime approssimative per ciascun articolo. Gli sviluppatori potrebbero dirti che alcuni requisiti saranno molto difficili o che alcuni degli elementi della lista dei desideri sono banali.
  4. Nota se è probabile che alcuni articoli dipenderanno da altri elementi.
  5. Presenta gli elenchi al cliente e permetti loro di decidere quali articoli sono disposti a pagare.
  6. Incorporare gli elementi dell'elenco nel contratto.
risposta data 28.01.2017 - 03:55
fonte