Contratista enfrentado a error de alcance: ¿debo cumplir con ninguna, algunas o todas las solicitudes de los clientes?

Soy un contratista en un proyecto de desarrollo de software que es un poco una pesadilla y sufre de Scope Creep .

Antecedentes:
asumí un proyecto para desarrollar una aplicación web para un cliente. Debía trabajar con el desarrollador, un empleado del cliente, que pensé que era un desarrollador experimentado pero que resultó tener un conocimiento muy limitado del desarrollo web. El acuerdo verbal fue que el otro desarrollador haría todo el front-end (HTML, CSS, JavaScript). Mis errores incluyen (pero no se limitan a);

  • aceptar un cronograma de proyecto acelerado (dije 12 semanas pero me redujeron a 4 semanas),
  • precio fijo del proyecto, pensando que el otro desarrollador podría hacer su parte
  • aceptar un proyecto sin hacerles definir claramente todas sus necesidades (animaciones, integraciones webgl, etc.).

Han pasado 6 semanas y he implementado las funciones descritas en el contrato (5 plantillas, función de audio, publicaciones personalizadas, integración de campos personalizados).

Los problemas:

  • El cliente sigue agregando más solicitudes. Él las considera expansiones/alteraciones de las características que acepté hacer en el contrato pero, de hecho, estos cambios son cambios significativos que consumen mucho tiempo.
  • El desarrollador introduce errores.
  • El desarrollador debe mantener el proyecto después de mi salida, pero no tiene las habilidades ni la experiencia para implementarlo.
  • He tratado de entrenarlo en el despliegue. Actualmente tiene un problema en el que no puede compilar el proyecto en modo de producción, pero funciona bien para mí en 2 computadoras y sistemas operativos diferentes. No puede arreglarlo, por lo que tanto él como el cliente piensan que es la configuración de mi proyecto.

Lo que quiero hacer:
En este punto quiero dejarlos con el proyecto como está. No es agradable, pero creo que he implementado las funciones descritas en el contrato. Facturé al cliente en 2 cuotas, el 50% a las 2 semanas (que ha sido pagado) y otro 50% a las 3 semanas (todavía no pagado). Estoy dispuesto a renunciar a la segunda entrega, y espero que eso evite las acciones legales a pesar de que mi reputación podría verse afectada.

¿Qué acciones tengo disponibles para mí? ¿Debo o estoy obligado a solucionar el problema del desarrollador junior? Si el junior no puede arreglarlo, el cliente no puede mantener/implementar el proyecto.

¿Debo decir que no a realizar soporte técnico para el desarrollador? ¿Debo aceptar hacer algunos de los cambios que el cliente desea? ¿Debo decir que no a todos ellos?

¿El acuerdo es sólo verbal? Tenga en cuenta que las consecuencias legales podrían responderse mejor en otra comunidad de Exchange
@MrRipstein gracias por tu comentario. Estoy buscando consejos éticos y prácticos más que consejos legales. Hay un contrato firmado por escrito, con una tarifa total especificada, una lista de características/artículos que se producirán (vagamente indicados), fecha de vencimiento del proyecto (ya vencida).
Su pregunta puede estar más relacionada con el tema (y obtener mejores respuestas) en freelancing.stackexchange.com
¿El contrato tiene un esquema de los entregables? Y ningún "Tú me construirás un sitio web" no cuenta como uno porque los contenidos del sitio son ambiguos.
@ValarMorghulis Sí, tiene entregas en la lista. Cosas como A responsive website, Should be a progressive web app, A case study page that details X vision and approach, The ability for non-technical users to create custom posts, Compatibility across IE11+, FF (last 4 versions).... Hay 14 entregables/características enumeradas.
@mk11 parece que su lista de entregables sigue siendo demasiado ambigua. ¿Qué significa 'un sitio web receptivo'? ¿Totalmente receptivo para cualquier resolución o hasta cierto límite? Es solo un ejemplo, pero cuando realiza un proyecto de precio fijo, debe ser increíblemente específico sobre lo que va a entregar.
¿Actualmente está haciendo un trabajo fuera del alcance de este contrato y no le pagan por ello? No hagas eso.
"Dije 12 semanas pero me redujeron a 4 semanas" - wow.

Respuestas (2)

Uno de mis mentores tenía una larga carrera en contratación y me explicó algunas pautas generales que funcionaron bien a lo largo de su carrera y en mi experiencia (aunque mi experiencia en contratación es limitada):

  • Haga todo lo posible para obtener requisitos claros. Verifíquelos dos y tres veces de antemano.
  • Cada vez, a menos que tome menos de 5 minutos, que se le pida que haga algo que no está en el contrato, debe llamarlo, incluso si lo va a hacer. La satisfacción del cliente es enorme, y si le va a dar algo a alguien, debe asegurarse de que sepa que le está haciendo un favor y que le permitirá usar esto como palanca en otras negociaciones. Cuando vaya a hacerlo, use un lenguaje como: "esto no era parte de nuestro acuerdo original, pero tal vez pueda ayudar".
  • Evite hacer cualquier trabajo significativo que no esté específicamente descrito en el acuerdo original. Si das cosas gratis a la gente, te valorarán menos (no tiene sentido, pero es verdad).
  • No seas un presa fácil. Si ha cumplido su contrato, exija el pago completo. No ofrezcas perder el 50% del dinero que te debe porque su desarrollador es incompetente y quiere cosas gratis.

Para aplicar específicamente estos principios, debe:

  • Explique que ha terminado todas las partes del proyecto estipuladas en el contrato.
  • Explique que la persona que trabaja de su lado no ha cumplido su parte del contrato.
  • Enumere todos y cada uno de los trabajos que haya realizado que se suponía que debía realizar su contraparte en su organización y todos y cada uno de los trabajos que haya realizado más allá del contrato.
  • Exija el pago completo antes de continuar con el trabajo en el proyecto.
Solo un comentario aparte: un jefe de camiones de producción de video que conocía tenía un sistema. Tenía cuatro tarjetas azules plastificadas con "Por cierto" impreso en ellas en negrita grande. Cuando park & ​​power estaba terminado, le entregaba las tarjetas al productor. Él les dijo: "Obtienen 4 By the Way's por las cosas que olvidaron poner en los requisitos. No me quejaré en absoluto, pero cada una les cuesta una tarjeta. Cuando se acaban sus tarjetas, están acabados". Resolvió muchos problemas y estableció expectativas claras desde el principio.
Dudaría en hacer tarjetas, ya que algunas cosas que olvida podrían explotar el alcance de un proyecto, al menos para CS: "por cierto, necesito que esto se integre con una base de datos no estándar". Pero me gusta que claramente establece expectativas y llama cada vez que se agrega algo nuevo.
No estoy tratando de sugerir esto como un plan específico. Estoy tratando de decir que si establece expectativas desde el principio, todos serán más felices. Debe permitir cierta flexibilidad, pero debe mantenerla manejable.

IANAL , pero:

Si ha completado lo que se describe en el contrato, entonces ha completado el contrato. Lo que el cliente quiera más allá de eso es algo completamente diferente. Si cree honestamente que ha cumplido con su acuerdo contractual con el cliente, me retiraría e incluso consideraría ir tras ellos por la última cuota.

Sin embargo, SI cree que todavía hay partes del contrato pendientes, debe arreglarlas lo más rápido posible y salir.

No veo nada poco ético en dejar un proyecto terminado solo porque el cliente quiere más. Deberían saber mejor entonces hacer un contrato que no era del todo lo que querían. Así es la vida, obtuvieron lo que acordaron.