¿Se pueden facturar los errores al crear software?

Depende.
Si estaba trabajando en un proyecto de presupuesto fijo y durante los ciclos de control de calidad o después de terminar se encontraron errores en el proyecto, tendría que corregirlos sin cobrar un centavo. En nuestros proyectos, generalmente incluimos alrededor de 3 meses de garantía para los errores que son nuestra culpa, siempre que el código no haya sido tocado por nadie más.

Ahora, para un proyecto basado en la hora, las cosas podrían ser diferentes. Por ejemplo, un caso típico es cuando está trabajando con contacto constante con su cliente, él es el que sigue dictando el flujo del proyecto qué características se deben agregar cada semana / mes. Si él te dice que trabajes en una función durante una semana y sabes que se necesitarían 2 para que funcione a la perfección y aún así insistió en hacerlo en ese momento porque tiene otras prioridades.
Cuando llegue el momento de probar la aplicación más tarde, probablemente habrá errores. DEBERÍA pagar para arreglar eso, ya que fueron errores introducidos al no seguir su consejo profesional de dedicar más tiempo a trabajar en eso.

Cualquiera sea el caso, esta es un área gris y habrá muchas opiniones diferentes. Simplemente se reduce a cuál es su relación con el cliente y cómo quiere que sea. Tenga en cuenta que una vez que comience a corregir un error de forma gratuita, esperará que los otros 99 también se solucionen de forma gratuita, aunque no sean su culpa.

Pablo Ruiz tiene razón: depende. Es un problema de contrato. Esto debe ser resuelto de antemano y firmado por ambas partes. ¡Bienvenido al negocio del desarrollo de software personalizado! Se trata tanto del negocio como del desarrollo de software.

Hay muchos modelos que puede usar para un contrato. Describiré brevemente algunos de ellos a continuación. Tenga en cuenta que están algo idealizados. Siempre debe ser un poco flexible al tratar con clientes para ganar buena voluntad, pero no debe permitir que los clientes se aprovechen de usted. Debe descubrir qué funciona mejor para usted y para sus diversos clientes, no solo para los gerentes de proyecto, sino también para el departamento de compras.

Tiempo y materiales: también conocido como “T&M”. Esto es estrictamente por hora. Están pagando por su trabajo, no por el producto terminado. Esperan que le cobren la tarifa por hora más baja. Les debes tu mejor esfuerzo durante el tiempo que contratan. No les debe correcciones de errores. T&M tiene el menor riesgo para usted y, por lo tanto, el menor potencial de recompensa. Observo que en su pregunta se identifica como una empresa de consultoría, pero hay algunos que dirán que si hace estrictamente T&M, es una empresa contratante, no una empresa de consultoría. (No estoy completamente de acuerdo con eso, pero es una opinión bastante extendida).

T&M plus Retainer / Garantía : Usted cobra por hora a su tarifa más baja. Están pagando por la mano de obra, no por el producto, pero usted acepta de antemano un bloque adicional de horas de retención que pagan más allá de las horas reales del proyecto. Factura las horas reales más la retención al finalizar el proyecto. Si hay errores, los arregla y carga las horas contra el retenedor. En cambio, si quieren que trabaje en otros proyectos, puede dedicarle cualquier hora restante al retenedor. Puede poner un límite de tiempo al retenedor, por ejemplo, un año. Si no usan las horas de retención, no recuperan el dinero.

Precio fijo Te dan requisitos. Están pagando por un producto terminado. Les deberá todas las correcciones de errores por un período de tiempo después de la entrega. Entonces, trabajando de forma gratuita en este punto, escribe una respuesta pidiendo aclaraciones. Cuando esté satisfecho de que han definido el proyecto lo suficientemente bien, les da una oferta. La oferta contiene la reexpresión de los requisitos y su precio. Para calcular el precio, calcula las horas y utiliza una tarifa por hora significativamente más alta de la que utilizaría para que T&M presente la cotización. Qué tan significativamente más alto depende de usted. Estás tomando muchos riesgos y estás pendiente de las correcciones de errores, ¡así que no te rebajes! El contrato debe especificar un período de tiempo corto pero razonable para que el cliente realice las pruebas de aceptación, y un período de tiempo para que usted entregue todos los errores encontrados durante la prueba de aceptación.

