Dovresti addebitare ai clienti le ore trascorse sulla strada sbagliata? [chiuso]


17

Ho accettato una piccola sfida CSS da risolvere per un cliente e sto per essere pagato con una tariffa oraria. Alla fine l'ho risolto, ci sono volute 5 ore ma ho trascorso circa il 25% del tempo nella traccia sbagliata, provando una soluzione CSS3 che ha funzionato solo nei browser recenti e alla fine scoprendo che nessun fallback è possibile tramite JS (come pensavo inizialmente). Devo addebitare al cliente quel 25%?

Maggiori dettagli: non ho fornito un preventivo, mi è piaciuta la sfida di per sé, quindi ho iniziato a lavorarci prima di dare un preventivo (ma ho lavorato con lui prima, quindi so che non è una di quelle persone che hanno aspettative non realistiche ). Nel peggiore dei casi, avrò trascorso 5 ore non pagate in un'affascinante sfida CSS. E darò la stima più equa possibile per entrambi, poiché avrò già svolto il lavoro. :)

Modifica: grazie a tutti, vorrei poter accettare più di una risposta! Ho finito per non fatturarlo per le ore extra (l'ho fatturato per 3 e mezzo), ma le ho menzionate, in modo che sappia che ci ho lavorato più di quanto non lo abbia fatturato. Forse è per questo che ha immediatamente accettato la "stima" (che in quel caso non era una stima, quindi le virgolette).


Quale stima iniziale hai dato al tuo cliente?
JK

2
Stai sperando in più lavoro da parte del cliente? Che tipo di relazione vuoi stabilire?
Steve Jackson,

@Jonathan: guarda la mia modifica
Lea Verou


1
Non è un duplicato, ho letto quella discussione prima di pubblicare la mia domanda. Sta parlando di imparare cose nuove, non di lavorare sulla soluzione sbagliata.
Lea Verou,

Risposte:


24

Spesso ho tali situazioni quando passo qualche ora a fare qualcosa, poi noto che esiste una soluzione a una linea più semplice, o che la mia prima idea è stata troppo cattiva, ecc.

In generale, in questi casi, faccio la differenza tra tre situazioni:

  • La soluzione appena scoperta non era ovvia e / o uno sviluppatore medio sarebbe probabilmente sulla strada sbagliata e / o la pista sbagliata era un prerequisito per trovare la soluzione finale. In questo caso, addebito al cliente il tempo trascorso sulla strada sbagliata.

  • La soluzione appena scoperta non era così ovvia, ma probabilmente molti sviluppatori medi sarebbero andati direttamente in questo modo. In altre parole, se pensassi meglio prima di iniziare a scrivere codice, probabilmente avrei potuto trovare direttamente la soluzione finale, o forse no. In questo caso, addebito al cliente, ma riduco il prezzo della metà o di una percentuale che sembra la più adeguata.

  • Ovviamente, ero troppo stupido, troppo assonnato o non ci pensavo affatto prima di iniziare a scrivere codice, poiché la soluzione finale era estremamente facile da trovare. In questo caso, anche se ho trascorso due giorni sulla strada sbagliata, è mia responsabilità e il cliente non deve pagare per quello.


Non credo che gli sviluppatori "medi" lo risolverebbero affatto. Ma per quelli con un'esperienza CSS più della media, probabilmente sarebbe il 2 °.
Lea Verou,

1
@Lea Verou: quando parlo di "sviluppatori medi", è molto soggettivo. Dipende anche dal tuo livello e da cosa pensa il tuo cliente del tuo livello. Se il tuo cliente sa che sei il meglio del meglio e ti paga migliaia di dollari al giorno, la "media" soggettiva sarà molto più alta di se il tuo cliente pensa che tu sia una scimmia di codice.
Arseni Mourzenko

Bene, parlo in grandi conferenze sul CSS, e lui lo sa :) Ma sicuramente non
guadagno

4
Vorrei anche prendere in considerazione la tua tariffa. Se la tua tariffa è molto alta, allora dovresti essere migliore della media, quindi ovvio può significare molte più cose. Se la tua tariffa è molto bassa, NON ti aspetti che sia al di sopra della media, questo è meno ovvio.
Martin York,

