icono_twiter icono LinkedIn icono Facebook Icono Xing
Roberto Canales Mora

Creador y propietario de AdictosAlTrabajo.com, Director General de Autentia S.L., Ingeniero Técnico de Telecomunicaciones y Executive MBA por el Instituto de Empresa 2007.
Twitter:

Autor de los Libros: Planifica tu éxito: de aprendiz a empresario y Informática profesional, las reglas no escritas para triunfar en la empresa

Puedes consultar mi CV y alguna de mis primeras aplicaciones (de los 90) aquí

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2013-01-02

Tutorial visitado 2.473 veces Descargar en PDF
Mirar el todo

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.



A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL:

Fecha publicación: 2013-01-03-12:18:00

Autor: Erodriguezmar

Uy! Mucho más claro, gracias por el resumen! Pero es que no podemos olvidar lo estratégico, porque de ahí parten muchas cosas, por ejemplo, si queremos que la gente técnica sepa de negocio, tendrá que haber un objetivo estratégico que diga que la gente debe estar una temporadita p.e en las sucursales como a tu amigo banquero le sugirieron y eso o se es capaz de vender arriba demostrando que aporta valor y se convierte el algo estratégico o complicado lo veo.

Y esto no es nada nuevo, p.e en Imaginarium ya se aplica, que yo sepa para directivos, pero si tiene que aplicar a otros ámbitos, no lo puede cambiar un programador, o mando intermedio o CIO sino el Director General....(obviamente hay que sugerirlo y proponerlo y hay que tener las armas adecuadas para defenderlo, ahí es donde creo que vosotros y la gente con experiencia puede aportar)

A eso me refería con que no solo es cuestión de hablar de metodologías ágiles en la gestión de proyectos, sino que hay un montón más de temas importantes alrededor, y no hay más que ver el comentario de jcmgiraldo que creo está en la mente de mucha gente! Como cuantificamos el "valor" que cada cual aporta y cuanto vale eso en términos de nuestro amigo "don dinero"? Como gestionamos las expectativas de "carrera profesional"?

Bueno, seré paciente y esperaré tus próximos posts, yo por al parte que me toca voy a intentar resumir nuestra experiencia como novatos en esto y contarlo con la ayuda de la gente del equipo que le apetezca.....de momento poco más puedo hacer más que intentar aprender y preguntar :-)!

Y gracias por contar cosas, es la única manera de que la gente piense, se plantee alternativas y tome decisiones, que no se conquistó Roma en dos días! Y ya se sabe que por más que a uno le digan cosas, el poder de cambio parte de uno mismo y el cambio solo es posible si de manera consciente se decide que hay que hacerlo. Nadie cambia nada si no cree que va a tener un beneficio haciéndolo.....y crees que cualquier gran consultora que se gana sus buenas perras con el control férreo de cambios/alcance va a dar el paso? pues creo que por ellos mismos no, es cierto que son los clientes los que tienen el poder de decidir a quien compramos o no, pero cuando hay relaciones en las alturas.......uffff cuantas barreras quedan por romper :-)

Fecha publicación: 2013-01-03-11:18:12

Autor: rcanales

Hola jcmgiraldo:

Tendrías que definir que es un "desarrollador senior" para que veamos el valor que aporta. Podrías intentarlo aquí con un resumen de habilidades y yo te puedo decir las que creo que podría tener: a ver si hablamos de lo mismo.

¿Cuantos programadores hay en España de más de 40 años? Muchos y cada vez más. Sólo acercate a un open-spaces, code-retreat, etc. Lo único que ahora verás que ellos mismos se empiezan a llamar "artesanos" y aglutinan muchas habilidades.

Cualquier foro deriva hablando de sueldos de alguien que se encuentra insatisfecho con el suyo pero os voy a hacer la pregunta al revés ¿por qué habilidades alguien estaría dispuesto a pagar mucho? ¿las tenemos? ¿cómo nos diferenciamos de los demás?

Fecha publicación: 2013-01-03-10:54:48

Autor: jcmgiraldo

