El temor al conflicto

Existe una raza muy especial de responsables de IT o areas subordinadas. Realmente esa raza se ha extendido a múltiples departamentos y unidades de negocio de diferentes empresas.

Se trata en general de personas que no suelen tener mucha idea de lo que hablan, pero lo hacen de una manera autoritaria, agresiva, vehemente... en fin, variables que superan con creces a otras como conocimiento, sentido común, respeto a las opiniones, etc.

En un entorno inmaduro como en el que nos movemos, en el que habitualmente hay bastante rechazo al conflicto, triunfan los mentirosos y los despotas.

Los mentirosos triunfan porque el mar de ambigüedad y desconocimiento que muchas veces rodea las cuetiones tecnológicas o metodológicas no da pie a discusiones serias, en las que se puedan defender o atacar argumentos de manera relativamente sólida. Ahí ganan los mentirosos sutiles, los que no parece que mienten, o si lo parece, mejor creerse lo que dicen por evitar un conflicto absolutamente esteril.

Al igual que los mentirosos, los despotas triunfan porque son capaces de imponer sus ideas u opiniones a fuerza de agresividad y rudeza. Ahí, por evitar conflictos en este caso más desagradables, también ganan ellos.

Normalmente, los mentirosos suelen estar en la trinchera del proveedor, en forma de comerciales o consultores 'galácticos'. Por el contrario, despotas los solemos encontrar en clientes finales, tomando forma de directores de area, unidades de negocio, responsables de factorías de software y un largo etcétera.

Lo peor es cuando se juntan mentirosos y despotas; en ese momento, el espéctáculo está asegurado. Habitualmente, suelen juntarse en el proceso de venta o en el proceso de cierre de los proyectos, es decir, cuando nadie quiere conflictos, es más, cuando todo el mundo los teme.

Así, los mentirosos venden proyectos a base de falsedades, las cuales son matizadas (normalemente para mal) por parte de los despotas, porque si no, no hay trato.

Calidad y urgencia

Las cosas se pueden hacer bien o mal. Para hacer las cosas bien hay que hacerlas con cuidado, sin urgencia. En general hacer las cosas con cuidado tiene ciertas ventajas, ya que se supone que mejora la calidad del resultado final y disminuye los problemas y las culpas.

El problema de hacer las cosas con cuidado es que es incompatible con las urgencias. Y hacer las cosas con prisas tiene al menos dos ventajas cuya importancia no hemos de minusvalorar:

• Cuando hacemos las cosas con prisas, podemos culpar a las prisas de la mala calidad del resultado, con lo que se reduce nuestra responsabilidad. Esto es una gestión sencilla de las culpas a la que no hay que renunciar sin considerar los riesgos.
  
• Cuando tenemos prisa, podemos presionar a nuestros subordinados para que trabajen más horas. Esto simplifica nuestra gestión, ya que evitamos la responsabilidad de la planificación y el seguimiento de los proyectos.
  

Lo complicado de todo esto consiste en que estas dos ventajas funcionan a todos los niveles. Si presionamos a nuestros subordinados para que trabajen más duro mediante la segunda táctica, ellos utilizarán la primera en nuestra contra y la calidad del resultado será imprevisible.

(Corolario: se puede presionar a un programador para que trabaje acabando una aplicación durante el fin de semana, pero luego no se le puede pedir que documente las pruebas unitarias)

CASPER

Aunque rápidamente se viene a la cabeza ese pequeño, cabezón y simpático fantasmilla, nos queremos referir al Conjunto de Artefactos Solo Para Esta Release.

Existe la idea equivocada de estar obligados mantener continuamente toda la documentación que se genera a lo largo de un proyecto. Pero sin embargo, hay cantidad de artefactos de usar y tirar. Es decir, información que sólo tiene sentido durante un ciclo de desarrollo (idealmente lo más corto posible); pero que no es necesario mantener por más tiempo.

Algunos ejemplos son: conjunto de peticiones u ocurrencias del cliente asumidas para la siguiente release, lista de pruebas específicas para dicha versión, notas sobre cambios realizados en los diseños o el código durante este ciclo de desarrollo, diagramas o indicaciones al programador sobre cómo implementar las nuevas funciones, etc.

Debemos asumir que esta documentación no requiere excesivo formalismo y, en general será bastante simplona, ya que en general se trata de indicaciones sobre cómo modificar el producto.

Evidentemente, tendremos artefactos que definen el producto en sí, y que sufren cambios continuos durante el ciclo de vida de dicho producto. Para entendernos, hablamos de la especificación funcional, de la arquitectura, diseño de clases o bbdd, código, hardware, equipo de trabajo,... es decir, el MODELO, con mayúsculas, o todo lo que se va manteniendo desde el principio hasta el final.

Diferenciar claramente entre ambos conceptos (CASPER y MODELO) aclara enormente las cosas a la hora de gestionar documentación, cambios, requisitos o el proyecto en general.

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.