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.

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.

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.

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.

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".

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.

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!

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 ... ".

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.

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.