Sé que un contratista generalmente es dueño del código que se desarrolla hasta el pago final del cliente. Si se utiliza GitHub, ¿significa esto que el contratista debe pagar por un repositorio privado en GitHub, trabajar en el proyecto desde su cuenta, y luego transferir la propiedad del repositorio una vez que se reciba el pago final?
Respuestas
¿Demasiados anuncios?Hay un par de razones por las que no recomendaría el enfoque que usted está considerando:
- En muchos casos, el cliente espera que colabores con sus propios empleados mientras trabajas. Incluso es posible que tengas que trabajar en un repo que ellos ya controlan. Aunque parece que no estás tratando con eso aquí, ya que estos escenarios son comunes, deberías tener una forma de trabajar que se adapte a ellos.
- Tendrá mucho más éxito como consultor si consigue establecer relaciones basadas en la confianza y no en la desconfianza. Mantener la repoblación para ti puede proporcionarte la palanca para asegurar ese pago final, pero no crea la "calidez" que te conseguirá futuros trabajos, recomendaciones, etc. (Véase la referencia más abajo.)
En su lugar, yo sugeriría adoptar la postura de que el cliente es el dueño del código desde el primer día, y asegurarse de que tiene visibilidad, acceso e incluso la capacidad de echarte cuando ellos quiere hacerlo. La idea es que sea fácil de despedir. (De nuevo, véase la referencia más abajo).
Entonces, haz otras cosas para aumentar las posibilidades de que te paguen:
- Bill, de forma incremental.
- Demuestre su trabajo con regularidad para que, si hay problemas, los detecte a tiempo.
- Cobra lo suficiente como para que, si el cliente te estafa en el último pago, puedas sobrevivir.
- Si el cliente es pequeño y no te sientes seguro de que te van a pagar, puedes pedir un anticipo razonable. (Los clientes más grandes no suelen hacer esto, simplemente porque no deberías preocuparte de que un cliente grande no pague).
Por último, en relación con los puntos anteriores (incluida la idea de la "calidez", la idea de ser fácil de despedir, etc.), no puedo dejar de recomendar este artículo:
Estoy de acuerdo con @willie. Creo que todos esos puntos son válidos, pero también creo que es razonable mantener cierto control sobre el producto del trabajo. Esto también debería estar claramente indicado en el contrato.
Hice un trabajo que estaba atrasado en el pago y me quemé. Mi siguiente contrato establecía claramente los puntos de pago. 1/3 por adelantado, 1/3 en la demostración beta, 1/3 en la entrega final.
Mi contrato establecía claramente los resultados y la forma en que se producirían. En realidad, no establecí qué tecnologías utilizaría para el control del código fuente, sólo que entregaría el acceso completo al código fuente tras la aceptación final y el pago.
Si el cliente está muy preocupado por el acceso a los servidores y el acceso al código fuente y quiere hacer pagos de retroceso, estas deberían ser banderas rojas sobre un cliente que probablemente lo acuse.
Si estás haciendo algún trabajo que estará a disposición del cliente (o de los empleados del cliente) entonces podrías considerar no hacer NINGÚN trabajo a menos que recibas un depósito como garantía de que el cliente no desaparezca con tu trabajo-producto. (esto ocurre todos los días)
Si vas a empezar un proyecto de cuatro semanas, pide un depósito para la primera semana y factura semanalmente. No empieces la segunda semana hasta que te hayan pagado por ella. Esto minimiza el riesgo para ti.
Está perfectamente bien explicar a un cliente que parte de su práctica empresarial incluye minimizar el riesgo para usted. No tienes que ser un imbécil al respecto y declarar esto por adelantado te da una plataforma con la que comprometerte, según lo que sientas que este cliente va a hacer (en términos de pagar tus facturas) a largo plazo.
En general, no hay que ir con la vista gorda. No todo el mundo es honesto. Mantén tu repo de Github en privado y si el cliente pide indagar en él, asegúrate de que primero cambie algo de dinero.