per copiare e incollare un commento che ho fatto altrove: il tempo trascorso lavorando / pensando / ricercando / ottimizzando un problema è tempo impiegato su un problema. MA che dire di qualcuno che passa il tempo per sth che dovrebbe conoscere (per l'attività assunta) e / o che è già risolto (ed è ciò che viene richiesto). In altre parole, non ci sono scuse per la mancanza di conoscenza o semplicemente un cattivo lavoro professionale. Si noti che un vero professionista può (e dovrebbe) effettivamente fare un caso convincente per quanto tempo è stato speso e perché
Nikos M.

33

Non penso che tu fossi sulla strada sbagliata. Hai codificato una soluzione, testato la soluzione (complimenti) e hai scoperto che non funzionava come previsto. Hai eseguito il debug della soluzione e hai quindi apportato la correzione andando in una direzione diversa.

IMHO, questa non è la strada sbagliata. Questo è uno sviluppo software regolare.

Se fossi in te, farei pagare per le 4 ore complete.


1
Mi piace il modo in cui pensi: p :)
Lea Verou

2
Concordo, per natura, la ricerca / progettazione è un'area in cui anche le svolte sbagliate sono importanti. Dimostrare che qualcosa non funziona (e lasciare una traccia) semplifica la manutenzione perché il prossimo non lo proverà.
Matthieu M.

1
Ecco come fanno tutte le altre professioni. Solo i programmatori sono "nobili" (o, per dirla chiaramente, ingenui) anche solo a pensare di non fatturare per tutte le ore lavorate sul problema del cliente.
quant_dev,

8

La maggior parte dei programmi che scriviamo, stiamo scrivendo perché una soluzione non è immediatamente, facilmente disponibile. Quasi tutto ciò che facciamo comporta l'apprendimento di qualcosa di nuovo. Il cliente non ti stava pagando per il prodotto. Ti stava pagando per imparare a costruire il prodotto e dandoti i risultati (e se lui stesso lo definiva una "sfida", si aspettava che tu imparassi qualcosa). Vedi "Waltzing with Bears" di Tom de Marco e Timothy Lister - "Se un progetto non ha rischi, non farlo".

Se vuoi rimborsare correttamente il cliente, inviagli la tua soluzione insieme ai dettagli delle soluzioni che non hanno funzionato, in modo che possa passare quelle a qualsiasi altro personale che assume e aiutarli a impiegare meno tempo.

Sta a te negoziare se pensa di pagare troppo. Certamente, mi aspetterei che pagasse per qualsiasi apprendimento che non è facilmente utilizzabile altrove.


Lui stesso non l'ha definita una sfida, non aveva idea che fosse una sfida. (anche se probabilmente ha trovato difficile decidere di esternalizzarlo)
Lea Verou

I downvoter potrebbero commentare il motivo per cui questo è in fase di downgrade?
Lunivore

5

A volte la risoluzione di un problema comporta l'eliminazione delle soluzioni non ottimali da una serie di opzioni ragionevoli. Il processo di eliminazione è uno dei tuoi strumenti di risoluzione dei problemi; il cliente ti sta pagando per una soluzione e dovrebbe aspettarsi che tu usi tutti gli strumenti a tua disposizione.

Sarebbe un client irragionevole che si aspetta che tu possa immaginare immediatamente la soluzione migliore, passando direttamente dal briefing del progetto alla tastiera, dove emetti un flusso di codice rapido e ottimale senza backspace. Il che non vuol dire che non ci sono tali clienti. Ho avuto il cliente che ha chiamato nel bel mezzo del progetto per verificare che stesse effettivamente pagando solo per "programmazione, non debug". E naturalmente ci sono i clienti (o i capi) per i quali la programmazione è l'atto fisico di digitare.

Il tuo vicolo cieco potrebbe rappresentare il miglior denaro speso dal cliente: un altro sviluppatore potrebbe non essere stato completo come te, e ha fornito una soluzione più economica ma meno compatibile che potrebbe rimandare indietro in futuro.


2
Odio imbattermi in questi ragazzi che hanno questa mentalità di "programmazione, non di debug". Come se uno scrittore potesse semplicemente iniziare a scrivere una storia senza rileggerla e apportare modifiche. Sarebbe probabilmente una storia schifosa se scritta in quel modo :-).
Htbaa,

