57. El costo del re-trabajo

EL COSTO DEL RE-TRABAJO SUELE permanecer oculto y en general se lo asignamos a factores externos:

• El usuario no entiende el producto, tenemos que cambiar cosas.
• El sponsor cambió los requerimientos, tenemos que agregar funcionalidad.
• No era lo que esperaban, hay que hacerlo de nuevo.
• El cliente no entendió, o el usuario no sabe lo que quiere, o el sponsor no se involucró lo suficiente, etc.

En el fondo, son evidencia de un proceso deficiente en la captura no sólo de los requerimientos, sino en la definición de los problemas de fondo:

• ¿Qué necesitan los usuarios?
• ¿Qué necesita el negocio?
• ¿Cuándo es necesario?
• ¿Cuál es el presupuesto?

En el desarrollo de software, hay algunas reglas que suele ser recomendable seguir:

• Haz todo lo posible para no escribir código.
• Entiende el problema completamente antes de escribir código.

¿Cómo podemos, entonces, enviar requerimientos a los equipos de construcción de software sin estar 100% seguros que es lo que el usuario realmente necesita, que favorece al negocio y que es acorde al tiempo y a los recursos disponibles?

Cada punto porcentual que restamos al nivel de certeza suma a la complejidad que transferimos a otros equipos.

Es decir, si estamos un 90% seguros de los requerimientos enviados a construir, el 10% restante es costo oculto que va a retornar en forma de re-trabajo. Tarde o temprano.

Dentro de este panorama, el re-trabajo no es el peor de los males. Hay un escenario peor, en donde el re-trabajo no es requerido no porque satisfagamos las necesidades de manera adecuada, sino porque nuestros usuarios decidieron abandonar el producto y no hacérnoslo saber.

Entonces, puedes considerar al re-trabajo como un indicador que anticipa un posible abandono de tus usuarios.

Aprovéchalo.