martes, 28 de noviembre de 2006

Gestión de culpas

Hay gente que considera que el desarrollo ha de responder a necesidades de las organizaciones. Esto puede no ser necesariamente verdadero, pero desde luego es irrelevante. El software se desarrolla en general porque a alguien se le ocurre.

Efectivamente, cuando a alguien se le ocurre la idea de que se desarrolle o modifique una aplicación, puede decidir no decírselo a nadie, lo cual suele ser la mejor idea. En ocasiones se le ocurre comentárselo a alguien, con lo que la idea comienza a propagarse hasta que algunas personas empiezan a emplear su tiempo (o dinero, prestigio, etc.) en hacerla realidad o utilizar el producto resultante.

El proceso es sencillo y se realiza naturalmente. Así funcionan muchas aplicaciones en la realidad. Alguien las desarrolla en su tiempo libre y se las enseña a otros, les gustan y empiezan a utilizarlas. El problema empieza cuando la gente empieza a quejarse y no está claro que tú no tienes la culpa. O cuando la gente esta contenta y no está claro que sea gracias a tí, que es el problema resultante de no prometer (comprometerse) a cosas si no creemos que las vamos a cumplir.

Para no tener la culpa lo mejor es no tener nada que ver con el desarrollo en cuestión. Otra opción es demostrar que la culpa la tiene otro. Por definición el culpable es aquel que se comprometió a algo y no cumplió, pero no tiene ninguna otra persona a la que culpar. Por supuesto, todos estamos comprometidos a todo aquello que no hayamos rechazado explícitamente (es decir, se es culpable a no ser que se demuestre lo contrario). Es algo así como un flujo descendente de la culpa.

También se puede tratar de demostrar que no hay culpables, principalmente porque el problema cuestión es irresoluble. Esto es peligroso porque te convierte automáticamente en el principal sospechoso y sobre todo porque se puede se puede producir un rebote hacia arriba del flujo de la culpa hacia los gestores por la falta de planificación. Una variación consiste en culpar a alguien que ya no forma parte del árbol de responsabilidades (un sumidero de culpas).

Resumiendo, el objetivo de la gestión de culpas -más conocida como gestión de riesgos (los riesgos de cargar con la culpa)- consiste en ser capaz de demostrar que has hecho todo aquello que no has rechazado explícitamente, y que lo has hecho bien.

Conceptos relacionados:

- Gestión inversa de requisitos. El objetivo de los requisitos es demostrar que no nos hemos comprometido a satisfacer ciertos requisitos.
- Test-driven development. El objetivo es demostrar que se han satisfecho el resto de los requisitos.
- Métricas de calidad. El objetivo de las métricas es medir y demostrar lo bien que has hecho el trabajo.

No hay comentarios: