¿Debería cobrar a los clientes las horas dedicadas a la vía incorrecta? [cerrado]

Asumí un pequeño desafío de CSS para resolver un cliente y me pagarán una tarifa por hora. Finalmente lo resolví, me llevó 5 horas, pero pasé aproximadamente el 25% del tiempo en la pista equivocada, probando una solución CSS3 que solo funcionaba en los navegadores recientes y finalmente descubrí que no es posible una recuperación a través de JS (como originalmente pensé). ¿Debo cobrarle al cliente ese 25%?

Más detalles: no proporcioné una estimación, me gustó el desafío per se, así que comencé a trabajar en él antes de dar una estimación (pero he trabajado con él antes, así que sé que no es una de esas personas que tienen expectativas poco realistas ) En el peor de los casos, habré pasado 5 horas sin pagar en un intrigante desafío CSS. Y daré la estimación más justa posible para los dos, ya que ya habré hecho el trabajo. :)

Editar: ¡Gracias a todos, desearía poder aceptar más de una respuesta! Terminé sin cobrarle por las horas adicionales (le facturé por 3 años y medio), pero las mencioné, para que sepa que trabajé más en eso de lo que le facturé. Tal vez por eso aceptó de inmediato la "estimación" (que en ese caso no era una estimación, de ahí las citas).

A menudo tengo tales situaciones cuando paso algunas horas haciendo algo, y luego me doy cuenta de que hay una solución de una línea más fácil, o que mi primera idea fue demasiado mala, etc.

En general, en esos casos, hago la diferencia entre tres situaciones:

• La solución recién descubierta no era obvia y / o un desarrollador promedio probablemente también estaría en el camino equivocado y / o el camino equivocado era un requisito previo para encontrar la solución final. En este caso, le cobro al cliente por el tiempo dedicado a la pista equivocada.

• La solución recién descubierta no era tan obvia, pero probablemente muchos desarrolladores promedio irían directamente de esta manera. En otras palabras, si pensara mejor antes de comenzar a escribir código, probablemente podría encontrar la solución final directamente, o tal vez no. En este caso, le cobro al cliente, pero reduzco el precio a la mitad o un porcentaje que parece el más adecuado.

• Obviamente, era demasiado estúpido, demasiado somnoliento o no pensaba en absoluto antes de comenzar a escribir código, ya que la solución final era extremadamente fácil de encontrar. En este caso, incluso si pasé dos días en el camino equivocado, es mi responsabilidad y el cliente no tiene que pagar por eso.

No creo que estuvieras en el camino equivocado. Codificó una solución, probó la solución (felicitaciones) y descubrió que no funcionaba como esperaba. Usted depuró la solución y luego hizo su corrección yendo en una dirección diferente.

En mi humilde opinión, ese no es el camino equivocado. Eso es desarrollo de software regular.

Si fuera usted, cobraría las 4 horas completas.

La mayoría de los programas que escribimos, estamos escribiendo porque una solución no está disponible de manera inmediata y fácil. Casi todo lo que hacemos implica aprender algo nuevo. El cliente no le estaba pagando por el producto. Te estaba pagando por aprender a construir el producto y por darte los resultados (y si él mismo lo llamó un "desafío", esperaba que aprendieras algo). Ver "Waltzing with Bears" de Tom de Marco y Timothy Lister - "Si un proyecto no tiene riesgos, no lo hagas".

Si desea reembolsar al cliente correctamente, envíele su solución junto con los detalles de las soluciones que no funcionaron, para que pueda pasarlas a cualquier otro personal que contrate y ayudarlos a tomarse menos tiempo también.

Depende de usted negociar si él piensa que está pagando demasiado. Ciertamente, esperaría que pague por cualquier aprendizaje que no sea fácilmente utilizable en otros lugares.

A veces, resolver un problema implica eliminar las soluciones subóptimas de un conjunto de opciones razonables. El proceso de eliminación es una de sus herramientas para resolver problemas; el cliente le está pagando por una solución y debe esperar que use cualquier herramienta a su disposición.

Sería un cliente irracional que espera que visualice instantáneamente la mejor solución: caminar directamente desde el resumen del proyecto hasta su teclado, donde emite un flujo de código rápido y óptimo sin retroceso. Lo que no quiere decir que no haya tales clientes. He tenido al cliente que llamó a mitad del proyecto para verificar que en realidad solo estaba pagando por "programación, no depuración". Y, por supuesto, hay clientes (o jefes) para quienes la programación es el acto físico de escribir.

Su callejón sin salida podría representar el dinero mejor gastado del cliente: otro desarrollador podría no haber sido tan minucioso como usted y haber ofrecido una solución más barata pero menos compatible que podría afectar en el futuro.

estas preguntas me vuelven loco ...

Si un mecánico o un abogado pasaron tiempo trabajando en su caso / problema, usted apuesta a su $ $$ que se le cobrará, incluso si pasaron tiempo en el camino equivocado

