Así que comencé a trabajar independientemente tanto en el desarrollo de escritorio / web como en este cliente que ya aceptó mi trabajo, y me pagó, siempre me responde cada vez que encuentra un error, etc. gratis. ¿Está bien o debería comenzar a cobrar una tarifa de soporte?
¿Cuál es la mejor manera de lidiar con las correcciones en un trabajo supuestamente aceptado y completado?
Respuestas:
Parte de su contrato debe describir las pruebas de aceptación, es decir, las pruebas que realizará el cliente y su solicitud debe aprobarlas para que se cumpla el contrato. Cualquier cosa que no esté cubierta por estas pruebas es responsabilidad del cliente. Cualquier cosa cubierta por ellos es tuya.
Debido a que no es posible (especialmente para un cliente no técnico) prever todos los problemas posibles, debe agregar a su contacto una cláusula que especifique un período, en el que solucionará cualquier problema nuevo como parte de un contrato. Después de eso, debe ofrecer solo soporte pagado.
fuente
Depende.
En primera instancia, debe pagar ya que se puede argumentar que el trabajo no está completo.
Más tarde, el cliente debe pagar por el soporte continuo.
Sin embargo, el problema radica en decidir dónde está el límite y qué constituye un error y qué es una nueva característica. Tener requisitos y / o pruebas de aceptación ayuda mucho a definir esto.
Que realmente necesita para conseguir estas cosas en su lugar antes de entregar el trabajo, pero si no es así entonces tal vez ahora es el momento por lo que dicen - "Voy a apoyar esto de forma gratuita para la próxima N días / semanas, pero después de eso nos Necesito discutir un contrato de soporte "(tenga en cuenta mi énfasis en" nosotros ").
Habiendo dicho todo eso, sin embargo, hay momentos en los que tendrá que corregir un error de forma gratuita y recibir el golpe. Si nada más construye buena voluntad.
fuente
Todas las respuestas dadas anteriormente son buenas. Sin embargo, agregaría algunos puntos para considerar:
¿El cliente es valioso para usted? A veces vale la pena recorrer algunos metros más para mantener contento a un cliente si siente que es valioso para usted y le traerá más trabajo en el futuro. Debe encontrar un equilibrio entre ser estricto y flexible, y esto puede diferir para cada cliente. No tiene sentido perder el trabajo futuro solo porque está convencido de que un error fácil de solucionar queda fuera de alcance. Por otro lado, no quieres dejar que el cliente te pase por encima. ¡Es un equilibrio delicado!
¿Es el error algo que fácilmente podría haberse perdido en las pruebas de usuario? Por ejemplo, tome un error relacionado con la fecha que solo entra en juego cuando se ingresa un año determinado (piense en el error Millennium, etc.). No se puede esperar razonablemente que un cliente detecte esto durante las pruebas, por lo tanto, es responsabilidad de usted solucionarlo.
fuente
Cuando trabajaba por cuenta propia, mi acuerdo básico con el cliente definía una condición llamada "aceptación", que era necesaria antes de poner el proyecto en vivo al público. En el momento de la aceptación, comenzó un período de 30 días que llamé "soporte operativo". Después de ese período de 30 días, el trabajo en curso en el proyecto era facturable por hora.
Si tiene una buena relación con este cliente, tenga una relación sincera con ellos acerca de cuán inviable es la situación actual para usted y proponga una tarifa por hora justa para el mantenimiento y soporte continuo. La gente a veces piensa que comprar software personalizado es como comprar un sándwich o algo así, una vez que está hecho, está hecho. Simplemente no es así.
fuente
En general, puede solicitar asistencia gratuita durante un número fijo de días después de entregar la aplicación. Ciertamente, un soporte gratuito de por vida no es posible / inaceptable.
Asegúrese de que el error generado sea un ERROR y no un cambio en la función existente. Por cualquier cambio de características, debe cobrar.
fuente
Si lo probó y lo firmó, podría argumentar que debería pagar.
Si se enorgullece y valora su trabajo, podría argumentar que corregiría el código. Aprenda de las experiencias y cree un mejor código la próxima vez, de manera más eficiente. O tenga en cuenta más ganancias para cubrir la corrección de errores.
Si el programa hace algo indeseable o inesperado dadas las entradas, entonces es un error y debe solucionarse.
Podría haber cotizado por adelantado la tarifa de soporte como un extra al trabajo de desarrollo inicial.
fuente
En su contrato, especifique una tarifa por hora y realice un seguimiento de su tiempo. Cuando le dé el precio a su cliente, especifique que se trata de una estimación y que el resultado real puede ser menor o mayor.
Mantenga al cliente actualizado sobre el progreso, y cuando inevitablemente haga sugerencias, simplemente puede decirle el tiempo que le llevará (si el cambio está fuera de las especificaciones originales) y él puede decidir si el cambio vale la pena. Por lo tanto, solo se agregarán los cambios importantes para él.
Yo personalmente cubriría los errores aceptables frente a los inaceptables (soporte pagado versus soporte gratuito) en el contrato, y de esa manera al menos tiene algo por escrito desde el principio. Sin duda se preguntará por qué debería necesitar esa cláusula, así que sea sincero y explique que si sale una nueva actualización del sistema operativo que rompe algo, eso no es soporte gratuito. Sin embargo, los errores en su código de acuerdo con la especificación original en las plataformas especificadas estarían cubiertos.
Sin embargo, debo mencionar que solo he realizado trabajos de TI independientes en lugar de programar. Esto podría asustar a los clientes, pero solo asegúrese de que su trabajo se venda solo, sea más profesional, extrovertido y útil que el resto, y sea sincero con sus razones para tener un contrato más estricto.
Además, un cliente que no aceptará esa cláusula es muy probablemente un mal cliente.
fuente