En mi post anterior de Consultoría Artesana. Reflexiones sueltas ya deslicé tímidamente que encontraba puntos de contacto entre los principios que (creo) inspiran la consultoría artesana y los métodos ágiles, cuyo corpus doctrinal se resume, de forma ágil por supuesto, en los 4 principios y 12 puntos del manifiesto por el desarrollo ágil de software.
Soy consciente de que estos principios fueron formulados para ser aplicados en un ámbito tan específico como el desarrollo de software, pero los paralelismos que encuentro son tantos que no me puedo resistir a reflexionar sobre cómo aplicarlos a esto que hemos venido a llamar la consultoría artesana.
Como método, creo que vale, iré desgranando los 4 principios del manifiesto ágil y los paralelismos que encuentro con la consultoría artesana (tal como yo la concibo al menos) y que abreviaré a partir de ahora como CA.
Los métodos ágiles se asientan en cuatro principios básicos:
Valorar más a los individuos y su interacción que a los procesos y las herramientas
En el caso de la CA se maneja el axioma de que cada proyecto es irrepetible al 100%. Hay que trabajarlo sin estar atados a metodologías enlatadas que bloqueen la entrada a nuevas ideas, pero sin renunciar -ya me pronuncié al respecto- a experiencias anteriores.
Así, (dicho a lo cluetrainiano) los proyectos son -deben ser- conversaciones, entre consultor y cliente. De resolución conjunta, de escucha atenta (¡mutua, que hay cada cliente que para qué!), de exploración compartida, donde el consultor -aparte de traer conocimiento foráneo- sabe extraer y canalizar el que reside en el propio cliente (a veces sólo hay que escuchar para ver que la solución a un problema ya está ahí y que sólo hay que presentarla de la forma adecuada). La metodología no es ya una serie de tareas encadenadas, con roles, deadlines, deliverables, etc. sino que se parece más a poner en escena a los diferentes actores y verles actuar sin guiones previos completamente cerrados.
Valorar más el software que funciona que la documentación exhaustiva
El fin del powerpoint-informe-final-de-proyecto como un objetivo en sí mismo del proyecto. Este es uno de los elementos más potentes y dinamitadores que veo. El propio proceso del proyecto se constituye en un resultado del mismo: intercambio abierto, construcción de conocimiento pasito a pasito, consciencia y conciencia de que el proyecto no se acaba del todo, metodología que luego quedará, confianza adquirida entre las personas componentes del proyecto, ... son en sí mismo resultados que perdurarán y deberían ser benéficos para la organización de forma permanente.
En contraposición: el tipico proyecto donde los consultores desembarcan con sus metodologías, sus best practices multiterreno, ... removiendo cielo y tierra, recogiendo mucha información para, al final, presentar el megainforme que debe ir a misa (aclaro, es una caricatura)
Valorar más la colaboración con el cliente que la negociación contractual
Es evidente que la CA no se puede desarrollar así como así en cualquier cliente porque exige de éste que vaya a pecho descubierto, con un resultado incierto y no prefijado de antemano del todo - sin nadie con espaldas anchas a quien echarle la culpa si algo va mal. Eso no hay contrato tradicional que lo soporte y deberá ser sustituido por contratos abiertos y mucha, mucha, confianza. Es decir, hemos de ir, no hay otra, a la relación persona-persona, no empresa-empresa.
¡Otra cosa es ver cómo se logra esa confianza la primera vez! - quizá al cliente hay que irlo convirtiendo poco a poco, desde un primer proyecto, con un contrato tradicional, pero que se va desarrollando con los preceptos artesanos de forma paulatina... ¿evangelización?
Este es otro principio de lo más subversivo. Asumir que un proyecto no tiene un alcance cerrado de forma precisa, y que debe ir ajustándose, en tareas y resultados, a medida que se va desplegando, puede ser un hueso difícil de tragar pues es renunciar a la referencia con la que se puede apretar al contratista (las dos palabras están escogidas premeditadamente). Pero es que la propia esencia de la metodología base de un proyecto artesano, recordemos los proyectos son conversaciones, te lleva a esa dinámica de tener que acomodar cambios a medida que aparezcan. Y reconozco que esto es un reto colosal para un gestor de proyecto que, seamos realistas y tengamos los pies en el suelo, tiene que acabar un proyecto en un plazo y con un balance coste/beneficio razonable.
Valorar más la respuesta al cambio que el seguimiento de un plan
Y los 12 puntos del manifiesto (Me permito llamar la atención sobre los nº 4, 5, 6, 9, 10 y 11)
1) Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
2) Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
3) Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
4) Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
5) Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
6) La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
7) El software que funciona es la principal medida del progreso.
8) Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
9) La atención continua a la excelencia técnica enaltece la agilidad.
10) La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
11) Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
12) En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.
Y si te has tragado este ladrillo no puedo sino admirar la paciencia que has demostrado. Si además te ha gustado, ya es la leche... y si además dejas un comentario pues ya no se como calificarlo. En cualquier caso, de verdad, muchas gracias.
y bueno... tanta correr, reconozco que he quedado un poco cansado.
Entradas relacionadas:
15 comentarios:
Estoy muy de acuerdo con lo que expones.
Aprovecho para sugerirte que, completando el paralelismo que expones --y en relación con mis observaciones a la entrada anterior sobre el oxímoron "consultoría industrial"-- cambies "consultoría artesana" por "consultoría ágil" ;-)
Me encanta el manifiesto de desarrollo ágil, y me gusta el paralelismo que le has encontrado. Cuando yo estaba en esto del desarrollo de software intentaba aplicarlo.
Me gusta el punto 11, aunque ya veo que tu no lo has destacado. Creo que no hay que basar el desarrollo en esfuerzos heroicos, sino en tener un proceso tan efectivo que cree valor continuamente, las 40 horas de la semana. Irte a casa diariamente, sin portátil adosado, a tu hora, a disfrutar de la familia, y con la sensación de tranquilidad de que el proyecto avanza, es de las mejores cosas que me han pasado.
@josempelaez, también a mí me gusta más "ágil" pero ahora es un poco tarde para cambiar. De todas formas recojo tu sugerencia y a partir de ahora usaré ambos términos
@Josu, gracias. Cierto, el punto 11 es destacable pero para cualquier tipo de actividad. El post se centraba más en resaltar puntos específicos de contacto, por eso no lo he destacado especialmente. Me gusta lo de "esfuerzos heróicos" ;-)
Muy buena reflexión. Me gustan los 4 puntos que expones porque suponen construir sobre relaciones de confianza: confianza en las personas, en su conocimiento, en el saber hacer y en las actitudes.
Cuando esta confianza no existe, la sustituímos por herramientas sofisticadas, planes detalladamente ambiciosos y sistemas de información desmesurados. Demasiado lastre para conseguir ser ágil.
Yo tanto en el planteamiento de la consultoría ágil como en el desarrollo ágil no dejo de pensar en que lo que estamos haciendo es volver a ser honestos.
No se si es prejuicio o no pero el modelo tradicional/industrial me produce la sensación de mentira, de actuación, de fingir lo que no es. Ya sea consultoría o desarrollo. Siempre parece que fingimos ser más de lo que somos, saber más de lo que sabemos, ofrecer más de lo que podemos...
no se, seré yo...
@Anna, eso es, el enfoque atractivo de los métodos ágiles: que se basan en equipos autogestionados, es decir que no pueden funcionar sin confianza, competencia, conocimiento, ir al grano, resultados, ... sin lastres como tú dices
@lboisset, sí a veces parece que es como algo que va degenerando. Es otra consecuencia de intentar paquetizar y clonar indiscriminadamente: para diferenciarte tienes que exagerar, por no decir mentir directamente.
Gracias por los comentarios
Buenísimo desarrollo y enlace con el post anterior.
Bajo mi punto de vista, el principal problema lo encuentro en el segundo principio.
Me da la sensación de que por pequeño o cercano que sea el cliente, cada vez se tiende más a "cerrar" en todos los aspectos el resultado final antes de la contratación del servicio. Los clientes tienden a asegurar costes y en lo posible, resultados, exigiendo al redactor del contrato, propuestas o presupuestos con mucho trabajo tras ellas y que incluyan la responsabilidad de hacer frente a posibles imprevistos (O errores en esa elaboración previa).
Como bien dices ganar esa confianza hoy en día, sobre todo la primera vez, es el paso que veo más importante y más complicado para establecer esa relación persona - persona que caracteriza la consultoría artesana. Por lo menos como la voy entendiendo yo desde que os sigo ;).
Un saludo.
@Felipe, gracias. Los clientes están muy escarmentados de que el consultor le diga a mitad de proyecto que determinado tema no entra en el alcance inicial y que se factura aparte. Es normal que intenten cerrar el alcance (resultados) al máximo ya que es la única arma que luego pueden utilizar en caso de incumplimiento o mala calidad. Yo también lo veo como un gran escollo al que, como siempre, hay que superar paso a paso y en pequeñas aproximaciones, que es más o menos lo que comento en el post.
Creo que es muy acertado el paralelismo porque supone que ya hay corrientes que se mueven en territorios cercanos. Sin embargo, no creo que la "agilidad" quede tan cerca de la artesanía. El tiempo para hacer y pensar me parece algo que debe distinguir a la artesanía. Es algo así como considerar si, sin más, la artesanía acompaña a la liquidez de nuestro tiempo o si, reconociendo que eso es así, busca una alternativa a través de otro tipo de servicio.
Paralelismo muy interesante y acertado, Luis. Me ha gustado mucho.
Solo hay dos temas sobre los que me gustaria agregar algun comentario:
1) Estoy en parte de acuerdo con Julen en que la agilidad no es un atributo tan "artesano". Sabes que es un debate viejo en nuestro taller. No se, es algo complejo, pero me imagino al consultor artesano queriendo masticar lentamente el proyecto pero sufriendo al mismo tiempo los rigores de la presión-tiempo. Quizas la solución está en buscar proyectos que admitan un timing más artesano, pero está claro que los plazos en consultoria son lo que son.
2) Este asunto de las metodologias me tiene de cabeza. Voy a introducir un contrapunto en la cuestión. Es cierto que tenemos que desplazar el foco a la conversación, pero ciertas metodologias son validas y útiles en la medida que sirvan de molde para pensar y se apliquen ordenada y con todas sus consecuencias. Como consultores hemos visto a mucha gente que al segundo paso de intentar adoptar una "metodologia", se cansa, empieza a "conversar", y entonces dice que la metodologia no le vale. ¡¡hay metodologias muy buenas!! a las que yo no le agregaría una coma... y lo que hay que hacer es tener la disciplina de aplicarlas. Decimos que no nos sirven, y resulta que no hemos pasado del tercer punto.
A mi me gustan las metodologias por su capacidad de ordenar la reflexión y la implantación. Su fuerza esta precisamente en seguirlas, respetarlas... y claro, conversar alrededor de ellas pero no para cambiarlas o denostarlas como algo rígido. En fin, es un tema interesante, que admite muchas lecturas...
@julen, creo que no debemos asociar agilidad sólo con hacer las cosas rápido (aunque es discutible que esa asociación sea automática - pero no es eso sobre lo que quiero argumentar). Lo relevante, en mi opinión, son los puntos de contacto y coincidencias respecto a trabajar sin lastres, desde la simplicidad, valorando la relación real/personal sobre la formal, "a pelo" y parafernalias las justas.
@Amalio, ya te echaba de menos ;-)
Sobre el punto 1 de tus alegaciones creo que lo que he comentado a Julen lo responde. Lo relevante en lo ágil no es la velocidad sino la simplicidad
Respecto al 2 no creas que yo soy antimetodológico por definición- Por supuesto que hay que tener un marco de referencia pero que no te tape el cuadro ni te impida pintarlo. Desgraciadamente, en demasiadas ocasiones, la aplicación de la metodología porque sí ha llevado a hacer proyectos mal.
Gracias por pasaros. Seguimos
Como siempre, últimamente, llego tarde y veo que todo está muy bien dicho.
Lo primero es lo primero, y te he de decir que después de tanto tiempo sin apenas escribir estás que te sales, ¡vaya dos posts magistrales!
Algo si añado, yo creo que la agilidad no es rapidez, agilidad es "cintura", adaptación y capacidad de reacción, recursos ante las incidencias. No veo que se deba asociar a correr, prisas y presión de tiempo. Por otra parte, para se ágil has de ir ligero... pura artesanía.
Sobre los métodos, metodologías. La metodología base de cualquier otra es la epistemología, el pensamiento sobre cómo pienso. Un consultor es un metodólogo que, por supuesto, cuestiona sistemáticamente cualquier metodología para verificar si ajuste al caso. Eso creo que concilia esa capacidad de adaptar y la relativizar cualquier metodología. No la hay buena ni excelente por sí misma. Siempre depende del caso. Ese es el criterio más metodológico que existe.
Qué bien que escribas así de nuevo. Un abrazo.
Hola,
Me encanta tu planteamiento y estoy de acuerdo con él. El problema reside en la estandarización del modelo que propugnas.
Si yo digo que contrato consultores para hacer X, todo el mundo se monta en la cabeza la idea de consultores tradcionales.
Si digo que he contratado un consultor artesano ¿qué imagen tendrá el resto de la empresa? ¿y mi jefe?
Hay que conseguir que el mercado "reconozca" el buen hacer y la capacidad de aportar soluciones de la consultoría artesana para que esta funcione de verdad.
@mkl, nunca es tarde si la dicha es buena. Te agradezco mucho tus palabras, reconozco que llevaba un bache en el blog. A ver si puedo mantener el ritmillo de al menos un post semanal.
Por otra parte, coincido plenamente contigo en que agilidad no implica correr por correr y la metodología como algo a ser cuestionado y adaptado a cada situación. No añado más porque lo has expresado perfectamente.
@Jaime, entiendo perfectamente tu razonamiento. EL nombre desde luego no es muy "sexy" para determinados entornos y sin duda es uno de los problemas más graves que habrá que gestionar (no el nombre, sino que el "concepto" cale y se reconozca)
Algunos de nosotros son muy radicales y directamente descartan trabajar para esos entornos. Yo soy, en ese sentido, más moderado, prudente y, creo, realista y no renuncio. Hay que empezar poco a poco, y que el concepto vaya empapando a las organizaciones donde sea más complicaodo hacer entenderlo.
Gracias por vuestros comentarios
Método, procedimiento, instrucción, orden, documentación, predicción, planificación, aseguramiento… confianza?
Cambio, adaptación, diálogo, comunicación, flexibilidad, agilidad, ductilidad, maleabilidad, efectividad… confianza?
Velocidad, rapidez, celeridad, rendimiento, productividad, eficiencia, agitación, confusión, atolondramiento… confianza?
Publicar un comentario