Sin reaccion

Supongamos el siguiente caso:

Un programador termina un desarrollo. El responsable evalue al desarrollo y encuentra varios fallos. Se los indica al programador. El programador los soluciona. El responsable vuelve a evaluar los cambios pero sigue viendo el fallo. Se lo dice al programador. El programador indica al responsable que ya esta solucionado.

Lo normal es que el responsable ya no compruebe mas resultado y se fie del programador (no es lo mas correcto pero no se suele tener mas tiempo en el proyecto para mas).

Al tiempo, el evaluador (o otro miembro del equipo del proyecto) sigue encontrado fallos ya detectados y que el responsable ya le indico al programador que lo solucionara.

¿Que se ha hecho mal? Hay muchas cosas (que el responsable pruebe hasta que no vea fallos, fases de pruebas, etc..) que se puede hacer pero normalmente no hay tiempo para hacerlo por lo que lo unico que queda es FIARTE de que el programador lo va a hacer correctamente tras una (o como mucho dos) evaluación.

¿Que ha pasado? Factores a tener en cuenta:

La frustración que produce la tarea. Hacer codigo nuevo gusta, volver a un codigo que el programador creia terminado y ajustarlo no gusta.

Desconocimiento funcional de lo que se tiene que hacer.

Falta de responsabilidad con lo desarrollado. Un programador lo que quiere es terminar lo mas rapido posible y luego si hay un fallo pues intentar justificarlo con que es un fallo del grupo.

¿Que hacer para paliar estos factores?

Evaluar mientras el codigo sea nuevo.

Antes de picar nada de codigo, se debe asegurar que los programadores saben lo que tiene hacer correctamente y cual es la solucion propuesta

Suena horrible pero la solución es ser puñetero y quisquillos. Hay que mirar codigo, explicar porque ser ha hecho esto asi o asa y criticar. Con mano izquierda pero hay que ser puñetero que se justifiquen los desarrollos. Asi no solo se consigue mas calidad, se consigue que el programador sienta una relación mas estrecha con lo que ha programado.