Domanda:
Il mio primo progetto freelance mi ha richiesto il doppio del tempo stimato - Come devo procedere?
user20914
2014-06-04 01:48:56 UTC
view on stackexchange narkive permalink

Come mio primo lavoro di programmazione grafica freelance per &, (ho 19 anni) ho accettato di sviluppare un'applicazione web per un agente assicurativo locale.

Ho impiegato 4 mesi per completare il lavoro, mentre stimavo 1-2 mesi, originariamente. Ogni mese ho dimostrato i miei progressi, ma ho continuato a stimare la fine di ogni riunione, non prevedendo i molti problemi che avrei incontrato nel processo di sviluppo. L'agente assicurativo non ha espresso dispiacere verbale per il tempo impiegato dal lavoro, ma le sue risposte sono brevi e concise, e sono nervoso su come si sente riguardo al tempo impiegato.

Non sono sicuro di come dovrei gestire la situazione dopo aver impiegato così tanto tempo per completare il lavoro. Questo imprenditore è ben noto nella mia città e potrebbe potenzialmente portare a molti più affari se è soddisfatto del mio servizio.

Voglio sapere come devo procedere per mantenere la professionalità e fare del mio meglio per riparare i miei errori e ottenere in futuro una buona revisione da parte di questo datore di lavoro a qualsiasi potenziale datore di lavoro.

Ecco i dettagli che sto prendendo in considerazione:

  • Ho spiegato che questa era la mia prima applicazione web su vasta scala e che non ero sicuro del lasso di tempo. Ho stimato 1-2 mesi.

  • Ho calcolato il prezzo dell'applicazione in base al tempo che ho stimato che il lavoro avrebbe richiesto a uno sviluppatore più esperto, in modo da non addebitarlo di più a causa di la mia inesperienza. Ho valutato il lavoro a metà dell'importo che stimavo che altri sviluppatori freelance avrebbero addebitato, pari a $ 2000 in totale, per la progettazione e lo sviluppo di un'applicazione web front-end e back-end compatibile con Chrome.

  • Non sto addebitando il tempo effettivo impiegato (nemmeno vicino), ma un importo predefinito.

  • Questo accordo è stato stipulato in buona fede, con nessun termine contrattuale. Il titolare dell'azienda conosce mio padre, che mi ha fatto conoscere questa opportunità di sviluppo, quindi era adeguatamente sicura.

  • Sono un designer piuttosto bravo, che presta estrema attenzione alle funzionalità innovative dell'interfaccia, alla "perfezione" visiva e al codice efficiente. In altre parole, l'app è buona. Veramente buono. E ho accettato di aggiornare e mantenere l'app gratuitamente, con l'eccezione che l'hosting è a pagamento.

  • Ho offerto una funzionalità aggiuntiva gratuita, un client di messaggistica, al fine di (si spera) mantenere la sua compiacenza con la mia inesperienza.

Come dovrei procedere, ad esempio, dovrei scusarmi per il ritardo, ignorarlo, ecc.? Allo stato attuale, potrei ricevere una revisione dannosa per la reputazione dopo 3-4 stime della data di fine mancate (avrei dovuto lasciare aperta la data di fine, ma ho commesso un errore e ho continuato a stimare una data di fine).

http://creativemornings.com/talks/mike-monteiro--2/1
** \ * commenti rimossi \ *** Ricorda [a cosa servono i commenti] (http://workplace.stackexchange.com/help/privileges/comment)
Nota a margine: il tuo cliente probabilmente non si è reso conto delle implicazioni di "Chrome-friendly" - questo potrebbe tornare a morderti quando si rende conto che IE non funziona ...
Questa domanda non sembra riguardare la navigazione nel posto di lavoro professionale. Invece, suona come una domanda freelance. Per riferimento futuro, abbiamo un sito [Freelancing SE] (http://freelancing.stackexchange.com) per problemi di freelance. Buona fortuna e grazie per la partecipazione.
@jmort253 Il freelance SE è troppo giovane per una migrazione a questo punto?
Ehi @jt0dd,, l'ho preso in considerazione, ma le 10 risposte avrebbero coperto ogni possibilità che i membri di quella neonata comunità fossero in grado di contribuire in modo significativo, specialmente di fronte al punteggio +113 di Wesley Long. Se lo avessimo sospeso prima, probabilmente prenderei in considerazione la possibilità di migrarlo. Tuttavia, dovrebbe essere sicuro in quanto generalmente non cancelliamo i post con punteggi positivi, anche se fuori tema. Se ritieni che qualcosa non abbia risposta che sarebbe meglio indirizzato lì, potresti chiedere di nuovo su Freelancing SE, ma assicurati di adattare il post a quella comunità, non copiare incollare per favore. :) Spero che sia di aiuto!
Si prega di notare anche [Legge di Hofstadter] (https://en.wikipedia.org/wiki/Hofstadter%27s_law).Immagino che il mio punto sia che questo accade abbastanza, anche ai migliori, che ha la sua pagina wiki umoristica.Non scoraggiarti troppo dal fatto che ci sia voluto il doppio del tempo: in un certo senso stai già soddisfacendo gli standard del settore!
Dieci risposte:
#1
+142
Wesley Long
2014-06-04 02:06:19 UTC
view on stackexchange narkive permalink

Benvenuto nello sviluppo del software.

Regola 1: i clienti non sanno mai cosa vogliono o cosa hanno bisogno di entrare nel progetto. Se lo facessero, sarebbero i project manager. Sanno come fare il loro lavoro, non costruire gli strumenti per fare il loro lavoro. Nei progetti più grandi, esiste un'intera professione nota come "analisti aziendali" che lo capisce al posto loro.

Regola 2: i clienti creeranno nuovi requisiti durante il progetto, principalmente a causa della regola 1. Ecco perché si desidera avere requisiti e risultati chiaramente definiti e misurabili per iscritto.

Regola 3: questi requisiti in evoluzione sono ciò che fa o distrugge la maggior parte dei progetti. Assicurati di disporre di un processo chiaramente definito per le modifiche ai requisiti, compreso l'adeguamento del prezzo e del programma di consegna come condizione per accettare le richieste di modifica.

Regola 4: questi problemi riguardano molto più la gestione del progetto che non lo sono la tua abilità di sviluppatore. Hai appena ricevuto una lezione su qual è la differenza.

Regola 5: nessuno sano di mente si aspetta che un diciannovenne sia in grado di gestire un progetto, in particolare il suo primo progetto, e ottenere il tempo stima giusta. Il fatto che fosse solo il doppio della tua stima iniziale è in realtà piuttosto impressionante.

Hai affermato di aver completato il progetto come concordato senza modificare il prezzo. Questa è stata la decisione giusta. Chalk questo fino a sperimentare.

Dì al cliente: "Ho fatto un pessimo lavoro di stima della quantità di manodopera in questo progetto, ma credo di aver fatto un ottimo lavoro sul prodotto reale. Non sto cambiando il nostro - sul prezzo a causa di un mio errore. Spero che tu sia soddisfatto del tuo prodotto finito e spero di poterti utilizzare come riferimento in futuro. "

Per quanto riguarda la "perfezione" visiva, è necessario decidere con ogni progetto se si tratta di un lavoro "portfolio" o di un lavoro "paga i conti". Ad esempio: ho iniziato la mia carriera come ingegnere del suono. Ho fatto un po 'di lavoro gratuitamente per alcune giovani band che mi sarei vergognato di presentare a qualsiasi etichetta discografica. Ho fatto un po 'di lavoro retribuito per gli annunci dei concessionari di auto che erano più o meno "Mettigli un microfono e lo farò passare attraverso un compressore più tardi" perché avevo bisogno di finire il lavoro e di essere pagato quel giorno. Sembra che tu abbia fatto un pezzo per il portfolio. Se puoi usarlo come tale, fallo e sii felice.

Ricorda: il tuo obiettivo principale è migliorare. Hai 19 anni. Hai decenni per migliorare il tuo lavoro. Non scoraggiarti.

** \ * commenti rimossi \ *** Ricorda [a cosa servono i commenti] (http://workplace.stackexchange.com/help/privileges/comment)
Sono rimasto semplicemente colpito da quanto fosse incredibilmente perspicace, considerando quanto sia conciso.Penso che dovrebbe essere richiesta una lettura per qualsiasi aspirante sviluppatore
#2
+30
Underdetermined
2014-06-04 02:52:52 UTC
view on stackexchange narkive permalink

Ho appena aggiunto un account per darti i miei due centesimi. Insomma, non preoccuparti troppo. Wesley Long ti ha dato ottimi consigli / ragioni per cui la situazione in cui ti trovi è assolutamente accettabile.

Voglio aggiungere un'altra prospettiva a questo: Non venderti allo scoperto!

Se ti occorre il doppio del tempo per completare, forse hai ha creato qualcosa di più valore. È impossibile giudicare con precisione quanto valga uno sviluppo del genere, soprattutto da parte di clienti che non conoscono la tecnologia alla base di ciò che si sta facendo. Si affidano tanto alla tua presentazione per giudicare il merito del lavoro quanto alla loro esperienza passata.

Il tuo atteggiamento nel modo in cui presenti i risultati è importante! C'è anche molta psicologia coinvolta in questo. Una bandiera rossa per me è stata la promessa di funzionalità aggiuntive gratuite . Tutto ciò che si ottiene nella mia mente è ridurre il valore del tuo lavoro complessivo.

Non conosco il tuo settore o cosa hai fatto in modo specifico, ma ho visto che progetti molto più grandi offrono molti meno risultati, altri superati da multipli molto maggiori della stima originale.

Non sto sostenendo che ti concentri esclusivamente sulla presentazione e sulla vendita di bit e trascuri le tue effettive capacità di base, il mondo ne ha abbastanza di quelle persone. Ricorda solo che dovrai venderti costantemente per tutta la tua carriera. Una parte è produrre un prodotto all'avanguardia, l'altra è far capire al tuo cliente.

#3
+11
dyesdyes
2014-06-04 14:50:35 UTC
view on stackexchange narkive permalink

Mi sono trovato nella stessa situazione qualche anno fa.

Ho stimato un progetto in 3 mesi a circa 25 ore a settimana e finito dopo 5 mesi a 35 ore a settimana in media.

La tua decisione è stata buona. Non dovresti addebitare al tuo cliente il tuo errore.

Inoltre, l'aggiunta di alcune funzionalità gratuitamente per compensare è il modo giusto di fare affari.

Don " t venderti a buon mercato

Ma una cosa a cui devi stare attento è essere sottopagati. Il primo grande progetto che fai è sempre difficile e quindi essere sottopagato non è un problema. Ma 2000 $ per 2 mesi di lavoro non sembrano davvero equi in primo luogo (anche se dipende da quanto tempo alla settimana hai pianificato di dedicarci).

La stima di un progetto è un lavoro duro e verrà con il tempo. Alcuni dicono che devi moltiplicare per Pi la tua stima per avere effettivamente quella giusta in quanto avrai molti problemi imprevisti, alcuni test ecc ...

Non impegnati a lungo termine gratuitamente

Penso che il tuo unico vero errore sia la manutenzione gratuita del sito web. La manutenzione è una parte integrante dell'attività e impegnarti a mantenerla gratuitamente diventerà probabilmente una seccatura in seguito per te.

Oggetto: Manutenzione a lungo termine, considererei qualsiasi offerta di aggiornamenti e manutenzione perennemente gratuiti come un segno di inesperienza e non avrei molta fiducia in tale offerta.
#4
+8
ero
2014-06-04 14:18:30 UTC
view on stackexchange narkive permalink

In realtà la tua domanda praticamente risponde da sola. Hai già proceduto bene:

  1. Consegnato un prodotto di alta qualità
  2. Non hai addebitato nulla per il tempo extra speso
  3. Aggiunta una funzione extra come compensazione

Dato che il tuo cliente non ha espresso alcun dispiacere, è probabile che pensi che tu l'abbia gestito correttamente. Risposte brevi e concise non significano necessariamente che sia arrabbiato. Molto probabilmente significa che ha delle responsabilità, tratta 3 dozzine di email al giorno in modo che non si prenda il tempo di iniziare i suoi messaggi con "Ehi amico, come stai? Hai passato un bel weekend?".

Uno ultima cosa: non essere troppo duro con te stesso. La stima del carico di lavoro su un progetto è un'abilità che può essere acquisita solo con l'esperienza. Non è facile ed è praticamente un lavoro in sé chiamato project manager. Sarai più bravo.

#5
+3
Giacomo1968
2014-06-06 03:04:16 UTC
view on stackexchange narkive permalink

Hai già scelto una risposta e alcune persone la sfiorano vagamente, ma ciò a cui si riduce è qualcosa di veramente semplice:

Indipendentemente da quanto semplice o complesso possa essere un progetto, devi avere il controllo della struttura del tuo progetto sin dall'inizio.

Meno pianifichi, più cadrai in un ciclo di sviluppo senza fine. Devi stabilire dei limiti chiari in modo che il cliente ottenga ciò che vuole & tu ottieni ciò che vuoi.

La realtà è che, a meno che questa persona non ti conosca, le possibilità che tu ottenga commissioni extra a questo punto sono zero. Detto questo, questo potrebbe essere un caso in cui dopo che questo progetto è finito hai un punto di discussione: "Bene, l'ultimo progetto ha avuto problemi. Se vuoi lavorare con me su un nuovo progetto, questo è quello che dobbiamo fare ". Significa sfruttare questo fallimento per ottenere successi futuri!

Detto questo, mi ci sono voluti decenni per perfezionare il modo in cui gestisco queste situazioni. Ma logicamente tu stesso devi dividere le cose in questo modo.

  1. Quali sono i tuoi punti di forza. Non mentire a te stesso su questo. Lavoro principalmente nel mondo dell'amministrazione di sistemi Unix / Linux & Incontro sempre sviluppatori che si vantano di quanto siano bravi nello sviluppo full-stack. Sciocchezze. La maggior parte degli sviluppatori web è brava nel design front-end, alcuni più nello sviluppo front-end, altri nello sviluppo back-end, altri nella strutturazione del DB e alcuni sono bravi nell'amministrazione dei sistemi. Ma davvero non puoi essere un maestro di tutte quelle abilità. Il punto è che se qualcuno ti avvicina per un progetto, molto probabilmente vorranno che tu sia tutto quanto sopra più un project manager. Sei pronto ad assumerti questa responsabilità? Fin dall'inizio devi fondamentalmente dire: "Beh, hai visto che ho fatto X. E pensi che il tuo progetto sia X. Ma in realtà io sono Y. Posso aiutarti, ma devi realizzare i miei punti di forza & limiti."
  2. Crea i documenti prima di ogni altra cosa: mappare il progetto in blocchi. Punti elenco puntato. Ad esempio, un progetto di sviluppo web può essere suddiviso in: discovery, information architecture, wireframe, visual design & functional design. Rendi molto chiaro che ogni punto elenco è una cosa separata. Ed essere preparati a dire cose come: "Dobbiamo discuterne in una fase successiva, forse a questo punto ..."
  3. Crea una sequenza temporale. In genere nella scoperta puoi stimare il periodo di tempo complessivo di un progetto comprese le pietre miliari obiettivi &. Rendi molto chiaro al cliente che questo accadrà in seguito, quello in seguito. Personalmente mi piace fare di una settimana il tempo minimo per qualsiasi cosa. Quindi, per semplici correzioni, 1-2 settimane. Per la riprogettazione del sito, 3-6 mesi.
  4. Fattore di manutenzione. La manutenzione dovrebbe sempre essere una cosa separata dal progetto principale & negoziato come tale. Non lasciare che il tuo ciclo di sviluppo principale si trasformi mai nella manutenzione del codice.
  5. Strategia di uscita. La strategia di esistenza più basilare è la classica divisione 50/50. Significa che, una volta che sei soddisfatto l'uno dell'altro & degli obiettivi, chiedi il 50% in anticipo. Metti in chiaro che nessun lavoro viene eseguito fino a quando non viene ricevuto il 50%. Metti anche in chiaro che se per qualsiasi motivo ritieni di dover abbandonare il progetto, mantieni il primo 50% & non ricevi il secondo 50%. Questo accade molto più di quanto ti aspetti. E non dovresti vergognarti di dire: “Guarda, non sta funzionando. Devo smetterla. "
  6. Chi ottiene la custodia dei bambini (aka: codice): definisci anche cosa potrebbe comportare un'uscita dal punto di vista del codice. Significa che mantieni il codice cotto a metà? Oppure lo dai al cliente & e dici: “Questo è il lavoro che ho fatto finora. Trasmettilo a qualcun altro. " Questa è una chiamata difficile. In generale, non ti senti proprietario nei confronti del codice contratto.
  7. Avere alleati di codifica. Questa è un'altra grande cosa da fare. Fondamentalmente, sempre in rete con altri programmatori. E se inizi a stancarti di un progetto, non preoccuparti di chiedere a uno di questi altri programmatori di subentrare per te. Detto questo, molti programmatori non vogliono prendere in carico il mal di testa di qualcun altro. Ma poi di nuovo, tornando ai punti di forza, per quanto ne sai un altro programmatore potrebbe avere abilità in cui è forte e in cui sei debole. Quindi potresti formare una squadra per complimentarti a vicenda anche solo per un semplice progetto.
  8. Non prendere gli affari sul personale. Tutti questi punti sopra sono focalizzati sul farti capire che sei entrare in una transazione commerciale in modo da non prendere nessuna di queste decisioni personalmente. Quindi, se un cliente si comporta come un idiota, & cerca di ottenere di più da te di quanto tu abbia accettato? Basta farglielo notare. Non lo accettano? Andarsene. E se sei arrabbiato? Indovina un po? Ci arrabbiamo tutti per progetti falliti. Fai una passeggiata intorno all'isolato. Scaricalo dal tuo sistema. Ma riprenditi. Le persone ti vogliono per le tue abilità & dovresti trattare le tue abilità come una merce.

Inoltre, crea confini realistici. Ho lavorato come freelance per oltre 10 anni & ogni volta che ho detto che alle persone casualmente avrei avuto ogni idea folle che qualcuno mi avesse lanciato come se stessi cercando lavoro. In generale la società vede i liberi professionisti come casi di beneficenza. E la cosa migliore che ho fatto per fermare quel flusso infinito di "grandi idee" è stata ottenere un concerto a tempo pieno. Ma se torno a fare il freelance, il mio atteggiamento è semplicemente quello di dire subito: "Guarda, devo solo dire che non sto davvero cercando lavoro in questo momento".

#6
+1
pawel-kuznik
2014-06-06 17:46:52 UTC
view on stackexchange narkive permalink

Un buon consiglio. Non dire mai al cliente quando arriverà il prodotto finale. Invece di quello, disegna loro una linea temporale quanto tempo impiegherà ogni pezzo. Divina il tuo progetto in fasi o moduli e presentalo ogni volta che raggiunge uno stato stabile. Raccogli input per ogni fase e modulo e sii onesto nei confronti del cliente sui costi aggiuntivi. Sii flessibile. Anche i tuoi clienti lo apprezzeranno, perché desiderano una soluzione su misura.

Inoltre è una buona idea dare una stima o un costo base di un progetto all'inizio, ma anche informarli che le funzionalità aggiuntive costeranno di più e prolungheranno il progetto.

Questo flusso di lavoro ti darà anche una relazione più stabile con i clienti e creerà più fiducia nelle tue relazioni con loro.

Inoltre:

  • Quindi, don non accusarli dei tuoi errori. È molto brutto e lascerà un cattivo gusto dopo aver finito.
  • Lascia una buona documentazione sul tuo progetto. Sia per i clienti che per i futuri manutentori (molto probabilmente sarai tu, quindi sii buono per te stesso).
  • Quando lasci il progetto puoi suggerire loro che tipo di miglioramenti potrebbero essere applicati anche al progetto. (sii ​​onesto)

PS. Per un primo progetto, va ancora bene raddoppiare il tempo necessario. Migliorerai la stima dei prossimi progetti, quindi tieniti al passo.

#7
-1
Vidar S. Ramdal
2014-06-05 21:28:43 UTC
view on stackexchange narkive permalink

Per un primo progetto, non credo che tu abbia fatto così male. È difficile dirlo senza conoscere le persone coinvolte, ma se il tuo cliente non ha espresso dispiacere ed è probabile che sia soddisfatto del risultato finale, penso che tu possa presumere che sia felice.

In merito a come procedere, altri rispondenti hanno dato buoni consigli su come comunicare con il tuo cliente. Quello a cui dovresti pensare ora è come puoi usare queste esperienze nei tuoi prossimi progetti.

  • Assicurati che tu e il cliente siate sulla stessa pagina del lavoro da fare - scrivi una specifica chiara
  • Impara come chiudere un progetto - come dire al cliente che il tuo lavoro è finito e se vuole qualcosa di più, te lo fai pagare
  • A volte, dovrai mettere da parte un po 'del tuo perfezionismo. Sì, ti sei preso il tuo tempo per scrivere codice pulito ed efficiente, ma al cliente interessa davvero così tanto? Se stai entrando troppo nei dettagli, farai saltare di nuovo le tue stime
  • Non offrire mai una manutenzione perpetua e gratuita: questo può tornare e morderti se tu e il tuo cliente non avere una chiara comprensione di ciò che è coperto dalla "manutenzione".
  • In futuro, se vedi che mantenere questo primo progetto richiede troppo tempo lontano da altri lavori, non aver paura di dire al tuo cliente che devi dare la priorità all'altro lavoro (retribuito).

Buona fortuna con la tua carriera!

#8
-1
Kaz
2014-06-06 02:18:55 UTC
view on stackexchange narkive permalink

Il cliente non ha detto nulla sul ritardo, molto probabilmente perché l'applicazione è molto buona (se ci crediamo sulla parola), il prezzo fisso era un buon affare e il tempo straordinario era gratuito.

Se sei nervoso per questo (o per qualsiasi altra cosa), una buona strategia è che tu sia la persona che lo solleva per primo.

"Anche se sembri soddisfatto del progetto e mi sento bene anche per la qualità, mi dispiace di non aver previsto con precisione il tempo necessario per il completamento. La stima del progetto software è ampiamente considerata complicata; lavorerò per migliorare questa abilità con ciascuno nuova esperienza lavorativa. Spero che la consegna tardiva non abbia avuto un impatto negativo sulla tua attività. "

Se tiri fuori qualcosa per primo, mantieni sempre una posizione migliore o addirittura un vantaggio. Quando l'altra parte lo solleva, c'è spesso un senso persistente, solo percepito o reale, come se il problema venisse introdotto con, "non sembri attribuire molta importanza o consapevolezza a quanto segue, ma Vorrei parlare di ... ".

questo non sembra offrire nulla di sostanziale rispetto ai punti fatti e spiegati nelle 5 risposte precedenti
@gnat offre meno TL; DR.
Trovo difficile capire come _less / tldr_ sia conforme a ** [Esegui il backup e non ripetere gli altri] (http://meta.workplace.stackexchange.com/questions/255/faq-proposal-back-it -up-and-dont-repeat-others) ** regole
#9
-1
Galadrius Krunthar
2014-06-06 04:32:18 UTC
view on stackexchange narkive permalink

I progetti IT sono notoriamente difficili da stimare, basta guardare a tutti i grandi progetti IT pubblici (in particolare nel Regno Unito) che hanno fatto saltare la pianificazione e i budget molte volte.

  1. Cerca di non accettarne un altro progetto a prezzo fisso fino a quando non cerchi "punti funzione" (non è un numero di funzioni nel tuo codice ...) e come scrivere contratti di lavoro basati su punti funzione.
  2. Dal momento che sei solo agli inizi probabilmente dovrà accettare qualche altro progetto a prezzo fisso. Una regola pratica che mi è servita bene per stime rapide: se pensi che ci vorrà un determinato periodo di tempo, raddoppia e aggiungi un altro 10%. Probabilmente sottovaluterai ancora ma non così male. Gli ingegneri tendono ad essere troppo concentrati su come risolvere il problema e si perdono sempre tutte le cose che possono andare storte e non riescono a tenere conto di tutti i pezzi ausiliari che sono anche parte importante della consegna (ad esempio documentazione, configurazione del sistema e configurazione, test, formazione ...). Inoltre, come già accennato da altre persone, il progetto non è mai chiaramente definito all'inizio indipendentemente da quanto chiara sia la visione delle cose che il tuo cliente ha. Ci sono sempre pile di cose che non sono ben definite e necessitano di ulteriore lavoro da elaborare, e ci sono sempre funzionalità aggiuntive a cui il cliente pensa in seguito e naturalmente presume che farai gratuitamente con un contratto a prezzo fisso (fare riferimento al punto 1).
  3. Accetta il fatto che perderai denaro su questi progetti iniziali e considerali semplicemente come un'esperienza di apprendimento.
  4. Controlla il diritto contrattuale nelle giurisdizioni in cui lavori. In alcuni luoghi, se qualcuno esperto nell'arte in questione sta effettuando una stima, tale stima non può essere più del 20-30% in meno rispetto al tempo / importo effettivo, anche se sono state negoziate aggiunte al contratto e aggiunte al contratto su richiesta del cliente. Se questi extra si accumulano, devi rinegoziare e firmare l'intero contratto da zero o il cliente avrà il diritto legale di rifiutarsi di pagare qualsiasi importo superiore alla somma iniziale + 30%.
  5. Assicurati di effettuare consegne regolari ( non solo mostrare al cliente che stai progredendo) come se non avessi accettato consegna oltre la scadenza, potrebbe rifiutarsi di pagarti qualsiasi cosa.

E, come già accennato in molte altre risposte, questo è VERAMENTE male: "E ho accettato di aggiornare e mantenere l'app gratuitamente, con l'eccezione che l'hosting è a pagamento."

Non dovresti MAI promettere a nessuno un servizio perpetuo, gratuito, illimitato e INDEFINITO. Spero che tu non l'abbia messo per iscritto.

#10
-1
Vector
2014-06-06 13:36:49 UTC
view on stackexchange narkive permalink

Non c'è bisogno di "scusarsi". IMO che è decisamente poco professionale, a meno che il tuo cliente non ti spinga esplicitamente contro il muro al riguardo.

Se ciò dovesse accadere, non cercare di svincolarti, chiedi scusa solo che sei ancora un principiante e hai fatto del tuo meglio, ma non sei ancora esperto nel fare stime accurate dei tempi . Non entrare in lunghe spiegazioni e scuse. Sii breve, conciso e professionale.

Offrire "extra" come compenso per il ritardo potrebbe non essere una buona idea, come altri hanno già detto: questo tende a svalutarti e ti fa sembrare un po 'disperato (mai una buona cosa), mette a fuoco sulla tua mancanza di esperienza e ti lascia vulnerabile a infinite richieste di "freebees", ecc. Ma quello che è fatto è fatto. Evitalo in futuro.

Non hai addebitato in base al tempo, sei stato sincero e onesto con loro sin dall'inizio e hai valutato il lavoro in base alla tua esperienza. Quindi, penso che tu sia partito bene. Finché hai consegnato un prodotto solido e funzionante, non penso che tu debba essere troppo preoccupato. Il cliente può sembrare impaziente, ma se hai fatto un buon lavoro sarà presto placato quando si godrà i frutti del tuo lavoro.

Per il futuro: finché non sarai veramente bravo a stimare i tempi di consegna (quello richiede un po 'di tempo, e spesso anche gli esperti commettono errori su questo) triplicare o quadruplicare (almeno ...) il numero che inizialmente ti sembra praticabile.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...