Nadie quiere realmente reducir la calidad de los productos, sino su coste. Habitualmente, sin embargo, el significado es el mismo. Los pasos que se dan para entregar el producto en menos tiempo implican menor calidad. A menudo son los usuarios finales quienes consienten una menor calidad a cambio de una entrega en menos tiempo y con menos coste.
Pero estas concesiones pueden ser muy dolorosas para los programadores. Su autoestima y disfrute del trabajo salen perjudicados ante la necesidad de construir un producto de una calidad claramente inferior a la que son capaces.
Otro daño colateral de la reducción de la calidad es la identificación con el equipo. Los compañeros que saben que están desarrollando un producto malo ni siquiera quieren mirarse a los ojos. No hay sensación de logro conjunto para ellos. Saben que se sentirán mejor cuando acaben. Al final del proyecto, invertirán todo su esfuerzo en separarse y buscar algo mejor.
Todos los miembros del equipo entienden que la calidad del trabajo es importante para la organización, pero los equipos cohesionados adoptan unos niveles de calidad superiores para distinguirse. Sin este signo de distinción, el grupo es sólo un grupo, nunca un verdadero equipo.
Este texto se ha traducido del libro:
Peopleware: Productive Projects and Teams
Tom DeMarco & Timothy Lister. Dorset House Publishing, 1998
No hay comentarios:
Publicar un comentario