¿Cuál es la mejor manera de evitar un conflicto cerca del final de un contrato independiente de desarrollo de software?

Al frente, no soy un programador. Mi interés está en la psicología, particularmente en cómo nosotros, como seres humanos, damos forma a nuestras perspectivas. Voy a recomendar el libro de Kahneman “Pensando: rápido y lento” y, francamente, casi todo lo que ha escrito. Esto no es solo para psicólogos, sino que es fácilmente accesible para los laicos y es importante para comprender cómo nuestras mentes nos arruinan.

Un punto a considerar aquí al determinar los plazos es que las personas son idealistas, no en un sentido filosófico, sino en que tendemos a pensar lo más alto de nosotros mismos, particularmente cuando estamos acorralados, como ocurre a menudo cuando se determina un plazo. Inflamos nuestra importancia, nuestras habilidades y nuestra capacidad de ir sin dormir ni cuidar de nosotros mismos.

Para lidiar con esto, hay algunas cosas que hacer.

Uno, quita la presión. Haga la pregunta de la fecha límite como si estuviera considerando otra compañía o grupo con antecedentes similares, no el suyo propio.

Dos, junto con uno, realizan investigaciones en otros grupos con antecedentes similares o mejores, prestando atención a sus marcos de tiempo completados. Esto puede dar un punto de vista más objetivo y ayudar a informar la creación de opiniones cuando la discusión surge en su equipo.

Tres, divida los proyectos en partes más pequeñas, luego cree canales de comunicación para facilitar la combinación de piezas ya completadas en un todo más grande. Esto quita algo de presión y fomenta una mayor colaboración.

Como programador, creo que esto se debe principalmente a la comunicación.

  • ¿Está el trabajo al menos parcialmente terminado? Agile está destinado a fabricar productos en fases y, por fase, esa parte del producto debería estar trabajando por su cuenta.
  • ¿Por qué algo se retrasó? ¿De quién fue la responsabilidad de terminar eso a tiempo?
  • ¿Quién es el propietario del producto una vez finalizado el trabajo?

– Pagar por sprint, no por un producto completo.
– Asegúrese de que el desarrollador sepa que cada parte debe estar terminada y lista para su implementación.
– Tener una idea de por qué el desarrollador está pidiendo más tiempo y dinero. Si la información no es clara, debe comunicar sus deseos con anticipación y deben guiarle adecuadamente por qué no es posible lo que desea o por qué debería llevar más tiempo programar.
– Asegúrate de que el desarrollador asume su propia responsabilidad. No deberían pedirte que pagues más porque se equivocaron.
– Consigue un desarrollador diferente para terminar tu producto por ti, si no es satisfactorio. Esto no es ideal, pero el producto debe ser de su propiedad. Siéntete libre de hacer lo que quieras con él.

En general, creo que para evitar tener problemas al final, todo debe quedar claro de antemano.

Nunca cito ni ofrezco ofertas, solo trabajo por tiempo dedicado. De esa manera, nunca me siento agobiado si un proyecto demora mucho más de lo que se anticipó inicialmente y el cliente nunca se siente acosado si toma mucho menos tiempo de lo anticipado inicialmente.