En uno de los comentarios de los ultimos post Rafa comentaba acerca de los DWH. "No todas las organizaciones son suficientemente maduras para lanzarse a ello...".
Eso me hizo reflexionar sobre la idea de qué debe cumplir una organización para poder abordar un proyecto utilizando metodologías ágiles, que paradigmas se han de romper para tener garantías de éxito en un proyecto de este tipo. El resultado son estos siete puntos (sí otra vez siete, como Los Siete Samurais)
1) Cambiar el estilo de gestión de "orden y control" hacia "liderazgo y colaboración".
Una organización basada en una visión clásica de dar ordenes y controlar al personal, dificilmente podrá asumir un proyecto ágil. Las jerarquías estrictas de jefe-ordena y empleado-obedece, acabn indefectiblemente en situaciones en que las personas se limitan a hacer sus tareas y nada más sin aportar nada por lo que no se le pague. En un organización ágil, el coaching y el liderazgo colaborativo harán que el equipo de lo máximo de si. No queremos un jefe que mande, queremos un lider que motive. No queremos un control, queremos una colaboración.
2) Cambiar la cultura empresarial de "centrada en los procesos" hacia "centrada en las personas".
La visión única de control de procesos de negocio sin tener en cuenta las interacciones de estos procesos con las personas que los ejecutan tiene que desaparacer. Ya lo vimos en el anterior artículo, el éxito está en la interacion de las personas con los procesos y con la tecnología. Si queremos ser ágiles debemos organizar nuestra empresa en torno a las personas, que son las que pueden darnos esa agilidad, esa capacidad de adaptación a situaciones nuevas que no hayan sido previamente pensadas y modeladas en un proceso, pero que son vitales para la supervivencia de una orgnaización.
3) Cambiar la gestión del conocimiento no crucial de "explícito" a "tácito".
El conocimiento de una organización suele estar siempre en los cerebros de sus empleados, las organizaciones tienden a intentar guardarlo de forma explícita, absolutamente todo y al máximo nivel de detalle posible, eso nos deja en la penosa situación de documentar periodicamente nuestro conocimiento y claro no lo haces como lo explicarías de viva voz, porque has de ser formal y explícito. Precisamente este ansia de documentarlo todo, es loq ue ha veces nos corta las alas de la creatividad, perdemos tiempo en documentar en lugar de invertirlo en crear, en adquirir nuevo conocimiento. Prefiero documentar una idea genial en una servilleta de papel y que tener toneladas de documentos repletos de vacuidades.
Obviamente, esto nos deja en una situación bastante comprometida de dependecia de nuestros empleados, pero no nos engañemos, eso SIEMPRE es así, el autentico conocimiento esta en las personas, nos podemos engañar diciendo que no, pero es eso, un simple engaño.
4) Cambiar la comunicación de "formal" a "informal".
Si queremos hacer equipos, que colaboraren , compartan conocimiento, y funcione al unísono, no podemos encorsetarnos en comunicaciones rígidas, formales y llenas de burocracia.
5) Cambiar el rol del usuario final de "importante" a "fundamental".
En las metodologías tradicionales, el usuario o cliente formaba parte de la fase de análisis en la que tomabamos los requisitos del sistema. Con las metodología ágiles los usuarios finales forman parte del equipo de desarrollo y son una pieza fundamental del proyecto. Sin ellos, simplemente no hay proyecto.
6) Cambiar la estructura de la organización de "jerárquica" a "orgánica".
Debemos pasar de un entorno burocrático y altamente formal a una orgnaización felxible, reflexiva, participativa y que facilite la cooperación. Si os fijais las neuronas no están organizadas en forma de arbol jerárquico, sino en forma de red. Cada persona es como una neurano del "cerebro" de la organización.
7) Cambiar los "roles estrictos" por "roles intercambiables".
En la revolución industrial teneia serntido, que una persona se especializase solo en una cosa, pero en la época actual, el poder intercambiar roles y funciones en un mismo proyecto, nos da la posibilidad de desarrollar nuevos puntos de vista y así atacar los mismos problemas desde diferentes puntos de vista. Nuestros empleados crecerán en motivación, en conocimiento y la empresa será mas adaptable.
Seguramente son 7 grandes barreras, pero hay que empezar a romperlas si queremos adaptarnos a los nuevos paradigmas
Modificación del 4/12/2006Joserra ha escrito este estupendo complemente que no os podeis perder
La confianza y las metodologías ágiles.
18 comentarios:
Bastante bueno el post.
Aunque no tengo formación a tan alto nivel sobre liderazgo y dirección, gran parte de lo escrito lo tengo ya en mente.
He sufrido jerarquías de yo ordeno y tu obecedes y acabas contando los días para irte.
Saludos.
A veces es mucho mas importante poner en práctica el sentido común que complicadas metodologías. Cuatro gotas de él y las cosas mejoran fácilmente.
Hola Jorge, he leido tu post y me parece muy interesante. Con tu permiso, lo he incluido en uno de mis blogs citando por supuesto tanto tu autoría como poniendo un link directo.
Te lo paso por si quieres verlo:
http://marketingeinternet.blogspot.com/2006/08/7-paradigmas-romper-para-tener-una.html
Saludos y felicitaciones por la forma de expresarlo.
He borrado el anterior comentario porque habia publicado el post en un blog equivocado ( a estas horas todo puede suceder)
Antonio Domingo
www.fenixmedia.com
Muchas gracias Antonio.
Me ha gustado mucho como lo has puesto. Me apunto tu blog que tiene buena pinta.
Es interesante, pero un tanto utópico con el sistema de desarrollo actual; sobretodo en IT.
El desarrollo y mantenimiento se suele contratar a terceros (outsourcing) y el conocimiento se queda en manos de la empresa externa. Estos "terceros" suelen ser consultoras que les importa más el negocio 'la pela' que el buen hacer, colaboración y todas las bondades que indica el artículo.... Sin la documentación ni el control adecuado, la empresa final se me sometida a los caprichos de la consultora y en caso de querer cambiar, hay que gastarse una pasta en investigar los que los otros han hecho.
El modelo que se propone es bueno para una empresa que se guise y se coma sus proyectos; pero de éstas ya no quedan mucho.
Un outsourcing "Total" del departemento de IT, es independientemente de la metodología que uses, sea ágil o sea tradicional, un error desde mi punto de vista. Esta bien que una parte del departamente la externalices, pero los perfiles medios-altos que conocen el negocio de tu empresa, el entorno, a las personas y que te pueden dar un valor añadido deben formar parte del personal de tu empresa.
Dejar todo IT en manos de terceros no es una buena solución, debes realizar siempre equipos mixtos, con un jefe de proyectos interno que te garantice que la modelización del procesos se ajusta a las necesidades de tu orgnización.
Enhorabuena Jorge por este artículo. Tan solo reflexionar sobre el antagonismo de tus propuestas con la tendencia actual en las relaciones laborales donde el compromiso entre empleado y empleador, en ambas direcciones, cada vez es menor. No obstante es interesante considerar esta guía para la gestión de proyectos, tal como propones al inicio del artículo, donde los compromisos tienen una duración más corta y puede conseguirse una mayor implicación de los participantes así como una mayor satisfacción en el desarrollo del trabajo por parte de todos aplicando los 7 paradigmas que propones.
Lo incluyo en mi lista para leer de vez en cuando http://del.icio.us/aagueda/Leer-de-vez-en-cuando
Muy interesante! Me atrevería a resumir en una palabra los siete puntos: CONFIANZA.
Confianza en los empleados, confianza entre los desarrolladores, confianza en los jefes de proyecto...
Tienes toda la razón, la confianza es lo fundamental en una organización ágil
Al final lo escribí un poco más formal: La confianza y las metodologías ágiles.
Estupendo, con tu permiso lo voy a añadir al final del articulo original
Me parece muy bueno el post, y estoy de acuerdo en mucho de lo que dices. Sin embargo, yo estoy haciendo el camino inverso, el pasar de una organización de TI, "excesivamente agil" a algo más controlado.
Aún así, estando yo al frente de esta reorganización, lo que siempre, cada mañana tengo presente es que la gente que sabe es la que está trabajando, y que hay que dar herramientas y ayudas para que se gestionen mejor.
Creo que este tipo de enfoques se pueden aplicar a determinadas partes de procesos de TI, pero otras más operacionales tienen que seguir siempre el esquema de un proceso maduro.
Me ha gustado el punto que comentas de la comunicación, estoy totalmente de acuerdo contigo creo que la informal hay que potenciarla respecto a la formal, sin embargo no todo el mundo opina así. De hecho, hace solo una semana, senté a todo el departamento para hablar de como nos estábamos organizando, y había un grupo de técnicos que lo que pedían es MAS COMUNICACION FORMAl y menos blog de TI y Wiki y charlas informales. (al final cada persona es un mundo)
Como tu bien dices la agilidad no se puede aplicar a todos los procesos y en todo momento, tiene su tiempo, su lugar y su equipo. Hay que saber cuando aplicarla.
Es muy curioso tu viaje a la inversa, me encantaria que compartieras con nosotros los problemas que te ha dado la agilidad.
La idea de la wiki me parece muy acertada, pero fijate que precisamente el fundamento de la wiki es que alguien porque quiere documenta algo apra comparir, pero no por que le obligan ha hacerlo. Las metodologías rígidas te obligana documentar cosas que luego nadie lee, es mejor documentar poco y ahcerlo con gracia y ganas como la wiki que tu propones.
Tampoco descarto la servilleta ;-B
Uff, eso de incentivar monetariamente esta bien, pero no es la idea de las metodologías ágiles (ojo que altruistas y tontos tampoco), pero en ellas necesitas un equipo y una gestión que se automotiven sin que la zanahoria del dolar este presente.
Pero la documentación ha de ser la justa y necesaria, ni inexistente , ni innecesariamente burocrática.
Muy buen artículo, bien documentado y actual
Revisando mis anotaciones antiguas, recuperé un enlace que me llevó directamente a este blog donde está bien resumido un conjunto de paradigmas que una organización debe reconocer para mejorar sus resultados como una entidad productiva, eficiente y eficaz.
Me pareció prudente guardar estas reflexiones en mi BLOG personal, para no olvidar lo que hace tiempo vengo sin poder lograr en la organización en la que participo.
Estos siete pasos que mencionas tienen un peso relativo muy importante para mi, puesto que participo de una organización que no tiene estructura para adoptar "modelos de producción pesados", pero cuya Gerencia se resiste a conocer e invertir tiempo y recursos para adoptar una metodología de trabajo Ágile. Tanto es así que nuestro proceso avanza con "calambres" y se altera en cada situación que lo conflictúa, lo entorpece o demuestra su obsolescencia.
Yo le di el nombre particular de "Proceso del Enjuiciamiento Final" ya que por cada fracaso se inicia indefectiblemente un proceso de enjuiciamiento a los involucrados.
Me pareció muy atinado esto de los Samurai, por que cuando el proceso iniciado de "enjuiciamiento" comienza a arrojar ataques, nuestras técnicas de defensas se ponen en evidencia más que nuestras verdaderas capacidades como profesionales y como personas. Tal vez hasta hemos perfeccionado nuestros mecanismos de auto defensa a un extremo dañino. Algunos ya expresaron que su mecanismo se basa en simplemente dar la razón. Otros en hacer pausas promoviendo la continua verborragia de "El Enjuiciador".
Publicar un comentario