Che cosa dovrei tenere a mente quando scrivo preventivi personalizzati? [chiuso]

Non sono chiaro su cosa intendi con "il tipico approccio ingegneristico", ma proverò con cautela contro il procedere senza un accordo scritto su quale lavoro debba essere fatto e per quale compensazione. Consiglio vivamente di creare una specifica funzionale piuttosto che una specifica di "programmazione", come per la serie di articoli sulle specifiche funzionali di Joel Spolsky (http://www.joelonsoftware.com/articles/fog0000000036.html).

Fondamentalmente le specifiche aiuteranno te e il cliente a concordare su quale sarà il comportamento finale del programma. Le specifiche funzionali dovrebbero contenere abbastanza dettagli che è possibile verificare il programma finale contro di esso. In questo modo non ci sono dubbi che hai consegnato ciò che è stato concordato e il pagamento è ora dovuto.

Fai molta attenzione a "Puoi aggiungere solo una funzione in più / modifica questa caratteristica leggermente". Di solito iniziano con qualche piccola modifica qua e là e se li fai gratis, inizi a ricevere richieste più frequenti e meno ragionevoli fino a quando non stai facendo progetti interi senza costi aggiuntivi. La mia raccomandazione è di costruire poche ore di consulenza / tempo di programmazione extra nella citazione iniziale per le modifiche al prodotto finito, e una volta che questo tempo viene superato fare una nuova specifica e quotare per le modifiche. In questo modo, il cliente ottiene qualche ritocco ragionevole sul prodotto finale, ma non inizia a credere che tutte le modifiche future dovrebbero essere fatte per l'importo iniziale indicato.

Per un piccolo progetto la migliore quotazione è un prezzo fisso, tuttavia devi stare attento e assicurarti di avere una piena comprensione dell'ambito e del tempo che investirai nel progetto.

Identifica tutti gli ambiti in una struttura di analisi del lavoro e assicurati che sia stato firmato dalla società. Questo è un accordo che TU comprendi ciò che consegnerai e LORO comprenderanno ciò che riceveranno.

Determina le stime di tempo, il pad per lo sconosciuto e fattura una percentuale in più rispetto alla tariffa del contraente in corso per riflettere il tuo rischio.

Avendo realizzato uno sviluppo software su misura per circa 20 anni, ecco cosa dovrei fare nei tuoi panni:

1. Se non l'avessi fatto, stabilisci un elenco concordato delle modifiche del software consegnabile - caratteristiche individuali, correzioni di bug, ecc.
2. Stima per quanto tempo penso che ognuno di questi compiti prenderà, individualmente. Si ottiene una stima molto migliore in questo modo rispetto al guardare il progetto nel suo complesso. Infatti, più puoi abbatterlo, migliore sarà la tua stima. Ma non dare quelle stime di attività individuali al cliente.
3. Aggiungili e raddoppia per tenere conto delle incognite. Chiama quell'importo raddoppiato X.

Quindi invierei una semplice email o una lettera che dice:

• Ecco l'elenco delle modifiche concordate. Stimo che questo richiederà al massimo un totale di X ore.
• Lavoro su una base di tempo e materiali, con tempi fatturati a $ Y all'ora.
• Se - a causa di fattori imprevisti - il progetto raggiunge il 90% di X e non è completo, interromperò il lavoro e ti contatterò per discutere se procedere.

Ho trovato che questo approccio è una vittoria per entrambe le parti. Il cliente ottiene il vantaggio del prezzo fisso di un "cap" sulla sua esposizione finanziaria e non sei bloccato a fare una quantità infinita di lavoro a un prezzo fisso.

Questo è anche molto facile da incorporare in un contratto. Negli Stati Uniti, in genere è possibile utilizzare un contratto a due pagine molto semplice che fa riferimento a un addendum "ambito di lavoro". Quindi l'addendum è una semplice pagina singola che elenca le modifiche e una stima del massimo delle ore Y.

Oltre alla tua tariffa oraria, l'unica obiezione che le persone più ragionevoli possono sollevare sarebbe che X sia troppo lungo. Il contro è quello di spiegare che in realtà non ci si aspetta che il progetto duri così a lungo, ma si è voluto rendere conto delle incognite e dare loro comunque un cappuccio che sei a tuo agio e che non supererai. In nessuna circostanza dovresti dire loro la tua stima originale, non modificata; potrebbe diventare un punto di contrattazione (ad esempio qualcosa su cui il cliente può discutere) che non sarebbe a tuo vantaggio.

Come altre persone hanno menzionato, un problema comune con i progetti a prezzo fisso è che il cliente può "un'altra piccola cosa" nella casa dei poveri. Un aspetto positivo di questo approccio è che, per richieste semplici, è possibile ottenere un accordo verbale per fatturarle ancora per qualche ora e, per richieste più complesse, è possibile aggiungere ulteriori pagine sull'ambito di lavoro come ulteriori aggiunte al contratto.

Sei in una posizione molto fortunata: hanno bisogno di te più del necessario, quindi puoi dettare le condizioni del contratto. Se proponi qualcosa di ragionevole come questo, dovrebbero essere felici. Se non sono felici - e soprattutto se richiedono un contratto a prezzo fisso nonostante il cap che ho suggerito sopra - questo è un avvertimento precoce che saranno un problema al collo da affrontare, quindi direi , "Mi dispiace non possiamo arrivare ad un accordo", e andiamo via.

Se puoi stimare quanto denaro o valore potrebbero risparmiare se automatizzi la fase di pre-elaborazione, sapresti quanto addebitare.

Fornirai il lavoro come esclusivo o hai qualche potenziale per vendere lo stesso codice ad altri clienti? Questo può influenzare il prezzo che chiedi.

Il valore che puoi generare per loro vale almeno il doppio di quello che verrebbe pagato per la vendita del tempo (consulenza)? Rifiuta l'offerta se ci sei sotto, sarebbe troppo rischioso. A meno che non siano disposti a pagare più soldi del valore che ottengono dall'output.