archivo

Archivos diarios: enero 2, 2013

A veces existe dificultad para entendernos con una persona o con otro equipo de trabajo y sin embargo requerimos de su colaboración para ejecutar determinadas tareas.

En el momento en que empezamos a acudir de manera reiterada a un superior para forzar ese entendimiento estaremos provocando este antipatrón ya que una cosa es que para un tema puntual se requiera su participación y otra es que se convierta en intermediario en la mayoría de las operaciones que tenemos con esa otra persona o equipo.

¿Qué provoca este antipatrón?

– El problema entre las personas o los equipos se hace más grande, si había poca confianza, se pierde, si había resistencias ahora serán más grandes.

– El jefe actúa pero no resuelve el problema de fondo que no es otro que determinar el por qué se ha llegado a esa situación. Si no hay fluidez en las relaciones entre los equipos, personas o departamentos y los mismos tienen que colaborar de manera activa, el principal afectado será la organización, además de los departamentos y proyectos implicados.

– El jefe actúa de apagafuegos en temas que, por lo general, son de un nivel de detalle que se le escapan, por lo que las decisiones que adopte es posible que no sean las más acertadas.

Recuerdo un día en el que charlaba con otra persona sobre las bondades e inconvenientes de las metodologías clásicas y los enfoques ágiles. Me decía que en su organización se había perdido mucho dinero en proyectos desarrollados con metodologías ágiles, antes de preguntarle más detalles, le pregunté que cuánto dinero habían perdido con las cascadas y obtuve el silencio por respuesta.

Dado que por ahí no iba a conseguir avanzar mucho, decidí cuestionarle sobre cómo se habían aplicado las metodologías ágiles y la verdad es que tampoco supo darme mucha más información, en base a lo que me decía interpreté que se aplicaron ciclos de vidas iterativos incrementales con sprints de corta y media duración.

Le comenté que la aplicación de ese ciclo de vida era un primer paso pero que no era suficiente para considerar el enfoque cómo ágil ya que no solo se trataba de aplicar una metodología concreta, sino que detrás debe haber una base conceptual asimilada por buena parte de los intervinientes.

Le pregunté que por qué creía que esos proyectos fracasaron y la respuesta fue que se desarrollaba sin tener una visión clara del sistema a desarrollar, lo que hacía que en cada iteración se tuviera que rehacer buena parte de lo desarrollado en la anterior.

Antes de indicarle mi diagnóstico (y advertirle que para poder ser más preciso necesitaría más información y hablar con más personas), siguió hablando y me comentó que el problema era debido a que no se había hecho un estudio exhaustivo de lo que se quería y eso se obtenía a partir de un catálogo de requisitos.

Le dije que no se necesita llegar a tanto para tener una visión del producto y que el catálogo de requisitos es solo una ilusión, un traslado a un documento de una visión abstracta de lo que se quiere, que probablemente se encuentra lejos de la solución concreta que los usuarios necesitan y que la aproximación a la misma se conseguía a través del feedback.

Es cierto que se necesita tener una visión de lo que se quiere hacer para poder desarrollar con la mayor intención posible pero también que el feedback es inevitable y necesario.