Todo esto está muy bien, pero seamos sinceros, el problema aquí es otro. Queremos implantar metodología que viene de otros paises (USA/JAPON/ALEMANIA...) y es muy lógico pensar que si ellos hacen software más rápido y mejor que nosotros será por que se organizan mejor. Puede ser, pero lo cierto, es que en esos países, la figura del desarrollador tiene peso, y se paga y aquí perdemos el culo para pasarnos a la gestión si quieres tener un salario decente. ¿Cuantos programadores hay en España de más de 40 años? Pues ahí lo tienes. En esos países la difencia saliarial entre gestores y técnicos no es tan abultada como aquí.

Y el problema no es solo de las consultoras, también es de los clientes que no son capaces de ver el valor de un desarrollador senior. Y es que la visión del cliente de software es la visión, erróneamente, de un constructor de viviendas. "¿Cómo voy a pagar lo mismo a un peon que a al arquitecto?" Eso lo he oido yo. Se olvidan, que en el software, los peones también tienen formación específica.

Resumiendo, se puede aplicar agilismo, pero su eficacia no se va a ver si no se toman en consideración otros problemas.

Fecha publicación: 2013-01-03-10:43:40

Autor: rcanales

Hola Erodriguezmar:

Claro que da para una saga.. y es lo que voy a intentar hacer, tratar de contestar con distintos post (en distintos días) aunque esto está abierto para todo el que se quiera animar.

Si te fijas, empecé el melón hablando de "mirar el todo" (en nivel táctico y tus preguntas van más al estratégico).

Si que suelo dispersarme y mezclar muchas ideas pero el resumen que se podría sacar de este post es que:

Si un director general lo lee, debería pensar si sus responsables de tecnología entienden el negocio. También si ellos mismos no están cediendo a presiones y trasladándolas a tecnología.
Si un director de tecnología lo lee, debería pensar si sus "analistas" entienden el negocio de primera mano o son interpretes (que se admite sólo durante un tiempo).
Si lo mira un gestor intermedio, que no maneja ya ni la tecnología ni conoce el negocio, podría plantearse a cual de los dos sitios podría acercarse para aportar un poco más de valor (product-owner o arquitectura).
Si lo lee un técnico, debería pensar que debe preocuparse de entender el negocio y de si sus esfuerzos contribuyen a que vaya mejor. Además, en este último caso, si adopta la (auto)gestión, se acerca a negocio y aporta números es muy posible que no de argumentos para externalizar/globalizar su trabajo.

Fecha publicación: 2013-01-03-08:34:56

Autor: Erodriguezmar

Como dicen que el feedback es un regalo, ahí va el mío con afán constructivo (me temo que después del curso me ha dado un chute activación -responsabilidad tuya- espero se me pase pronto....)
Me temo que estoy un poco espesita porque no termino de entender el foco del post, es hablar de llevar a las grandes organizaciones la agilidad? De la visión del CIO? de lean? de las oficina de proyecto? de todo a la vez? es que creo que son temas amplios que dan para una saga.

En realidad tengo muchas dudas de cómo se puede gestionar un equipo de IT completo de forma ágil en una gran organización (igual lo contasteis en la conferencia del Santander....pero como no fui....), han ido las metodologías ágiles más allá de la gestión de proyectos en si? Me refiero, como gestionaremos de manera ágil cosas como por ejemplo:

1.- El portfolio de aplicaciones de una gran organización
2.- La gestión de objetivos y desempeño del equipo, que eso de hacer todos de todo está guay, pero como lidias en una gran organización donde RRHH (ej. consultoras) ha impuesto mecanismos de promoción basada en el "crecimiento de perfiles profesionales" programador junior, senior, analista, JP, etc....
3.- Si estás en una gran organización cómo se lleva el proceso de cambio? Hay cosas escritas sobre eso? Es decir, las cosas por partes, como diría Jack el destripador, pero por donde se empieza? Que hacer primero? coger un equipo de referencia? basado en qué? hay alguna forma de hacer un plan director de sistemas de forma ágil, porque los libros que hay sobre esto son del siglo pasado?

Es que creo que alrededor de la gestión de un proyecto ágil hay muchas más cosas que impactan de lleno y que no se pueden obviar sobre todo cuando están establecidas desde hace tiempo, y ya no solo de la parte humana, por ejemplo, qué pasa con las certificaciones, esos proyectos faraónicos de conseguir el CMMi nivel como poco 3....

Creo que hay que desmontar muchos mitos/barreras/cosas establecidas. Por donde rompemos esa zona de confort para iniciar el cambio con garantía?? Que planteáis los que sabéis de esto?