los programadores necesitan comenzar a valorar más su tiempo

Lo que hiciste fue perfectamente normal. Fred Brooks analiza este fenómeno en el capítulo "Plan para deshacerse de uno" de su libro seminal sobre ingeniería de software "The Mythical Man-Month".

Estabas trabajando en un contrato de tiempo y materiales; por lo tanto, debe cobrarle a su cliente todo el tiempo que pasó trabajando en el proyecto. Depende del cliente determinar si recibió el valor suficiente para su inversión.

Lo veo de esta manera: al final del día, es tu decisión lo que cobras. Hay muchas variables como cuán feliz quiere al cliente, la relación existente, sus habilidades de ventas, etc. Todos estamos familiarizados con ellas. Lo que finalmente está proporcionando al cliente, y lo que realmente quiere, es valor. ¿Qué valor le diste al cliente y cuál es la solución / entrega que le estás dando?

Puede llevarle 10 minutos resolver un problema, pero le tomó 10 años aprender a resolverlo. Eso merece ser considerado. Al mismo tiempo, algunos de nosotros consideramos la capacidad de aprender la compensación "en el trabajo". A menudo aprendo cosas que realmente están en la moneda del cliente. Considero que es una forma de compensación no monetaria.

También puede agregarlo a la factura, luego marcarlo como "descuento de cliente preferido" en la factura, no cobrar y generar buena voluntad. Hago eso de vez en cuando, lo que hace que el cliente se sienta bien.

Además, su pregunta de si hay desarrolladores que ganan miles de dólares al día, la respuesta es sí. Tú también deberías ser uno de ellos con tus habilidades. Prácticamente estoy allí, y no estoy cerca de estar en la misma liga contigo en CSS.

Eso depende del acuerdo original.

¿Dijiste que ibas a entregarlo hecho y listo? Entonces es mejor que cobre por todo el tiempo que pasó desarrollándolo. ¡Todo ello!

Si contrata a un abogado para argumentar un caso por usted, y ellos lo arruinan y pierden por usted, aún así paga su factura.

Así es como lo hacen todas las otras profesiones. No hay ninguna razón por la cual los programadores deberían hacer lo contrario.

Si el cliente piensa que pagó demasiado, no volverá a usted. Mantenerlos como clientes habituales es la única razón sensata para no facturar todas las horas trabajadas.

Si es un proyecto que tomé específicamente para que alguien me pagara, mientras me enseñaba algo de tecnología nueva, tiendo a hacerlo por menos de lo que normalmente facturaría el tiempo. Por otro lado, no puede ofertar demasiado bajo, o eso hará las cosas raras con ese cliente para siempre ("¡Oye, cuando hiciste esa cosa realmente genial, cobraste mucho menos que esto!") De lo contrario, no lo hago. No es el momento en que me equivoqué y terminó tardando demasiado.

Mi excepción a esta regla: si la razón por la que el problema tardó horas en solucionarse es porque el cliente me criticó por algo que había roto, le cobraré por todo.

Normalmente no cobraría si fue mi culpa descaradamente y simplemente estaba dando vueltas, pero no soy nada inteligente para los negocios. He descubierto que la mayoría de las personas inteligentes para los negocios aplican esta filosofía de que los clientes están pagando por su tiempo , y no simplemente un resultado final. En muchas ocasiones en mi carrera, en retrospectiva, lamenté no pensar de esta manera. Todo lo que pensaba era que el resultado final valía la pena, mi tiempo carecía de sentido a menos que mejorara el resultado final. Sin embargo, uno podría ser arrastrado y perder mucho tiempo como resultado de que los clientes cambien de opinión, de que los compañeros de trabajo causen errores que se le asignan y retrasen su trabajo, por ejemplo, y no solo porque necesita un poco más de investigación por adelantado para saber realmente lo que estabas haciendo.

Cuando comienzas a doblegar las reglas y hacer excepciones sobre el tipo de tiempo de trabajo que se debe pagar y el que debe ser gratuito, puede ser fácil aprovecharlo. El tiempo es la métrica más fácil de usar para el pago. Le libera de una gran cantidad de responsabilidades complejas, que pueden parecer irresponsables, pero lo protege de ser detenido y hacer que la irresponsabilidad del cliente provoque una reducción salarial.

En mi caso, sería inútil si no pudiera cobrar por seguir el camino equivocado, ya que a menudo trabajo en cosas como esta:

... tratando de vencer a un algoritmo de subdivisión Catmull-Clark de casi 40 años que se ha arraigado en la industria y mejorado en repetidas ocasiones por compañías como Microsoft y Pixar al tratar de proporcionar resultados más intuitivos sin dejar de ser tan competitivo como estas grandes compañías En cuanto a la velocidad.