Precio fijo + Garantía Igual que el anterior, pero un precio más alto porque el cliente desea corregir errores durante un período de tiempo incluso después del breve pero razonable período de aceptación.

Precio fijo híbrido + órdenes de cambio por hora A veces, tanto usted como el cliente saben que los requisitos van a tener cierta ambigüedad en ellos, sin importar cuántas rondas de aclaración atraviesen. Por lo tanto, acepta de antemano una tarifa por hora para cualquier trabajo que resulte de factores desconocidos al momento del contrato. Además de la reexpresión de los requisitos, su oferta debe contener una lista de suposiciones que está haciendo, una pregunta abierta conocida, posibles direcciones alternativas, etc. Todavía debe haber un período de aceptación, y puede haber un período de garantía además de eso, así que aún asumes la responsabilidad de los errores. Pero te estás protegiendo de tener que trabajar gratis en muchas cosas que no son errores. (Siendo realistas, siempre se reduce a una negociación, pero escribir el concepto de órdenes de cambio en el contrato y escribir la mayor cantidad posible de problemas le brinda una mejor posición de negociación).

Híbrido T&M + Precio fijo Si el cliente no es capaz de cumplir con los requisitos que son lo suficientemente buenos, incluso después de un par de rondas de aclaraciones, es posible que desee ofrecer trabajar por hora con ellos en el desarrollo de los requisitos. Una vez hecho esto, prepara su oferta igual que arriba. Tienen derecho a abrirlo para otros postores. No te importa, porque te han pagado.

T&M pero no exceder He guardado esto para el final porque es el tipo de contrato menos favorable para usted. El cliente dice: “Quiero pagarle por hora a su tarifa más baja posible, pero realmente no estoy pagando por hora. Estoy pagando por el proyecto terminado y ya he decidido cuánto debería costar. No le pagaré más que eso, pero si le toma menos horas, le pagaré menos. Quiero que absorba todo el riesgo en esto “. Huya de esto cuando los clientes lo sugieran. Si realmente quiere el trabajo, puede intentar contrarrestarlo con una oferta de precio fijo, pero honestamente debe pensar que puede hacer el trabajo y respaldarlo por menos que el número No exceder del cliente. Y recuerde: debe usar su tarifa por hora más alta para su estimación de su oferta sobre una base de Precio Fijo porque es usted quien absorbe todo el riesgo. El cliente lo deja muy claro si está sugiriendo este modelo. Desafortunadamente, los departamentos de compras adoran este modelo.

Los errores (errores) son una parte regular de la vida del proyecto. Por lo general, los dividimos en categorías y discutimos con el cliente cómo tratarlos.

Los errores determinados en los entregables o entregables parciales bajo revisión se dividirán en las siguientes categorías de error:

Categoría de error 1 : como resultado del error, no se puede utilizar el sistema en su totalidad o parte del sistema que se está revisando.

Categoría de error 2 : el error causa restricciones sustanciales en el uso de funciones importantes, que no pueden eludirse con medidas adecuadas durante un tiempo razonable desde el punto de vista del Cliente.

Categoría de error 3 : todos los demás errores.

El cliente solo tendrá derecho a rechazar su aceptación como resultado de errores en las categorías de error 1 y 2. Los errores de la categoría 3 no impedirán la aceptación de los entregables, pero se corregirán si es posible.

Ciertamente, en términos de nuestra reputación, estamos tratando de evitar o minimizar su número y, por supuesto, estamos haciendo todo lo posible para evitar las categorías 1 y 2, pero la categoría 3 siempre se factura.

Además, me gustaría señalar que a menudo las características, mejoras y solicitudes de cambio también se llaman error.