5

queste domande mi fanno impazzire ...

se un meccanico o un avvocato passasse del tempo a lavorare sul tuo caso / problema, scommetti che il tuo @ $$ ti verrebbero addebitati, anche se trascorrevano del tempo sulla strada sbagliata

i programmatori devono iniziare a valutare di più il loro tempo


sarei d'accordo (quindi +1) il tempo trascorso a lavorare / pensare / ricercare / ottimizzare un problema è il tempo lavorato su un problema. MA che dire di qualcuno che passa il tempo per sth che dovrebbe conoscere (per l'attività assunta) e / o che è già risolto (ed è ciò che viene richiesto). In altre parole, questa non è una scusa per la mancanza di conoscenza o semplicemente un cattivo lavoro professionale. Si noti che un vero professionista può (e dovrebbe) effettivamente presentare un caso convincente per quanto tempo è stato trascorso e perché
Nikos M.

5

Quello che hai fatto è stato perfettamente normale. Fred Brooks discute questo fenomeno nel capitolo "Plan to Throw One Away" del suo libro fondamentale sull'ingegneria del software "The Mythical Man-Month".

Stavi lavorando a un contratto di tempo e materiali; pertanto, dovresti addebitare al suo cliente tutto il tempo che hai trascorso lavorando al progetto. Spetta al cliente determinare se ha ricevuto abbastanza valore per il suo investimento.


4

Lo guardo in questo modo: alla fine della giornata, è la tua chiamata a farti pagare. Esistono molte variabili come la soddisfazione che desideri del cliente, la relazione esistente, le tue capacità di vendita, ecc ... che conosciamo tutti. Ciò che in definitiva stai fornendo al cliente, e ciò che vogliono veramente, è il valore. Quale valore hai dato al cliente e qual è la soluzione / deliverable che stai fornendo loro valore?

Potrebbero essere necessari 10 minuti per risolvere un problema, ma ci sono voluti 10 anni per imparare a risolverlo. Questo merita di essere considerato. Allo stesso tempo, alcuni di noi considerano la capacità di apprendere una compensazione "sul posto di lavoro". Spesso imparo cose che fanno davvero parte del cliente, che considero una forma di compensazione non monetaria.

Puoi anche aggiungerlo alla fattura, quindi contrassegnarlo come "sconto cliente preferito" sulla fattura, non addebitare e costruire un po 'di buona volontà. Lo faccio ogni tanto, il che fa stare bene il cliente.

Inoltre, la tua domanda se ci sono sviluppatori che stanno guadagnando migliaia di dollari al giorno, la risposta è sì. Dovresti essere uno di loro, anche con le tue abilità. Sono praticamente lì, e non sono affatto vicino a essere nella stessa lega con te in CSS.


1
+1, questa risposta è fortemente sottovalutata. Ad entrambe le risposte più votate manca totalmente il punto "qual è la soluzione che vale per il cliente". Cavolo, a volte addebitiamo a un cliente 3 volte lo sforzo che effettivamente abbiamo fatto perché potrebbe essere ancora più economico per lui di qualsiasi soluzione possa ottenere da un concorrente.
Doc Brown

2

Dipende dall'accordo originale.

Hai detto che lo avresti consegnato fatto e pronto per partire? Quindi ti conviene pagare per tutto il tempo impiegato a svilupparlo. Tutto!


2

Se assumi un avvocato per discutere un caso per te, e loro falliscono e perdono per te, pagherai comunque il loro conto.

Ecco come fanno tutte le altre professioni. Non vi è alcun motivo per cui i programmatori dovrebbero fare diversamente.

Se il cliente pensa di aver pagato troppo, non tornerà da te. Mantenerli come clienti abituali è l'unica ragione ragionevole per non fatturare per tutte le ore lavorate.


1

Se è un progetto che ho intrapreso in modo specifico, così qualcuno mi pagherebbe, mentre mi sono insegnato alcune nuove tecnologie, tendo a farlo per meno di quanto normalmente mi si aspetterebbe. D'altra parte, non puoi fare offerte troppo basse, o faranno le cose con quel cliente per sempre ("Ehi, quando hai fatto quella cosa davvero bella, hai fatto pagare molto meno di questo!") Altrimenti, non t conto del tempo in cui ho sbagliato e alla fine ci è voluto troppo tempo.

