Ricarica per ora / progetto [chiuso]

If you agree to take on a project... work on and charge £X per hour - are you obligated to work for free after those 10 days are up and you have still not managed to complete your project due to unanticipated issues?

No. £ X all'ora è £ X all'ora. Chiaramente, non hai mai fatto lavori complessi a casa tua o in barca.

L'incapacità di stimare non significa nulla. Niente.

£ X all'ora è £ X all'ora. Fino a quando il lavoro è finito o il cliente dice "sei licenziato". (o "sei licenziato" .Sono uno Yank, quindi non so cosa dicono nel Regno Unito.)

What if you have delivered the project but bugs are found - should you fix these bugs for free if the 10 days are up or should you charge your client?

Dipende dal bug. devi eseguire l'analisi delle cause principali. Le specifiche errate (o incomplete) sono principalmente il loro problema. Le rughe tecniche inattese sono la norma per il corso: pagano. Errori di codifica stupidi sono il tuo problema.

you have to give up and tell your client that you cannot do it anymore?

Ops. È poco professionale. Se devi arrenderti, hai commesso un terribile, terribile errore.

I realise that this does nothing to build your reputation and relationship with the client but are you obligated to pay back the money paid to you or do you just deliver the half/nearly completed source code and help them find someone else to complete it?

Sigh. A questo punto, ti sei comportato così male che non importa niente. Dovresti davvero trovare un'altra carriera se non riesci a seguire i tuoi contratti. Sul serio. Ripensa la tua vita.

Il software parzialmente completato non ha valore. Nessuno lo "completerà". Ti spiegheranno che sei un idiota (perché lo sei) getta via il tuo codice e ricomincia da capo.

Devi fare quanto segue.

1. Riduci i requisiti a qualcosa di finale, disponibile e utilizzabile.

2. Crea quella cosa finale, disponibile e utilizzabile. Anche se non è il grande schema originale.

3. Addebitate per quel risultato, cosa utilizzabile.

4. Transizione del backlog di materiale non consegnabile a qualcun altro.

Il codice che non può essere utilizzato è inutile. In effetti, è un costo.

Tu e il tuo cliente perdete tempo a cercare di "trasferire" il codice parzialmente completato a qualcun altro. Enfasi su rifiuti . È più facile per la maggior parte delle persone iniziare da zero piuttosto che iniziare da semi-finito.

What are your obligations when charging by the hour vs charging by project?

Essenzialmente la stessa cosa. Sii professionale.

If you agree to take on a project, give a rough estimate that it might take 10 days for you to work on and charge £X per hour - are you obligated to work for free after those 10 days are up and you have still not managed to complete your project due to unanticipated issues?

No - finché dura circa 10 giorni, allora stai bene. Definirei circa 10 giorni come ovunque tra 50 e 120 ore ai bordi estremi. Qualsiasi cosa per più di 120 ore (un superamento del 50%) è praticamente impossibile.

Sebbene "problemi inaspettati" lasciano molta imprecisione. Professionisti esperti anticipano molti più problemi rispetto ai nuovi sviluppatori. Tuttavia, se il cliente sa che sei un nuovo sviluppatore (e sai che stanno ottenendo uno sconto significativo a causa di esso), allora c'è un po 'di spazio di manovra qui.

What if you have delivered the project but bugs are found - should you fix these bugs for free if the 10 days are up or should you charge your client?

Bugs? Sì, dovresti correggerli gratuitamente. Non ti viene pagato per 10 giorni per produrre codice non funzionante.

Ora, di nuovo, "bug" è un po 'vago. Ci sono bug di tipo show-stopper (come, il programma non viene eseguito - ovviamente la tua colpa) e bug di bordo (il programma taglia il testo su Windows localizzato in turco con IME cinese abilitato - non proprio ragionevole). La maggior parte cade da qualche parte nel mezzo, ma l'onere della prova è su di te.

Ci sono anche bug delle specifiche: questi sono i più difficili. Dovrai usare il tuo giudizio per decidere se avresti dovuto ragionevolmente prevedere, mettere in discussione o sottintendere il cambiamento delle specifiche. Ancora una volta, ti metterei l'onere della prova.

Per un progetto di 10 giorni (80 ore) con uno sviluppatore verde, altre 10 - 15 ore di correzioni di bug non sarebbero chiedere troppo. In ogni caso, proverei a calcolare il pagamento - anche se probabilmente farei altre 5 o 10 ore gratuitamente prima di licenziare il cliente.

