Questioni contrattuali
This is a big mistake because the time that I will spend [...] will not be paid
In realtà, il grosso errore è che il tuo contratto consente di trascorrere il tuo tempo lavorando gratuitamente. Non importa se stai risolvendo un bug o stai imparando una tecnologia richiesta per un nuovo progetto: il cliente deve pagare per il tempo che passi.
Non dovresti lavorare gratis. È così semplice. Ti fa stare male, e incoraggia i tuoi clienti a pensare a te come a un ragazzo che lavora gratis in ogni caso, e quindi a chi non deve essere particolarmente rispettato, o pagato del tutto, dopotutto. Non appena il tuo cliente sa che passi un'ora a lavorare gratis, la tua relazione è fottuta.
Questo è anche il motivo per cui è essenziale avere un contratto scritto da un vero avvocato specializzato in contratti di sviluppo software.
Stime tecniche
What errors I did, and how can I avoid it in the future.
Tecnicamente parlando, l'errore era di dare una stima troppo velocemente. Potresti aver trascorso qualche ora in più a studiare l'impatto e probabilmente trovare la relazione tra i dati e l'autenticazione.
Ma tali errori accadono comunque, quindi non è un grande errore dal punto di vista tecnico.
Questo non è molto diverso dai casi in cui si fornisce una stima di due settimane per un'attività e una settimana dopo aver avviato l'attività, si scopre che richiede molto più lavoro. Quindi, è sufficiente inviare agli stakeholder (sarebbe il tuo manager o il tuo cliente) la stima riaggiustata che tiene conto delle cose che hai scoperto nel frattempo.
Potresti aver sbagliato a dare una stima molto precisa. Se dici che un cambiamento richiederà "ottanta ore", non è la stessa cosa di "dieci giorni" e non è la stessa cosa di "due settimane". Inoltre, le stime sono spesso rappresentate come un intervallo o contengono un suggerimento sulla precisione:
The task will take from 4 to 9 days.
o
The task will take 16 days ± 4 days.
Questo rende il riadeguamento progressivo della stima più intuitivo.
Un altro aspetto importante è che dovresti essere in grado di dire di no. Questo si applica specificamente a questi due tipi di domande:
“Do you know how long this task will take?”
Se non sai quanto tempo impiegherà l'attività, non dire "Tre settimane" solo per liberarti della persona.
“Can you make an effort to deliver it faster?”
Se rispondi "Sì", significa che l'ultima stima era sbagliata (nel qual caso, perché dovresti fare preventivi sbagliati in primo luogo?), o che sai come essere più produttivi, ma don ' Lo faccio a meno che non sia espressamente richiesto, il che non sembra molto professionale.
Tutto dipende dalla leva
Ma, ancora una volta, la cosa più importante è come interagisci con il tuo cliente, che si riduce a due cose: che cosa dice il contratto e qual è la tua leva.
Ad esempio, confronta questo messaggio:
On February 7th, I sent you an estimate of 8 days ± 3 days for the task of migrating the bottom menu to the new data source. It appears that the task also requires to make changes in the top menu, since both partially rely on the same code. Given those new elements, the updated estimate is 11 days ± 2 days.
con questo:
On February 7th, I sent you an estimate of 8 days ± 3 days for the task of migrating the bottom menu to the new data source. It appears that the task is much more difficult than I thought, so I'm not sure I'll be able to release the changes on time. Can you, please, accord me three additional days for this task?
Il secondo fa schifo. Mostra che lo sviluppatore non ha alcun tipo di leva. Non dà alcuna stima, ma implorando a malapena i tempi supplementari. Sembra che lo sviluppatore abbia infastidito la stima originale e si sente in colpa. Il primo messaggio è puramente informale: ecco una stima, non mi interessa cosa ne pensate e non ho bisogno della vostra approvazione, dal momento che il nostro contratto non richiede la vostra approvazione in questo caso. La mia stima iniziale era corretta, e la successiva prende in considerazione informazioni aggiuntive. Niente di più.