La mia eccezione a questa regola: se il motivo per cui il problema ha richiesto ore per essere risolto è perché il cliente mi ha fatto una cazzata su qualcosa che avevano rotto, mi farò pagare per tutto.


1

Normalmente non farei pagare se fosse palesemente colpa mia e mi stavo solo masturbando, ma non sono affatto intelligente. Ho scoperto che la maggior parte delle persone in gamba sono in grado di applicare questa filosofia che i clienti pagano per il loro tempo e non semplicemente un risultato finale. Ci sono molte volte nella mia carriera in cui, a posteriori, mi sono pentito di non aver pensato in questo modo. Tutto quello a cui pensavo era che il risultato finale valeva, il mio tempo era insignificante a meno che non migliorasse il risultato finale. Eppure uno potrebbe essere trascinato in giro e perdere molto tempo a causa dei clienti che cambiano idea, dei colleghi che causano bug che ti vengono assegnati e ritardano il tuo lavoro, ad esempio, e non semplicemente perché avevi bisogno di un po 'più di ricerca in anticipo per sapere davvero cosa stavi facendo.

Quando inizi a piegare le regole e fare eccezioni per quale tipo di orario di lavoro dovrebbe essere pagato e quale dovrebbe essere gratuito, può essere facile eventualmente trarne vantaggio. Il tempo è la metrica più semplice da utilizzare per il pagamento. Ti libera da molte responsabilità complesse, che potrebbero sembrare irresponsabili, ma ti protegge dall'essere trascinato e dal fatto che l'irresponsabilità del cliente porti a una riduzione degli stipendi.

Nel mio caso, sarebbe senza speranza se non potessi pagare per aver seguito la strada sbagliata, dato che lavoro spesso su cose del genere:

inserisci qui la descrizione dell'immagine

... cercando di battere un algoritmo di suddivisione Catmull-Clark di quasi 40 anni che è stato radicato nel settore e migliorato ripetutamente da aziende come Microsoft e Pixar cercando di fornire risultati più intuitivi pur essendo competitivo quanto queste enormi aziende velocità-saggio.

Il 95% delle volte, in questi casi, sto percorrendo la strada sbagliata, tornando costantemente alla lavagna dopo fallimento dopo fallimento dopo fallimento. Se non potessi pagare per i miei fallimenti, sarei già senzatetto. Vedo più della metà del mio lavoro come ricerca, quando nessuno ha mai provato queste cose prima d'ora, e non c'è modo di trovare l'approccio perfetto per affrontare una soluzione al primo tentativo (forse il 20 ° tentativo). Per me l'obiettivo non è mai stato quello di riuscire al primo tentativo, ma di fallire il prima possibile, con ogni fallimento dopo fallimento che fornisce alcuni indizi su quale potrebbe essere quella soluzione corretta, che potrebbe effettivamente essere in grado di cambiare il mondo.

Non tutti potrebbero lavorare in un'area così ad alta intensità di ricerca e sviluppo in cui i clienti vogliono e si aspettano che tu possa battere le tecniche più consolidate là fuori semplicemente perché stai iniziando un nuovo progetto, ma per me la programmazione non è mai abbastanza ordinaria, non importa come una soluzione semplice e consolidata è. Il modo in cui progettate e integrate le parti sarà ancora unico, sempre una qualche forma d'arte in sé che produce pro e contro unici, non meccanici, non perfettamente scientifici, altrimenti i robot potrebbero farlo. Quindi penso che inevitabilmente dovremo sempre pagare per percorrere alcune strade sbagliate qua e là, altrimenti potremmo trarre profitto solo dal lavoro più ordinario che abbiamo già fatto cento volte per il quale applichiamo esattamente lo stesso soluzione ogni volta, nel qual caso dovremmo pagare per premere il pulsante copia e incolla.

imprevedibilità