El 95% del tiempo en tales casos, voy por el camino equivocado, constantemente volviendo a la pizarra después de una falla tras otra. Si no pudiera cobrar por mis fracasos, ya estaría sin hogar. Veo más de la mitad de mi trabajo como investigación, cuando nadie ha intentado estas cosas nunca antes, y no hay forma de que pueda encontrar el enfoque perfecto para abordar una solución en el primer intento (tal vez el vigésimo intento). Para mí, el objetivo nunca ha sido tener éxito en el primer intento, sino fracasar lo antes posible, y cada falla tras otra proporciona algunas pistas sobre cuál podría ser la solución correcta, que podría ser capaz de cambiar el mundo.

No todos podrían estar trabajando en un área tan intensiva en I + D donde los clientes quieren y esperan que superes las técnicas mejor establecidas simplemente porque estás comenzando un nuevo proyecto, pero para mí la programación nunca es del todo rutinaria, no importa cómo Una solución simple y establecida es. La forma en que diseñe e integre partes seguirá siendo única, siempre alguna forma de arte en sí misma que generará ventajas y desventajas únicas, no mecánicas, no perfectamente científicas, de lo contrario los robots podrían hacerlo. Así que creo que inevitablemente siempre tendremos que cobrar por tomar algunas rutas equivocadas aquí o allá, o de lo contrario solo podríamos beneficiarnos del trabajo más rutinario que ya hemos hecho cientos de veces para el cual aplicamos exactamente lo mismo solución cada vez, en cuyo caso estaríamos cobrando por presionar el botón copiar y pegar.

Imprevisibilidad

Otra cosa es que la programación siempre es difícil, impredecible, nunca del todo rutinaria. No es como la entrega de pizza, que es una rutina, en la que se puede tener en cuenta todo menos un accidente automovilístico. . Está aprendiendo en el sitio, siempre. No puedo imaginar que se vuelva completamente rutinaria a menos que alguien realmente me pague repetidamente para implementar una y otra vez. Siempre habrá algo de experimentación y aprendizaje allí, y mientras no sea excesivo, no hay necesidad de sentirse culpable por ello.

A menudo soñé con convertirme en agricultor o algo así para poder encontrar muchas más mociones de rutina en mi trabajo, no siempre empujando los límites de mi conocimiento existente. En cambio, trato de compensar haciendo que mi vida fuera del trabajo sea lo más rutinaria y mundana posible, para agregar algo de previsibilidad y movimientos rutinarios en algún lugar por el bien de la cordura, lo que me hace aburrir a las personas que desean encontrar emoción en sus vidas afuera de trabajo: encuentro bastante en el trabajo.

Está hablando de aprender cosas nuevas, no de trabajar en la solución incorrecta.

Trabajar en la solución incorrecta es aprender cosas nuevas, ¿no es así? ¿Sabía que era una solución incorrecta cuando comenzó, o siguió trabajando persistentemente incluso después de saber que era irremediablemente incorrecto? Ojalá no lo último. A menudo, el proceso de aprendizaje es a través de errores. Es el mejor maestro. La estrategia más efectiva que he encontrado es simplemente cometer errores lo antes posible, descubrir que, de hecho, son errores de diseño lo antes posible antes de comprometerles todo y unir esas soluciones, ya que la única constante que puedo contar Encender y predecir con casi un 100% de certeza es que se cometerán errores. Solo son caros si se descubren muy tarde.

Realmente depende de cómo propusiste el proyecto y de cómo se factura el proyecto.

Por ejemplo, si se trata de un contrato basado en entregables, todas las horas, independientemente de ello, deben ser rastreadas hacia el proyecto, incluso si fue para aprender algo nuevo.

Si es un contrato basado en el tiempo y los materiales, entonces debe ser mucho más sensible a esto. Por ejemplo, si está dentro del contexto del problema y tiene problemas, entonces debería ser facturable. Un ejemplo de esto es si está aprendiendo una API heredada o un bit de código y está intentando que funcione con su código.

Sin embargo, si te desvían tratando de hacer algo o simplemente quieres aprender cómo hacerlo de una manera nueva, entonces solo facturaría por el tiempo que tomó implementar la solución real, no el tiempo que tomé aprendiéndolo.

No estoy de acuerdo con Lunivore, que nos pagan por aprender cosas. Nos pagan por nuestra experiencia y porque la mayoría de las veces se supone que ya sabemos cómo hacerlo. Nos pagan por la implementación.

En resumen, si su estimación inicial no incluía el tiempo que tomó aprender el problema, entonces probablemente no deba facturarlo. Anótelo como una experiencia de aprendizaje y sepa que la próxima vez no tendrá ese retraso.

Editar: dado que especificó más tarde que no había una estimación, ciertamente no incluiría ese tiempo si cree que este será un cliente habitual. También siempre proporcionaría una estimación por adelantado en el futuro.

Para evitar esto, calculo lo que creo que sería un mal caso y cito basado en una hora en lo que creo que debería tomar con una cotización máxima establecida por el caso "malo". De esta manera, ambos somos ganadores.