Es irónico que el camino de la mejora continua esté tan cerca del camino del estancamiento, del que lo separa apenas un cambio de perspectiva, cierta tendencia a asignar responsabilidad sobre problemas concretos a personas concretas con la vana esperanza de que desaparezcan unos con otros.
Si asumimos que inevitablemente y en toda actividad humana (no sólo en la programación) se cometen errores, produciéndose defectos en los productos resultantes, no nos extrañaría tanto encontrarlos ni en las tareas más simples ni en los productos de más alta calidad.
Cuando es necesario que un producto adquiera cierta calidad, deberíamos controlar el proceso y el resultado en busca de problemas más que esperar a que no se produzcan mágicamente -o por la simple respuesta a un reclamo más o menos imperativo-.
Y al momento de controlar, tendríamos que tener muy en claro que estamos controlando en busca de errores y no para calificar o evaluar la calidad del trabajo de una persona o de un equipo.
Esto es porque, dada la primera premisa, no tendría sentido preocuparse por quién comete un error o por qué ya que la respuesta es obvia: porque es un ser humano o producto de un ser humano. Deberíamos focalizarnos en dónde y cuándo y por qué no se ha detectado antes en caso de que hubiese sido posible.
Siguiendo esa línea llegaríamos a la conclusión de que la cuantía de los errores no tiene relación directa con la idoneidad (“el que hace se equivoca, y el que no, se calla la boca”) por lo que, consecuentemente, no se deberían tomar ni admitir represalias por ellos (aunque muchas veces es deber tolerarlas).
Una postura opuesta, por ejemplo la medición del desempeño a través de la cantidad de errores cometidos y registrados “con nombre y apellido” lleva a las personas a actuar a la defensiva, al temor a cometerlos o a ocultarlos una vez cometidos. Pero como son inevitables -y esto es un hecho- la única forma de no tener errores es no haciendo nada. Es decir que esta actitud nos lleva, inevitablemente, a la parálisis.
3 comentarios:
En efecto, cuando se intenta implantar un control de seguimiento sobre la calidad del software (o un sistema de gestión de la configuración, con todo lo que ello implica), existen reacciones opuestas entre las que se incluyen las de rechazo por el "control sobre los trabajadores y su labor", que no tienen cabida si pensamos en que lo que se busca es gestionar adecuadamente el software y su calidad durante todo el proceso de desarrollo, y no actuar como policías sancionadores.
Muy interesante el artículo.
Saludos.
¡Excelente reflexión! Una elevada forma de pensar que va más allá del simple desarrollo de un software.
Un saludo.
La verdad que sí. Una muy interesante reflexión.
En mi mundo en el que vivo hay una selva y pensar así, como en esta relfexión, es un árbol bañado por el sol de la mañana ¡frescura pura!
¡Un saludo!
Publicar un comentario