Stima del costo di modifica del codice di un altro utente [chiuso]

Penso che non dovresti nominare un prezzo dall'inizio. Se qualcuno ti parla di un progetto, dovresti fare abbastanza lavoro gratuitamente per capire cosa vuole il cliente e quanto potrebbe costare. Non più o meno di così.

Offri loro una proposta, che può essere estremamente breve, ma dai loro qualcosa che descriva ciò che vogliono e ciò che consegnerai. Puoi mettere un intervallo se lo desideri e potresti anche dire che si tratta di una "stima in buona fede", ma che l'importo finale si baserà sul tempo trascorso.

Dalla mia esperienza come libero professionista, ci sono 3 passaggi principali in questo:

1. chiedi il 50% di acconto per iniziare a lavorare

2. chiedi il pagamento finale prima di consegnare i file

3. chiedi un blocco di ore per lavori in corso o lavori che probabilmente compariranno nel tempo

Buona fortuna!

Chiedi una tariffa oraria. Non lasciare accumulare molte ore prima della fatturazione.

Diventa Agile! Non stimare un intero gruppo, specialmente se non hai molta esperienza sotto la cintura.

• Parla con il tuo cliente e vedi cosa deve essere implementato / consegnato.
• Per ogni funzionalità / unità di lavoro creare una storia utente (parte non tecnica, scrivere una descrizione appropriata) e suddividerla in una o più attività secondarie (parte tecnica)
• Stima ogni storia utente

Ricorda, stimare con la sua definizione è sempre sbagliato, altrimenti verrebbe chiamato un numero! È molto importante che anche il tuo cliente lo capisca!

Dovresti eseguire una consegna incrementale. Spiega al cliente di dare priorità alle storie degli utenti e seleziona quelli da consegnare nella prima iterazione. Ogni iterazione dovrebbe durare 2 settimane o meno, ma non più di 3 settimane! Quando finisci una storia di un utente (tutte le sue attività secondarie sono chiuse), avvisa il cliente e chiedigli di verificarlo mentre lavori alla prossima user story.

Non devi addebitare in anticipo, puoi farlo dopo ogni iterazione.

Buon codice!

Dato che sei nuovo nella tecnologia pertinente e non hai familiarità con la base di codice di scarsa qualità esistente su cui dovrai lavorare, è probabile che la stima possa variare in una certa misura in entrambe le direzioni. Ma fai sapere al cliente la seconda ragione :-P

In primo luogo, elencare la miriade di modifiche / caratteristiche richieste dal cliente. Per ogni esigenza, fare una piccola revisione del codice e una ricerca su come implementarla e testarla. Dovresti investire questa volta senza ritorno prima di dare un preventivo.

In secondo luogo, creare 3 colonne per la stima: caso migliore (probabilità del 25%), caso medio (50%), caso peggiore (75%). Per i 2 motivi menzionati nel primo paragrafo, puoi scegliere la stima del caso peggiore. È quindi possibile aggiungere un tempo di buffer pari al 20%. Ad esempio, per un requisito particolare, la stima del caso migliore è di 2 giorni, il caso medio è di 4 giorni e il caso peggiore è di 5 giorni. Aggiungendo un tempo di buffer del 20%, la stima è di 6 giorni.

Terzo, non dare un punto fisso di stima, piuttosto un intervallo. Per l'esempio sopra, puoi dire al cliente che la stima è da 4 a 6 giorni. Il tuo cliente può insistere sulla stima per l'intero elenco di modifiche. In tal caso, è possibile sommare i minimi e i massimi degli intervalli per tutti i requisiti. Quindi fornire una stima finale nel range, ad esempio da 5 a 6,5 mesi. Questo ha il seguente vantaggio: è possibile superare la stima per un requisito, ma potrebbe finire prima un altro requisito. In totale, si annullano a vicenda e la stima finale regge.

In quarto luogo, quando si completano i requisiti di ciascun utente e si consegna in modo incrementale, rivedere le stime precedenti per ciascun requisito. Questo è un processo continuo e dovresti adattare / perfezionare la stima man mano che procedi con il progetto e la tua esperienza cresce. Se vedi che la differenza tra la stima raffinata e la stima iniziale è fuori controllo, siediti immediatamente con il cliente e discuti la questione.

Ho appreso queste cose dal libro "Software Estimation: Demystifying the Black Art" di Steve McConnell. Sono grato a lui.

Potresti citare un totale in base alle ore di lavoro previste, chiarendo le tue ipotesi e il fatto che sarà aggiunto ogni ulteriore tempo richiesto. In questo modo se vai sotto (improbabile) esci davanti.

Assicurati che la qualità del codice esistente sia chiara per il cliente. Se sono ragionevoli dovrebbero essere accomodanti alla flessibilità, altrimenti sii pronto a camminare via.

Ero in questa situazione quando ho iniziato e sfortunatamente lo Stack Exchange non esisteva in quel momento. Ho quotato un prezzo fisso e sono dovuto cauzione per l'affare due mesi dopo. Ho perso i soldi e ho bruciato un ponte perché non potevo consegnare.

Guarda come le industrie simili lo fanno. Un architetto non darebbe una stima accurata su un'estensione del garage senza aver prima visto la proprietà.

Ricarica loro un costo di ricerca per la tua ora iniziale. Spiega che il codice si trova in uno stato in cui non è possibile fornire loro una stima accurata senza approfondire la situazione attuale. Assicurati che ottengano qualcosa alla fine, come segno di fede, documentazione che potrebbero dare a un altro sviluppatore, se lo desiderano, per salvarli e dover fare lo stesso lavoro.

E poi, se è importante per te che tu abbia il vero lavoro di sviluppo, digli che se vengono da te per il lavoro di sviluppo vero e proprio, scaricherai il 50% o addirittura il 100% di tale addebito sul conto finale . Non puoi perdere e alle persone piace ricevere qualcosa gratuitamente.