Un'altra cosa è che la programmazione è sempre dura, imprevedibile, mai del tutto ordinaria. Non è come la consegna della pizza che è routinaria, dove si può spiegare tutto tranne qualcosa come un incidente d'auto (purtroppo una volta ho lavorato sotto un capo che ha equiparato le stime del programmatore alle stime della consegna della pizza e ho pensato che l'unico lavoro che stavamo effettivamente facendo fosse scrivere) . Sta imparando sul sito, sempre - non riesco a immaginare che diventerà mai completamente di routine a meno che qualcuno in realtà non mi abbia pagato ripetutamente per implementarlo più e più volte. Ci sarà sempre qualche sperimentazione e apprendimento in corso lì, e finché non è eccessivo, non c'è bisogno di sentirsi in colpa per questo.

Ho spesso sognato di diventare un contadino o qualcosa del genere solo per poter trovare molti più movimenti di routine nel mio lavoro, non sempre spingendo i confini delle mie conoscenze esistenti. Invece provo a compensare rendendo la mia vita fuori dal lavoro il più normale e il più banale possibile, per aggiungere un po 'di prevedibilità e movimenti di routine da qualche parte per motivi di sanità mentale, il che mi rende un annoiato tra le persone che vogliono trovare eccitazione nelle loro vite al di fuori di lavoro - ne trovo abbastanza al lavoro.

Sta parlando di imparare cose nuove, non di lavorare sulla soluzione sbagliata.

Lavorare su una soluzione sbagliata significa imparare cose nuove, no? Sapevi che era una soluzione sbagliata quando hai iniziato, o hai continuato a lavorarci costantemente anche dopo aver saputo che era irrimediabilmente sbagliato? Spero non sia quest'ultimo. Spesso il processo di apprendimento avviene attraverso errori. È il miglior insegnante. La strategia più efficace che ho trovato è semplicemente commettere errori il più presto possibile, per scoprire che sono, in effetti, errori di progettazione il più presto possibile prima di impegnare tutto per loro e sposare tali soluzioni, poiché l'unica costante che posso contare e prevedere con quasi il 100% di certezza è che verranno commessi errori. Sono costosi solo se vengono scoperti molto tardi.


0

Dipende molto da come hai proposto il progetto e da come il progetto è fatturabile.

Ad esempio, se si tratta di un contratto basato su risultati finali, tutte le ore indipendentemente dovrebbero essere tracciate verso il progetto, anche se fosse per l'apprendimento di qualcosa di nuovo.

Se è un contratto basato su tempo e materiali, devi essere molto più sensibile a questo. Ad esempio, se ci si trova nel contesto del problema e si verificano problemi, dovrebbe essere fatturabile. Un esempio di questo è se stai imparando un'API legacy o un po 'di codice e stai cercando di farlo funzionare con il tuo codice.

Tuttavia, se tieni tracciato lateralmente nel tentativo di fare qualcosa o vuoi semplicemente imparare a farlo in un modo nuovo, allora fatturerei solo il tempo impiegato per implementare la soluzione effettiva e non il tempo che ho impiegato per impararlo.

Non sono d'accordo con Lunivore, che ci pagano per imparare le cose. Ci pagano grazie alla nostra esperienza e al fatto che la maggior parte delle volte dovremmo sapere come farlo già. Ci pagano per l'implementazione.

In breve, se la tua stima iniziale non includeva il tempo impiegato per imparare il problema, probabilmente non dovresti fatturarlo. Calcola come esperienza di apprendimento e sappi che la prossima volta non avrai questo ritardo.

Modifica: dal momento che hai specificato in seguito che non vi era alcuna stima, certamente non includerei quel tempo se pensi che questo sarà un client di ripetizione. Fornirei sempre una stima anticipata in futuro.


-1

Per ovviare a questo, immagino che cosa penso sarebbe un brutto caso e cito basandomi su un orario su ciò che penso dovrebbe prendere con un preventivo massimo fissato dal caso "cattivo". In questo modo siamo entrambi vincitori.


Non mi piace molto, perché il cliente perde sempre, nel caso in cui non sia un caso "negativo".
Lea Verou,

c'è una differenza tra caso "cattivo" e caso "peggiore". Se è il caso peggiore, prendo la perdita.
Dave

Hmm, buon punto. Ma comunque, se fosse un caso "buono"?
Lea Verou,

allora è a ore. Ti addebiterò x importo all'ora fino a h ore.
Dave
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.