No, los errores de software no son facturables. El software es como cualquier otra industria. Si el error es de la compañía que crea el producto, entonces (como regla general) debe estar cubierto por la garantía. Si bien las garantías en sí mismas no necesariamente existen en el desarrollo de software, rechazar a los clientes cuando se dan cuenta de que el software que construyó su empresa es defectuoso es una forma muy rápida de ganar reputación negativa en la industria.

Por lo tanto, como regla general, si un cliente ordena y paga un proyecto que crea su empresa y sus desarrolladores cometen errores y envían un código defectuoso, entonces es responsabilidad de la empresa corregir esos errores para el cliente. A los clientes nunca se les debe facturar por los errores que usted mismo comete.

Si el error fue causado por el cliente, como cuando el software se usó contra la funcionalidad prevista o si el cliente mismo lo modificó de alguna manera (como cuando el cliente también obtiene el código fuente de un sitio web, por ejemplo), se corrige Estos errores son facturables.

Lo que la mayoría de las empresas hacen es que cuando llega un nuevo proyecto, asignan un amortiguador específico en el presupuesto por exactamente esas razones. Este presupuesto nunca se muestra al cliente, pero es completamente interno. Entonces, si un proyecto es pequeño y se factura al cliente por 8 horas de trabajo, entonces internamente podría haber un buffer de 2-3 horas para varias correcciones de errores que podrían ocurrir después del envío.

Algunas compañías reducen este búfer al mínimo y no lo usan en absoluto, lo que significa que si el código tiene errores, la compañía trabajará con pérdidas cuando los arregle. Pero incluso entonces, es responsabilidad de la empresa corregir el error, ya que el cliente nunca pagó por un producto roto.

Si comienza a facturar a sus clientes por los errores que usted mismo comete, entonces no solo perderá a sus clientes tarde o temprano, sino que también ganará mucha reputación negativa.

Espero que eso ayude.

Según yo, los errores son parte de cualquier software. Si no obtenemos los errores en nuestro software, entonces no podemos juzgar que estamos en el camino correcto. Entonces, si algún cliente dice que no pagará por los errores, entonces será bueno sugerirle que esto puede funcionar de acuerdo con los requisitos. Una vez, un ingeniero de software habitual pirateó Yahoo por un día. Fue atrapado por las autoridades en dos días. Después de eso, Yahoo le ofreció un trabajo en su organización porque inspeccionó el error en el sitio web. Así que creo que si no hay errores, entonces no podemos decir que el software está a la altura.

More Interesting

¿Los lenguajes de programación funcional se entienden mejor y es más probable que los usen personas con conocimientos de matemáticas?

¿Quiénes son los mejores desarrolladores de aplicaciones para niños?

¿Cuál es el mejor plan de bonificación para desarrolladores de software?

¿Por qué Blender es mucho mejor que otro software de código abierto?

Para un joven estudiante de CS, ¿valdría la pena invertir tiempo en aprender Emacs y / o Vim, o debería apegarme a Sublime Text o Atom?

Además de OOP y la estructura y algoritmo de datos, ¿qué fundamentos de las ciencias de la computación deben poseer todos los desarrolladores de software (por ejemplo, compiladores)?

¿Por qué es que la industria no ha adoptado un sistema de aprendizaje / oficial de desarrollo de software frente al método clásico de obtener una licenciatura y obtener entre 1 y 3 pasantías?

¿Cuál es el proceso de desarrollo de un software ERP?

¿Cómo pueden los desarrolladores de software comenzar una empresa de consultoría de nicho dirigida a la industria de la salud?

¿Puede un desarrollador de software entrar en un campo relacionado con negocios o comercio en la misma compañía?

¿Cuáles son las mejores herramientas de colaboración para el desarrollo de software disponibles y asequibles?

¿Qué habilidades les faltan a los desarrolladores de software?

¿Por qué algunos desarrolladores dicen que no son TI?

Cómo desarrollar aplicaciones en una entrevista para un desarrollador de software

¿Cómo cambio mi carrera de desarrollador de software a arquitecto de empresa? ¿Qué habilidades debo aprender?