Also, for the above project, what should be the result when you start on the project, but after the 10 days for whatever reason you have to give up and tell your client that you cannot do it anymore? I realise that this does nothing to build your reputation and relationship with the client but are you obligated to pay back the money paid to you or do you just deliver the half/nearly completed source code and help them find someone else to complete it?

Restituisci i soldi. Se non riesci a finire il progetto, è probabile che non puoi giudicare completato a metà. Se il cliente ti ha assunto, è ancora più probabile che loro non possano giudicare completati a metà. Se riesci a trovare qualcun altro per finirlo, puoi subappaltarlo - la differenza in ciò che ti fanno pagare e ciò che hai già fatto è il tuo profitto (o perdita).

Alla fine, è spesso meglio piegarsi al cliente e calcolarlo come una lezione appresa. Dopo un po ', sarai in grado di individuare i "clienti problematici" ed evitarli (o ricaricarli) all'inizio. Imparerai anche a stimare un po 'meglio, a costruire costi di bugfix sui tuoi prezzi, ecc.

Come sviluppatore studente, hai un margine di manovra. Nessuno è in grado di farti causa per il costo di un progetto di 10 giorni. Non avrai mai più affari da quel cliente (o dai suoi amici) di nuovo - ma, dal momento che hanno ingaggiato uno sviluppatore studente, è probabile che vogliono solo manodopera a basso costo e non capiscono quanto costa effettivamente assumere un buon sviluppatore comunque. Non stai perdendo molto in futuro se non i mal di testa, anche se a costo di una coscienza pulita.

Il mio consiglio? Finiscila - ti sentirai meglio, il cliente si sentirà meglio, e sarai uno sviluppatore e un uomo d'affari migliori per questo. Non è che valga la pena di lavorare per anni - e hai tutti i tuoi amici su Stackoverflow e Stackexchange per aiutarti. ;)

Quello che stai descrivendo è solo "importo fisso o inferiore". Questo avvantaggia solo il cliente, quindi se stai facendo l'offerta non ho idea del perché potresti lavorare in quel modo.

• Frequenza oraria - È possibile utilizzare una tariffa oraria quando il client sa di non aver preso una decisione su alcune cose e concorda sul fatto che il progetto è un po 'a tempo indeterminato - ma questo deve essere concordato in anticipo .

• Tasso fisso : utilizza se il client sa esattamente ciò che desidera. Se lo fanno, ma non puoi dichiararlo a un importo fisso, non hai ancora nessuna offerta commerciale. Non far pagare il cliente per la tua inesperienza.

Se segui questo, non finirai in una situazione in cui non sai cosa fare. Se devi arrenderti, discuti con il cliente e tratti come una dimissione o una dissoluzione della partnership. Rimborsa tutti i soldi e non consegnare nulla, o offrire il progetto parziale in cambio di pagamento parziale.

Si sta tentando di applicare la tariffa oraria ogni volta che c'è qualche incertezza, ma dovrebbe essere utilizzata solo quando il client è loquace . Se hai esperienza ma hai ancora domande tecniche senza risposta significative, allora sii aperto su questo con il cliente in anticipo.

E, ottenere un contratto, o è solo una questione di tempo prima di incontrare problemi.

Non sono un avvocato, ma la risposta a entrambe le situazioni dipende da ciò che hai concordato contrattualmente con il cliente. Ho visto nella tua precedente domanda che stavi lavorando senza un contratto che sembra piuttosto pericoloso per le ragioni esatte che hai sollevato qui. Nessun contratto scritto certamente non significa nessun obbligo vincolante. È bello avere capito tutto questo genere di cose prima di iniziare il tuo rapporto di lavoro in modo che, in caso di problemi, possano essere risolti professionalmente e amichevolmente.

Motivi legali a parte, questo è un business del servizio dopotutto e tu vivi e muori per referenze. Ne può prendere solo uno cattivo per darti una cattiva reputazione. Posso solo prendere un cliente veramente soddisfatto per darti tanti altri lavori. Quindi applica la regola d'oro, tratta il tuo cliente come vorresti essere trattato, entro limiti ragionevoli. Le persone ricordano e apprezzano le persone che vanno un po 'oltre il loro "dovere".