lunes, 14 de diciembre de 2009

Monkey Business.

Son casi humanos... somos casi monos, mejor dicho.

Visto en La Pastilla Roja

Me deja pensando, al trasladar la situación a nuestra vida laboral, en que –si bien entre otros factores- las reglas de juego tienen un peso fundamental para determinar si será la colaboración, la competición o la indiferencia la característica predominante en un entorno de trabajo.

En todo caso estoy bastante seguro de que las reglas pesan más que las características personales. Somos ante todo animales sociales –al punto en el que sólo sobrevivimos en sociedad-, mucho más influenciables por los que nos rodean que –en conjunto- ellos por nosotros.

¿Se pueden alcanzar altos niveles de calidad –esa esmeralda perdida- en el desarrollo de software sin colaboración, sin verdadero trabajo de equipo? Yo creo que sí, pero es mucho, muchísimo más difícil que en un ambiente colaborativo.

Los costos de un ambiente de “indiferencia” en el que cada uno “sólo hace lo suyo” se ven reflejados en complejas estructuras de control superpuestas que coordinan el trabajo: líderes de esto y gerentes de lo otro, supervisores de lo de más allá y más acá, capas y capas de jefes de jefes cuyo trabajo es apenas un poco más que distribuir información y controlar el correcto ensamblaje de subproductos que se construyen en la base de la pirámide aisladamente, sin visión de conjunto.

Se podría decir que parte del trabajo de esa jerarquía es, justamente, proporcionar una visión de conjunto. El problema es que, para el momento en el que el flujo de trabajo llega a ese nivel de revisión es un poco demasiado tarde para cambiar nada.

Para el momento de revisar la calidad –siguiendo las metodologías tradicionales- ésta está prácticamente determinada –sí, claro que podemos corregir desvíos funcionales… ya sabemos lo que sucede con la calidad del código durante esas correcciones-. Si el producto no cumple con las expectativas –de calidad, no sólo las de cumplimiento de requisitos funcionales- la única solución real es el retrabajo.

La solución propuesta generalmente es dividir el desarrollo en pequeñas etapas y revisar la calidad en cada una de ellas –siempre al final- con la esperanza de que la “suma de las calidades” sea provechosa –siempre al final-, y si así y todo las etapas presuponen productos demasiado amplios, las subdividimos… y luego ponemos a un responsable de cada división y de cada etapa, y ya estamos donde empezamos: jefes de jefes de jefes y poco trabajo real.

En un ambiente de colaboración las cosas son diferentes. La revisión es constante porque nadie es indiferente a lo que lo rodea. Cada corrección es mínima pero se dan constantemente. Es mucho más probable que la calidad final sea –para bien o para mal- toda la que el equipo pudo dar en un momento determinado. En esta situación el retrabajo cobra otro sentido: no es la corrección de lo que –en teoría- podría haberse hecho bien desde un principio sino la materialización del aprendizaje acumulado en el camino.

Pero son las reglas las que determinan si esa colaboración es posible. Si la ruta, -correcta o no, eso se verá al final- está predeterminada a través de un diseño milimétrico, el combustible de horas/hombre está calculado como para llegar con el tanque vacío y encima el vehículo no tiene ventanillas de poco sirve ponerse a pensar si hay o no un árbol en el camino, más vale rezar y esperar que cuando nos bajemos estemos en donde queríamos estar. ¿Parece difícil, no?

No hay comentarios.: