Mirar el todo: llevar el agilismo a las grandes organizaciones.

Mirar el todo: llevar el agilismo a las grandes organizaciones.

Ahora que conseguimos que se ponga de moda el Lean aplicado a la tecnología/desarrollo, vamos a repasar lo que yo entiendo como en primer principio, mirar el todo, que es lo que muchos CIOs tienen que hacer:

Recordemos los principios del site (interpretado libremente) www.poppendieck.com:

  • Mirar el todo.
  • Integrar la calidad.
  • Eliminar el desperdicio.
  • Amplificar el aprendizaje.
  • Entregar tan pronto como sea posible.
  • Potenciar a las personas.
  • Mejorar constantemente.

En las grandes corporaciones tienen cantidad de proyectos a manejar y pronto se empieza a descontrolar la situación porque todo el mundo tiene nuevas necesidades. (Imágenes de la charla de corporate agile.)

Es más, es relativamente fácil devolver la presión de proporcionar resultados a la dirección alegando que no se tienen las “herramientas informáticas” adecuadas para hacer correctamente el trabajo. Según el arte de la guerra (Sun-Tzu) desviar el conflicto a un tercero es siempre una buena estrategia.

Por tanto, la dirección de tecnología tiene una presión creciente y requiere reportar resultados en bases cada vez más cortas, con unas prioridades cambiantes en base a la presión que, a su vez, le rebote a la dirección general. No es de extrañar que las plantillas crezcan y empiecen a crear oficinas de proyecto para coordinar el estatus y dar la información que necesitan los de arriba, en proyectos normalmente mal definidos.

El problema es que estas oficinas de proyecto raramente aportan valor y ¿por qué?

Primero vamos a pensar en el perfil del personal que ocupa estos puestos: – Si es alguien técnico al que pasan a gestión, posiblemente se encuentre des-ubicado. Un técnico (esto lo podéis leer en el libro Lean StartUp) cree que está siendo efectivo en su trabajo cuando está dedicando 8 horas, sin interrupciones, a lo que él considera trabajar. Trabajar no es reunirse, no es coordinar. Por tanto, la motivación puede ser tirando a baja. La motivación va ligada al desempeño, igual que la presión.

  • Presión motivación baja, rendimiento bajo.
  • Presión motivación media-alta, rendimiento alto.
  • Demasiada presión-motivación, rendimiento bajo (stress o pérdida de foco).

– Si es alguien con perfil “consultor” que creéis que es más fácil que pase:

  • a) Que se quiera arrimar más a la dirección, que puede contar con ellos para otros proyectos/ascensos, a la que dedique más tiempo, y se convierta en una herramienta de presión más a los de abajo.
  • b) Que se pase todo el día junto a los técnicos intentado dar solución a sus problemas de interpretación de negocio, tratando de controlar las expectativas.

Bueno, seguro que depende de la persona y que hay un poco de los dos pero, creedme que es más fácil arrimarse a los que más poder tienen y alejarse de los técnicos para que no les salpiquen los incumplimientos.

Pero la pregunta es ¿y cómo conseguimos que estas oficinas de proyecto aporten verdadero valor?.

Pues sencillo: que conozcan el negocio y no sólo técnicas de gestión. Una día, un amigo que trabajaba en un gran banco me contó su historia, que creo que es un buen principio:

  • Había terminado la coordinación de un proyecto con relativo éxito (realizado por un proveedor) y, envalentonado, se fue a hablar con el director general diciendo que quería que la organización le pagase un Executive MBA.
  • Después de hablar un rato con él (y darse cuenta de que no tenía ni idea del sector), el director general le dijo: “Claro que vas a hacer un Master, pero de lo que a nosotros nos dedicamos. Te vamos a mandar 3 meses a una oficina donde vas a estar en todos los puestos: de cajero, en el área de empresas, ayudando al subdirector de la sucursal, visitando empresas, etc, de ese modo ya no tendrás que pedir que te priorice la importancia de los problemas: tú mismo sabrás qué es importante y qué no y, además, vendrás con un plan de decenas de mejoras en nuestros sistemas por haberlos sufrido”.

Si lo habéis captado, esto fue una oportunidad única para desarrollarse dentro de la organización y alinear las áreas de tecnología con las de negocio, haciendo que los mandos intermedios, que hasta ahora se había formado en técnicas de gestión, aprendieran de verdad el negocio. Aprendieran a mirar el todo.

No parece descabellado que cuando una persona se incorporase a cualquier corporación aprendiera el negocio antes de asumir su responsabilidad final. Como estamos en un mundo acelerado y corto-placista, esto no se hace, lo que provoca grandes desvirtualiciones de la realidad.

Al final, a muchos directivos de tecnología y mandos intermedios te los puedes encontrar arrastrados por el lado oscuro, cambiando constantemente de sector, donde les puede interesar más estar en mesas de compras, agasajados por proveedores (invitándoles a externalizar) y apostando por las nuevas tendencias tecnológicas (trabajando en proyectos en siglas/paradigmas de moda como ahora cloud o big-data). Claro, así es difícil que terminen en los consejos de administración… Aunque seguro que sí salen en alguna de las revistas del sector recibiendo un premio 😉

En las metodologías ágiles, donde los equipos están auto-gestionados (en mayor o menor medida en base a su madurez), se requiere de una figura imprescindible: el product-owner; el dueño de producto que tiene que dar unas especificaciones claras de lo que se necesita. A los responsables de negocio les suele pasar lo mismo que a los técnicos: percibe que están trabajando cuando se están dedicando 8 horas a lo que ellos creen que es trabajar. Y no es trabajar el estar muchas horas con los técnicos dando especificaciones detalladas porque, por proyección, piensan que esos técnicos deberían conocer el negocio del mismo modo. Además, siempre es mejor dar ideas vagas y criticar lo que otros hacen que hacerlo juntos.

Pues al personal de las oficinas de proyecto, formadas en el negocio, se las puede integrar como product-owner-proxys, es decir, como representante del cliente ausente, donde pueden compartir más fácilmente tiempo y visiones “con los de arriba” e interactuar con los equipos técnicos dentro de un mismo equipo de proyecto, y no como “visitantes” para preparar informes, como gestores profesionales.

Las metodologías como Scrum ya ofrecen “radiadores” para proporcionar información cuantitativa a la organización, por lo que las áreas intermedias se quedan sin tanta carga. Siguen siendo necesarias las oficinas de proyecto pero articuladas de otro modo: activas en los proyectos.

La conclusión es que las organizaciones se pueden aplanar y aportar con la misma gente más valor.

Parece entonces que las metodologías ágiles sí ayudan a que se minimice el desperdicio: gente puramente llevando información de un lado al otro, ayuda a que todo el mundo aporte más valor a sus negocios. ¿O se nos ha olvidado que la función de un departamento de desarrollo es ofrecer el máximo software “útil”? No es optimizar la gestión (confundiendo el medio y el fin), es optimizar la entrega de software.

En las épocas de abundancia se pueden pagar excesos, como clases sociales en la empresa que viven en tierra de nadie. Cuando la crisis aprieta y/o se busca mayor efectividad, hay que intentar que todo el mundo se acerque a optimizar la producción.

Eso sí, dicho estas palabras, que a nadie se le ocurra plantear cambios radicales en su organización y tratar de migrar a todos los mandos intermedio. Esto se empieza con cariño con una persona afín a la idea, en un proyecto razonable en tiempo y recursos y, probado su éxito, se extiende poco a poco viralmente.

Debe primar el sentido común, perdido durante mucho tiempo.