gestión de proyectos

He venido a hablar de mi libro: Efectividad KENSO

por

«Es que pasa el tiempo, se acaba el tiempo, entra la publicidad, entran unos vídeos absurdos que todos hemos visto ya, y no se habla de mi libro. Pues entonces, a qué he venido yo aquí».

He estado repasando la famosísima (al menos si estás en España, y si tienes ya una edad… porque esto fue hace ya 30 años, glups) escena que se produjo en un programa de entrevistas en las que el autor Francisco Umbral le reclamaba a la presentadora, Mercedes Milá, que cuándo se iba a hablar de su libro. La escena completa está aquí (es deliciosa).

Desde entonces «yo he venido aquí a hablar de mi libro» ha quedado en el lenguaje popular como sinónimo de «yo vengo aquí con el único interés de hablar de lo mío, y lo demás me da igual».

Bueno, pues hoy yo he venido a hablar de mi libro, aunque no es que todo lo demás me dé igual.

Pero es que si todo va bien, este próximo miércoles 25 de enero llega a las librerías (físicas y virtuales, en formato papel y en formato ebook) mi (nuestro; de Quique, Jeroen y mío) libro «Efectividad KENSO». 

La cuestión es que, aparte de hacértelo saber (porque igual te resulta interesante su lectura: la info del libro la tienes aquí), quería aprovechar para compartirte una reflexión sobre eso de escribir un libro.

Porque, la verdad, nunca pensé que yo lo haría.

Es verdad que he autopublicado un par de cosas: pero Skillopment es una recopilación de artículos cortos, y La Rueda de la Vida es más un cuaderno de trabajo. También he participado en libros colectivos, aportando un capítulo.

Pero escribir un libro «de verdad» es otra cosa.

En mi mente, un libro era un proyecto demasiado difícil. No me tengo por una persona constante. Y una cosa es escribir cosas para el blog, o la newsletter (escribes, publicas y hasta luego Mari Carmen), y otra es pensar en una estructura, irle dando forma a lo largo de las semanas, que todo tenga coherencia, no perder la motivación en el camino… 

Buf.

Pero mira, está claro que era una creencia limitante. Apoyado en el trabajo conjunto con Quique y Jeroen, y haciendo una buena labor de «trocear» el contenido para poder ir avanzando de a poquitos… llegamos al final.

Siempre se dice que la mejor manera de comerse un elefante es, precisamente, a trocitos… y en este caso así ha sido.

No quiere decir que todo haya sido coser y cantar, pero al final el león (o en este caso el elefante) no era tan fiero como lo pintaba.

También hay una frase que me gusta repetir: «Nadie construye una casa; lo que haces es poner un ladrillo, luego otro, luego otro… y al final, como resultado, obtienes la casa».

Nadie «escribe un libro». Lo que haces es que, con eso en mente, trabajas para transformar ese objetivo de llegada en tareas mucho más manejables y concretas. Las más cercanas las puedes definir ya, las más lejanas las irás viendo… pero todo es un camino de acciones concretas que puedes abordar.

Pim, pam, pim, pam… hasta que llegas a donde querías.

Nadie «escribe un libro», pero si te lo montas bien acabas con un libro en las librerías.

Y yo, la verdad, me siento muy orgulloso del proceso.

La columna izquierda en proyectos de transformación

por

Hace tiempo, en un proyecto, empezó a suceder una de esas cosas tan habituales: uno de los agentes involucrados empezaba a actuar de forma… incoherente. De palabra, todo era compromiso con el proyecto, apoyo a tope, al 100% de acuerdo. Pero la realidad de sus actos no cuadraba con su discurso.
Decir si, pensar no
Algo pasaba. Quizás debíamos abordarlo antes de continuar. Y así lo planteé a los responsables del proyecto. Su respuesta: «no podemos ponernos ahora a cuestionarnos esas cosas. En un Comité ya dijeron que estaban de acuerdo… así que hay que seguir avanzando».
Por supuesto, seguimos avanzando… para nada. Porque las declaraciones en los comités se las lleva el viento, y lo que quedan son las acciones en el día a día.

La columna izquierda

En el ámbito del coaching se usa una herramienta llamada «la columna izquierda». Digamos que tomamos una hoja y la dividimos en dos columnas. En la derecha ponemos lo que una persona hace o dice; sus comportamientos observables. Y en la izquierda, ponemos su discurso interno: todas las ideas, creencias, miedos… que a veces de forma consciente y otras de forma inconsciente son el origen de su comportamiento observable.
What I say
El problema, claro, es que mientras la columna derecha se puede observar, la columna izquierda está oculta: solo la conoce la otra persona, y eso en el mejor de los casos. Lo más que podemos hacer es plantear hipótesis e indagar, tratando de descubrir y entender qué hay en ella. Y es que cuanta más luz arrojemos sobre esa columna izquierda, más fácil será dar con la tecla que realmente movilice la acción de la otra persona.
Volviendo al ejemplo del proyecto que planteaba, era evidente que había algo no declarado en la columna izquierda. Algo que hacía que lo que se decía y lo que se hacía no coincidieran. Era necesario indagar en qué era ese algo, entender por qué estaba sucediendo esa incoherencia. Solo desde ahí se podía hacer algo al respecto.

Abriendo el melón de la columna izquierda

El problema es que indagar en la columna izquierda… no es cómodo. Requiere tiempo, trabajo, confianza, mano izquierda. Las cosas que están en la columna izquierda suelen tener un componente emocional. Suelen ser ideas y creencias arraigadas, susceptibles de generar rechazo cuando se verbalizan. Por eso nos cuesta sacarlas, o dejar que otros las vean.
¿Y si nos dicen algo inconveniente? ¿Y si nos obliga a replantearnos las cosas? ¿Y si descubrimos algo que no nos gusta, o algo que no sabemos manejar, incluso algo que directamente pone en riesgo el proyecto? Quita, quita.
Por eso mucha gente no quiere «abrir ese melón», «reabrir viejos debates», «remover la mierda» o «abrir la caja de Pandora». Mejor actuar como si eso no existiese…
Caja de Pandora
Pero claro, la cuestión es que sí existe. Enterrar la cabeza como un avestruz no hace que desaparezca. Y tarde o temprano acaba reventando.

Los cimientos de un proyecto de transformación real

Como la parábola de la Biblia, podemos edificar nuestros proyectos con cimientos sólidos, o hacerlo sin cimientos. Aparentemente los proyectos sin cimientos avanzan sin problemas; y de hecho más rápido. Desde un punto de vista superficial, es más que suficiente. Mucha gente se conforma con eso, con proyectos que avanzan en apariencia.
La prueba de fuego vendrá, claro, cuando vengan las tormentas. Entonces, el proyecto sin cimientos caerá como un castillo de naipes. ¿Por qué las cosas no funcionan como se suponían que tenían que funcionar? ¡Si lo hicimos todo bien! ¡Si todo el mundo estaba de acuerdo! ¿Por qué ahora resulta que no hacen lo que deben?. Y ahí tendremos, después de invertir esfuerzo, tiempo, dinero, energía… un proyecto frustrado más.
Casa en roca
Así que si quieres abordar un proyecto de transformación real, con voluntad de impacto y permanencia… hay que dedicar tiempo a los cimientos. A tener conversaciones francas, tanto al inicio del proyecto como durante su desarrollo, que permitan poner tanta luz como sea posible a las columnas izquierdas de todos los implicados. Y a abordar todas las cuestiones que sean necesarias, por difíciles o incómodas que puedan ser, antes de seguir avanzando.
Porque si no lo hacemos, si hacemos «como si nada»… correremos mucho; pero no llegaremos a ningún sitio.
PD.- Como ves, he añadido un episodio del podcast Diarios de un knowmad dedicado a este tema. Si te gusta, puedes suscribirte en iVoox y en iTunes, comentar, recomendar, compartir…

El management y los huevos

por

Hace no demasiado tiempo comer huevos era algo que había que hacer con prudencia. Que si demasiada proteína para el hígado, que si ojo con el colesterol… Luego no, luego resulta que comer huevos es estupendo y no causa problemas. Salvo que tengas enfermedades coronarias, que entonces bueno, mejor no. Entonces… ¿es bueno o es malo comer huevos? Y más concretamente, ¿cuántos huevos puedo comer a la semana? Pues depende. Porque comer huevos tiene cosas buenas, y tiene cosas malas. Y a lo mejor no depende tanto de los huevos, como de ti.
Me venía esto a la cabeza leyendo la noticia de que IBM, que en su día fue pionera en la política de trabajar de forma remota, está ahora dando un giro y promoviendo (a la fuerza ahorcan) que los equipos trabajen juntos de forma presencial. Hace no mucho leía algo parecido referido a si es bueno trabajar en «open spaces» o si es malo. Y podemos aplicarlo a casi cualquier decisión de gestión. Hay quien dice una cosa, hay quien dice lo contrario. Lo que antes era bueno, ahora resulta que no. Y a lo mejor pasado mañana sí. Entonces… ¿qué hago yo?
Los humanos, y las organizaciones, lidiamos regular con la incertidumbre. Queremos certezas. Queremos que nos digan qué tenemos que hacer para que nos vaya bien. Buscamos las recetas infalibles, los consejos que no fallen, los benchmarks que nos aseguren que por lo menos no estamos haciendo nada distinto de los demás, las metodologías impecables, los gurús del momento que bendigan nuestras iniciativas. Y con toda seguridad que, sea lo que sea lo que nos estemos planteando, encontraremos algún experto que afirme lo que queramos, un «estudio» de alguna «universidad americana» (aunque sea pequeñito y poco significativo y cogido por los pelos, pero estudio científico al fin y al cabo), un libro editado por algún brillante escritor de management, un curso donde nos enseñaran a hacer las cosas «de forma correcta», una cita de algún autor clásico (¿real o inventada?), una encuesta que diga que es una buena idea (aunque se haya hecho a cuatro amigos), un consultor que te diga que él lo ha hecho con varios clientes y les va de fábula, unos cuantos «casos de éxito» contados a bombo y platillo, varios artículos en las revistas del ramo y una miríada de contenidos en redes sociales (refritos de refritos) que apoyen esa idea…
Bueno, qué alivio. Ahí tenemos nuestras certezas. Ya podemos gestionar, ¿verdad? Lo malo es que esas «certezas» no son tales, por mucho que queramos darles la apariencia de que lo son, y sirven solo para apaciguar nuestra inquietud. De hecho, casi con toda seguridad, podríamos encontrar un buen número de «certezas» similares que apoyasen la tesis contraria. Porque la realidad es que cualquier curso de acción que emprendamos tendrá sus cosas buenas, y sus cosas malas; y no hay forma de saber a priori cuál de las dos pesará más. Porque encima, en un mundo complejo, las interrelaciones son tantas que lo que puede ser bueno para mí puede no serlo para ti, y viceversa. O lo que funciona hoy puede que no funcione mañana. Pero eso, a quien te vendió la certeza, le va a dar igual; ellos no van a estar ahí cuando apliques sus recetas y no funcionen.
Pero entonces… ¿qué hacemos? ¿Cómo vamos a tomar decisiones, sin tener ninguna certeza? ¡Qué angustia! Y sin embargo creo que, una vez aceptamos esa incertidumbre, nos encontramos ante un panorama liberador. Como no hay un «camino correcto», no tenemos la presión de elegir «bien». Podemos apostar por cualquier curso de acción, y ver qué pasa. Con prudencia, sí, por si hay que dar marcha atrás. Atentos a los resultados que vamos obteniendo, para corregir el rumbo a medida que avanzamos. Con humildad, conscientes de que podemos equivocarnos, pero también aprovechando las cosas que sí funcionan. No tenemos que ser perfectos, porque de hecho es imposible que lo seamos.

¿Es un curso lo que necesitas?

por

Hace poco comentaba con un conocido una posible colaboración. Estaban pensando montar un «curso de ventas» para un colectivo bastante grande, y me preguntaban que cómo lo veía yo. Respondí de la forma más honesta que fui capaz, aun sabiendo que mis probabilidades de éxito eran pocas.
Estas son las reflexiones textuales que les trasladé:

  • Para mí el enfoque es más de «cambio de cultura» que de «dar un curso». Puede (o no) que un curso sea necesario, pero seguro seguro que no es suficiente.
  • Para poder plantear soluciones hay que ir a la raíz del problema. ¿Se ha investigado dónde está el origen del «no vender»? ¿Se ha trabajado con el colectivo, con sus responsables, incluso con los clientes…? ¿O directamente se ha hecho una presunción? «No venden porque no saben; si les damos un curso, venderán».
  • Parte de la implantación de «soluciones útiles» pasa por la co-creación: es decir, trabajar con los colectivos afectados (el propio colectivo, en este caso; quizás clientes, y responsables, etc) y que sean ellos los que propongan cosas para hacer. Quizás propongan un curso. Pero quizás propongan otras muchas cosas que desde un despacho ni se nos ocurren, porque no estamos en su día a día. Y al ser «sus ideas», la probabilidad de que funcionen se incrementa…
  • Creo que importa mucho el enfoque experimental en la implantación de ideas: pensar una serie de medidas, probarlas de forma rápida y barata con pilotos… y la que funcione se potencia, y la que no funcione se abandona. Si se buscan enfoques masivos/definitivos («un curso para todo el colectivo») es más difícil acertar.
  • Del mismo modo, creo que el cambio funciona mejor si se empieza pequeño y luego se crece. Coger a los 20, 50 o 100 individuos más motivados para la venta, y empezar a trabajar con ellos, ver lo que funciona y lo que no. Y cuando esos individuos, y esas áreas, empiecen a obtener resultados… se va generando un efecto bola de nieve que permite ir incorporando a nuevos «fieles». Usar un «curso masivo» con un colectivo que no tiene interés es tirar el dinero: sí, les has llevado a un aula, puedes justificar que «les has formado»… pero no es real.
  • Hay que pensar de forma sistémica. Queremos que las personas vendan… ¿es la «habilidad para la venta» un rasgo que tengamos en cuenta a la hora de seleccionar? ¿cómo estamos incentivando las ventas? ¿qué información les damos sobre la evolución de sus ventas? ¿Cuál es la actitud de los responsables hacia la venta? Etc.
  • Los esfuerzos de cambio cultural solo tienen sentido si se sostienen en el tiempo, si hay consistencia. Si hoy damos un curso, y mañana pasamos a otra cosa… es tirar el dinero.

En fin, como ves son varias cosas pero todas en la misma línea: si hay interés real en cambiar las cosas, hay mucha tela que cortar. Alguien que se dedique a «vender cursos» no lo va a plantear así (le interesa «colocar» el curso, cobrar… y aquí paz y después gloria)… pero honestamente es como yo lo veo. Si crees que podemos profundizar en todo esto de cara a transformarlo en un proyecto ya sabes dónde me tienes.

Tal y como suponía desde el primer momento, mi enfoque no «cuajó»; y lo cierto es que no sé si acabaron encontrando ese «curso de ventas» que buscaban. Lo que sí me atrevo a pronosticar es que, si lo hicieron, el impacto será, en el mejor de los casos, pequeño y efímero.
La verdad es que por un lado me sentí bien exponiendo mi visión, sin cortapisas. Un poquito de «design thinking», un poquito de «agilidad», un poquito de «gestión del cambio»… «Mira, esto es lo que creo, y en esto creo que te puedo ayudar; si no consigo convencerte y no vamos a estar en la misma onda, mejor que busques a otro». Por otro, claro, siempre te queda la duda… ¿fui demasiado «asertivo»? ¿podría haber modulado mi discurso para «pillar cacho»? ¿hubiera merecido la pena?

Trece ideas de Scrum que puedes aplicar en tu gestión

por

Scrum por allí, Scrum por allá… llevo oyendo hablar de Scrum mucho tiempo ya, “una metodología de desarrollo de software”, “tiene que ver con el mundo de agile”, “cosas de techies”. En definitiva, oyendo campanas pero sin haber dedicado nunca tiempo a profundizar lo suficiente.
Bueno, ahora ya sé de dónde vienen las campanas 🙂 He puesto foco durante unas horas a entender mejor que es eso de Scrum (gracias a este curso online, y a leer la guía oficial de Scrum), y cómo funciona. Efectivamente, Scrum es una metodología de desarrollo de producto (normalmente vinculado al mundo del software) que se enmarca dentro de la filosofía Agile. Diría (y aquí si algún experto me tiene que corregir que lo haga) que es una forma (¿la que más éxito ha tenido?) de “aterrizar” la filosofía del manifiesto ágil en algo más concreto y funcional.
Ahora bien, es evidente que Scrum tiene su origen y su “caldo de cultivo” en el mundo del desarrollo del software, y se ve claramente que muchas de las cosa que plantea es ahí donde tienen todo el sentido del mundo, y donde los expertos lo explotan mayoritariamente. Lo que me iba cuestionando a medida que leía era: ¿es aplicable Scrum a otros ámbitos, a la gestión de proyectos menos técnicos? Algo me dice que sí, que la dinámica de trabajo puede ser extrapolada (con más o menos “ajustes”).
(Pulsa aquí si quieres ver una introducción breve a las metodologías ágiles y a Scrum)
Fruto de esa reflexión, y más allá de que se pueda aplicar la metodología de forma más o menos estricta, he extraído estas trece ideas de Scrum que se pueden aplicar a la gestión de cualquier proyecto:

  • Ten siempre el valor aportado al cliente como vara de medir: En Scrum, los elementos del product backlog se priorizan en función del valor que van a aportar al cliente. Lo que más valor aporte, se busca hacer cuanto antes mejor. El objetivo que persigue el “producto incremental” siempre es buscar aportar el mayor valor posible, cuanto más tangible mejor. La definición de requerimientos, el feedback en las revisiones… siempre está orientado a lo mismo. Esta “obsesión por el valor” es algo que no debe perderse de vista nunca en el desarrollo de un proyecto. ¿Cuántas veces, en el fragor de la batalla, nos miramos demasiado el ombligo y nos olvidamos de para qué estamos trabajando, nos enredamos en discusiones bizantinas que no llevan a ningún sitio, o nos emocionamos con detalles que apenas le aportan a nadie? Pues eso, no perdamos la brújula de la aportación de valor.
  • Organiza tus proyectos como sucesión de miniproyectos cerrados: se definen los “sprints” como periodos de una a cuatro semanas de trabajo sobre una serie de elementos del backlog (elementos que se definen al principio del sprint y que no se tocan) que, al finalizar, dan como resultado una “versión funcional del producto”. Este enfoque elimina la incertidumbre, los cambios de prioridades, el pasarse la vida replanteándose cosas… y permite al equipo centrarse en “producir” sin interferencias del exterior durante el sprint. Nos centramos en lo que hemos definido para el sprint, nos aislamos del exterior (la relación con el exterior es cosa del product owner) y sacamos el producto que nos habíamos propuesto sacar. Lo que haya que cambiar, lo que haya que corregir, las nuevas prioridades… ya se abordarán en el siguiente sprint (que, como llegará pronto, en ningún caso nos va a suponer un gran problema).
  • Entrega producto valioso desde el primer momento: además de funcionar como una sucesión de “miniproyectos”, en los sprints el objetivo es que al terminarlo haya un resultado final. Con cada “miniproyecto” el resultado será mejor y mejor (iteraciones), pero desde el primer momento se busca resolución y no hay que esperar a que transcurran n meses para tener algo tangible o darse cuenta de que, oh, no has ido por el buen camino. De hecho, idealmente, podrías abandonar el proyecto al terminar cualquier “sprint” y el resultado sería valioso por sí mismo. De esta forma, todo el trabajo que haces tiene sentido y aporta valor por sí mismo.
  • Feedback, feedback y más feedback: igual que en el caso del design thinking, el objetivo es que tras cada “sprint” se produzca una revisión que permita validar que efectivamente el resultado incremental aumenta el valor, ver lo que funciona y lo que no, y a partir de ahí tomar decisiones para la siguiente ronda. Este ciclo permanente de “producto funcional” y “feedback” permite ir avanzando y adaptándose de forma continua. No olvidemos exponernos al veredicto de los usuarios, no tengamos miedo a recibir sus opiniones: es lo único que nos sirve para mantener el rumbo.
  • Las prioridades las define uno y nadie más: el product owner es la figura encargada de interactuar con los “usuarios/clientes” (stakeholders en general), de identificar sus necesidades, de llegar a compromisos con ellos respecto a sus prioridades… y una vez filtrado todo ello, de trasladarselo al equipo de forma unívoca. Es el único que lo hace, la bisagra que une y a la vez aísla a los stakeholders y al equipo, el único interlocutor válido. Esta figura recupera el principio clásico de la “unicidad de mando”, y evita que haya más gente “metiendo la cuchara” y mareando al equipo, cambiando prioridades y tratando de arrimar el ascua a su sardina.
  • Protege al equipo: el equipo debe centrarse en trabajar, y aislarse en la medida de lo posible de interferencias e incertidumbres. Esto es labor del product owner, que centraliza las relaciones del equipo con los stakeholders (evitando que éstos vuelvan loco al equipo) y cerrando el alcance de los sprints en las reuniones de planificación (proporcionando un escenario de estabilidad al equipo, mientras él absorbe nuevos requisitos, cambios en prioridades, etc… que retendrá hasta llegar al siguiente sprint).
  • Comunicación multidireccional constante: Scrum define en la metodología todas las ocasiones en las que se producen interacciones entre los miembros del equipo. Reuniones de planificación, reuniones de refinamiento, reuniones diarias, reuniones de revisión, retrospectivas. En todos los casos el objetivo es “poner encima de la mesa” las distintas visiones que se puedan tener (sobre dificultades, enfoques, cómo se va a trabajar) y llegar a acuerdos. Coordinación sobre la base de la comunicación permanente.
  • Deja que los que saben se organicen: el product owner es el que define las prioridades, pero a partir de ahí es el equipo de desarrollo el que determina cómo abordar esas prioridades, qué tareas realizar, cómo repartírselas, cómo coordinar sus distintas habilidades. Son los que mejor saben hacer las cosas, y no tiene sentido que venga nadie de fuera a organizarles el trabajo. La autonomía es una clave de la motivación, y la motivación es una de las claves de un trabajo bien hecho.
  • Los equipos necesitan estar equilibrados: el equipo Scrum debe reunir, entre todos sus miembros, todas las capacidades necesarias para resolver las tareas que tiene asignadas. Es decir, no debe depender de nadie externo para avanzar. De esta forma, está 100% en las manos del equipo ejecutar lo que decidan, y no se deben quedar parados esperando a que alguien les resuelva nada. Esta visión suele ser difícil de organizar en los proyectos (y más si pensamos en proyectos transversales, con gente “de distintos departamentos” con “distintos directores”), pero resulta fundamental si queremos que las cosas salgan adelante de forma ágil.
  • Presta atención a cómo trabajas, y corrige si es necesario: las reuniones de retrospectiva se centran, al finalizar cada “sprint”, en analizar el funcionamiento del propio equipo, de identificar qué cosas han ido bien y qué cosas tienen que ir mejor. Este foco tendemos a olvidarlo y más si va a ser fuente de conflictos; para darnos palmaditas todos valemos, pero exponer problemas a la cara de forma constructiva y aceptar nuestras equivocaciones ya nos resulta más difícil. Y sin embargo es fundamental si no queremos que los problemas se enquisten.
  • Respeta los procesos y las herramientas, aunque parezca aburrido : siguiendo con la idea de la autoconciencia, la figura del Scrum Master se encarga de asegurar que el proceso se siga “a rajatabla”, que se celebren las reuniones que se tienen que celebrar y se hagan de la forma adecuada. En los proyectos todo son buenas intenciones, pero es fácil dejarnos llevar por las urgencias, por la rutina, por el “esto ya nos lo sabemos” y el “bueno, esto me lo salto que tampoco pasa nada” y a la que nos descuidamos hemos descarrilado por completo, hemos dejado de aplicar las rutinas y los hábitos que nos habíamos prometido seguir y acabamos en el batiburrillo habitual.
  • No te olvides, trabajas con personas: otra de las labores del Scrum Master es “prestar atención a las personas”. Es decir, vigilar las dinámicas interpersonales dentro del equipo, e intervenir cuando sea necesario para reconducirlo. Esta labor pone de manifiesto algo que ya he comentado en alguna ocasión: somos personas trabajando con personas, es absurdo pretender que nos relacionemos como si fuesen máquinas. Hay filias, hay fobias, hay roces, hay momentos altos y momentos bajos… y tener a una persona cuya responsabilidad es precisamente estar atento a todo eso implica reconocer esa realidad.
  • Cuanta más información tenga el equipo, mejores decisiones podrá tomar: todo el proceso de Scrum se basa en la idea de que todo es compartido por todos. Todos ven el product backlog, todos definen el sprint backlog, todos ven el seguimiento diario, todos hacen las reuniones de revisión y de retrospectiva, todos dan su opinión respecto a cómo ejecutar el trabajo… No hay carpetas privadas, no hay “ángulos ciegos”, todo el mundo tiene toda la información necesaria para hacer su trabajo. Y así, normalmente, las cosas salen mejor.

Castillos de arena

por

Verano, «sol, arena y mar» que decía Luis Miguel. Confieso que la playa tiene para mí un efecto hipnótico. Será por aquello de ser de la Meseta, y ser contados los días que puedo disfrutar de ella. O por coincidir esos días en periodos de vacaciones, dados de por sí a la introspección.
Y allí estábamos, rodillas en la arena y palas en mano, excavando y amontonando, dando forma a unos castillos en la arena. Creatividad y trabajo compartido con los niños (benditos niños, que nos dan excusa para hacer determinadas cosas sin temor al «qué dirán»).
Terminamos el castillo. Los castillos, en realidad. Muy aparentes, un trabajo muy satisfactorio. Nos sentamos en la cercana toalla. Y niños ajenos que empiezan a revolotear; algunos para mirar con curiosidad e incluso admiración, pero otros con mirada aviesa. Joder, ¿por qué hay gente que es destructiva casi desde la cuna?. «Tchs, eh, ni se te ocurra». El niño mira desafiante, pero recula. Bien, hemos salvado el castillo.
De momento. Porque no vamos a estar sentados en esta toalla para siempre. Más pronto que tarde llegará un niño (o un adulto, que los hay muy tontos también) y pisoteará nuestro trabajo, reduciéndolo a un montón de arena. Y en el mejor de los casos será cuestión de horas que suba la marea y las olas lo devuelvan a su estado original.
Mientras recogíamos y volvíamos al apartamento, me dio por pensar en todos los castillos que he construido a lo largo de todos estos años. Los de arena, y los otros; los proyectos, las herramientas, las webs, los documentos. En todos los «niños» que los amenazaban con mirada aviesa, sólo refrenados por mi presencia. ¿Cuánto tardaron en pisotearlos? En el mejor de los casos… ¿cuánto tardó la marea en subir y hacerlos desaparecer?
Puede parecer un pensamiento desolador, y en cierto sentido puede llegar a serlo. Pero quizás lo relevante de ese castillo no radique en su (imposible) permanencia, si no el disfrute que nos proporcionó mientras lo ideábamos y lo construíamos. Lo cual, también, puede ser una lección interesante de cara a abordar futuros castillos.

Herramientas: no hay segunda oportunidad para una buena primera impresión

por

El otro día me dio por curiosear las opiniones de los usuarios de una app lanzada recientemente por gente que conozco. «Buena idea, regular ejecución, mal soporte», «Necesita mejorar. La idea es buena y funciona casi bien», «Necesita mejorar muchísimo», «Buena idea, pero malísima app», «Esta demasiado verde como para haberla lanzado a nivel nacional»… son algunas de las opiniones que se leen de los primeros usuarios. Sí, también hay alguna valoración positiva, pero el tono general es de decepción.
Inviertes un montón de dinero y tiempo en desarrollar una aplicación, haces un lanzamiento multitudinario, consigues que miles de personas se la descarguen… solo para encontrarse con un producto que funciona de aquella manera. ¿Cuántas de estas personas van a dejar de usarla, y no te van a dar una segunda oportunidad? Da igual que, como dicen los desarrolladores, «gracias a vuestros comentarios vamos ajustando la App para mejorar la experiencia como usuarios». Muchos de ellos no van a perder más el tiempo contigo.
Desde luego, no soy ajeno a estos problemas. Yo también he caído en ese mismo error. Te pones a diseñar algo que crees que es fantástico. Haces el esfuerzo de desarrollarlo. Lo lanzas… y resulta que la acogida es muy floja. Porque no funciona bien del todo. Porque es complejo. Porque no responde a las necesidades reales del público objetivo. Porque te has venido arriba con tus ideas sin tener en cuenta a quienes en definitiva son quienes tienen que hacer uso de la herramienta. Porque has querido correr, porque no has hecho las suficientes pruebas. Luego sí, intentas recopilar el feedback, intentas reconducir la situación… pero ya es tarde, eres prisionero de lo que ya has hecho, y encima has perdido la confianza de tus potenciales usuarios.
¿Cómo deberían abordarse estos procesos para minimizar el riesgo de una mala acogida? Estoy seguro de que existe un montón de literatura y metodologías que ya dan respuesta a esta pregunta (y sin embargo se ve que no se aplican lo suficiente). Yo, de mi experiencia, extraigo estos puntos:

  • Entiende bien la problemática: y con esto me refiero no a «lo que tú crees que es la problemática», sino «lo que el usuario cree que es la problemática». Es a ellos a los que hay que ofrecer soluciones. El despotismo ilustrado («yo sé lo que tú necesitas») no funciona. Hay que investigar, hablar con ellos, pasar tiempo a su lado, conocerles. Entender cuál es la china que les aprieta en el zapato. Primero porque así sabremos mejor qué es lo que tenemos que resolver. Y segundo porque en el propio proceso estaremos ganando aliados para el futuro, nos verán como alguien que «se ha molestado en entendernos» y no como alguien que «nos impone su solución».
  • Resuelve un problema cada vez: es mejor resolver un problema de forma incuestionable, que intentar resolver a la vez quince problemas dejándolos a medias. Escoge un problema, y diseña una solución sencilla, robusta, fiable, que el usuario compre. Si consigues resolverle un problema de forma consistente, ya está de tu lado. A partir de ahí sigue identificando problemas, y resolviéndolos con el mismo nivel de exigencia. Pero uno detrás de otro.
  • Busca el 20%: o «Keep It Simple, Stupid». Una solución simple va a tener mucha mejor aceptación que una compleja. Incluso si en el camino pierdes potencia. Ya sabemos que «si añadiésemos esto y aquello, los resultados serían aún mejores». Ya. Pero hay que centrarse en ese 20% de funcionalidades que resuelven el 80% del problema. Ya habrá tiempo de rizar el rizo, si realmente es necesario. Porque si de un problema resuelves el 80%, posiblemente deje de ser un problema y te puedas centrar en otra cosa.
  • Prueba las soluciones exhaustivamente: probar, probar, y probar. Necesitas un colectivo pequeño con quienes trabajar en el «piloto». No vale cualquiera. Tiene que ser gente implicada, que te ayude a testear la herramienta en todas las circunstancias posibles, y que te dé feedback. Hasta que los usuarios de ese piloto no estén extremadamente satisfechos (y se hayan convertido en unos usuarios intensivos), no se puede dar el siguiente paso. Si los que han estado involucrados en el desarrollo no están satisfechos… ¿qué crees que va a pasar con aquellos a los que tu herramienta «les cae del cielo»?

En este sentido, me gustó mucho esta visión de «minimum viable product» que vi en una presentación de Spotify.

spotify_mvp

Tienes que resolver problemas desde el minuto 1. Ya irás refinando la forma de hacerlo, ya le añadirás complejidad si es necesario. Pero tu producto, por sencillo que sea, tiene que mejorar la vida del usuario, y tiene que funcionar de forma impecable desde el principio. Si no, es muy probable que el potencial usuario te cierre las puertas.
En mi experiencia, hay un enemigo importante en todo este planteamiento: el tiempo. O mejor dicho, la presión por parte de «los que mandan» para que las soluciones se implanten «antesdeayer». Todos los pasos que definía antes requieren tiempo. ¿Cuánto? Indefinido. No se puede calendarizar una fase de exploración, no se puede calendarizar una fase de desarrollo, no se puede calendarizar una fase de pruebas. Porque no conoces el problema hasta que te pones a analizarlo. Porque no puedes resolver incidencias hasta que no empiezas las pruebas, no sabes qué va a pasar, no sabes cuánto te va a costar resolverlo. Pero esto es algo que nadie quiere oír, como tampoco quieren oír que «la primera versión sólo va a centrarse en un problema muy concreto». Quieren la solución «tope de gama», y la quieren ya.
Y eso hace que nos saltemos pasos. No preguntamos a los usuarios, porque «el problema está claro». Diseñamos de espaldas a ellos. Nos metemos en caros y complejos desarrollos sin haber validado nuestras asunciones (o aceptamos como «validación» que alguien en un comité simplemente no se negase). Hacemos un par de pruebas en una semana, ignoramos el feedback que nos den, y nos ponemos con la expansión. Y sacamos pecho en una reunión de seguimiento. ¡Hemos cumplido! Ahí está nuestra herramienta, que mira qué bien funciona (en la demo… y de hecho a veces la demo la hacemos con pantallazos en powerpoint «por si acaso los problemas del directo»), ¡y en el plazo que prometimos!. Luego empiezan los problemas, el «runrun» de que aquello no va bien, que es complejo, que en determinadas circunstancias no funciona, que tampoco me resuelve nada, que yo lo que necesito no es esto. El impacto que se supone que debería de tener no aparece por ningún lado. Y entonces nos ponemos a pensar «qué podemos hacer para enderezar el rumbo», y empezamos a pensar en «la inversión que hemos hecho para nada». Ya. A buenas horas.
Las cosas, para que salgan bien, hay que hacerlas de determinada manera. No sirven los atajos. Y quienes toman las decisiones (y quienes les asesoran, que muchas veces son parte del problema porque son los primeros que no dicen las cosas como son) deben asumirlo.

El gestor de proyectos es un enfermo mental

por

El gestor de proyectos es un enfermo mental. O debería serlo para hacer bien su trabajo. Más en concreto, sufrir de un trastorno de personalidad múltiple (que por lo visto ahora se llama de «identidad disociativa«).
He empezado a leer el libro «Project Management: absolute beginner’s guide«. En uno de sus capítulos iniciales se hace un repaso de los distintos roles que debe desempeñar un gestor de proyectos: es un planificador, un organizador, un centralizador de las comunicaciones, un gestor de aprovisionamiento de recursos, un facilitador, un persuasor, un solucionador de problemas, un paraguas que proteja al equipo del exterior, un coach para los componentes del equipo, un perro de presa que persiga compromisos, un bibliotecario que documente los avances, un policía que vigile el correcto desarrollo y actúe en caso de desviaciones, un vendedor, un gestor de riesgos…
Tienes que ser a la vez metódico y flexible, exigente y tolerante, cordial y borde, organizado y capaz de improvisar, social y asocial, empático y asertivo, tener visión global y visión de detalle. Y por supuesto, ser capaz de adaptarte a todos y cada uno de los stakeholders vinculados al proyecto y a los miembros del equipo, a cada una de sus formas de ver el mundo, sus necesidades, sus exigencias y sus (por qué no decirlo) chaladuras.
Lo dicho, tienes que ser un enfermo mental para poder ser todo eso a la vez, y así poder poner en juego cada una de tus múltiples personalidades según convenga. Y si no lo eres, tranquilo: lo acabas siendo a la fuerza :D.
Pd.- Voy a dedicar un proceso de «aprendizaje focalizado» a consolidar conocimiento sobre «project management», así que podéis esperar más reflexiones sobre este tema…

Un sembrador fue a sembrar

por

Un sembrador fue a sembrar lo mejor de su semilla; parte caía en el surco, parte en la orilla. La primera daba fruto porque el agua la asistía, la segunda se agostaba y se moría. /Ni es culpa del sembrador, ni es culpa de la semilla, la culpa estaba en el hombre y en cómo la recibía

Ando últimamente pensando mucho en la parábola del sembrador (en la que está basada la canción de Palazón que refiero al inicio).
El sembrador suelta la semilla, y depende de dónde caiga fructifica o no. Si el terreno es yermo, de nada vale su esfuerzo. La cuestión es… ¿hay algo que pueda hacer el sembrador para que ese terreno sea más fértil? ¿hasta qué punto debe esforzarse en conseguirlo? ¿en qué momento debe decidir que más vale dedicarse a buscar otros terrenos mejores, en vez de empecinarse en sacar un pobre rendimiento a un pedregal?
Porque como diría José Mota, «si hay que sembrar se siembra, pero sembrar pa’ná es tontería»

De consultores, directivos y proyectos

por

Leía hace poco este artículo en el que el autor defiende que «los consultores deberían buscarse un trabajo de verdad«. Lo cierto es que, en mi situación actual, estoy «disfrutando» de una posición privilegiada en la que conviven mi yo consultor (con ese punto de «externo», «ajeno») y mi yo personal interno (integrado en las rutinas y dinámicas de funcionamiento de la empresa). Y eso me hace reflexionar con frecuencia sobre esta dualidad, esos dos mundos que en muchas ocasiones funcionan de forma diferente y que se miran el uno a otro con recelo (y he de decir que muchas veces con razón, tanto para uno como para otro).
Hoy toca darle cera a los consultores 😀
El consultor, por naturaleza, vive en el mundo de la superficialidad. Aborda proyectos de más o menos duración, pero con fecha de caducidad. Está en una empresa por tiempo limitado, y por mucho que algunos se autodenominen «consultores de implantación», lo cierto es que en el mejor de los casos tutelan esa implantación (pero quien la ejecuta es la empresa), y normalmente se marchan antes de que esa implantación sea real (total, ya has cobrado la parte del león).
Porque las implantaciones de verdad, con el cambio que suponen, tardan. En paralelo, los consultores viven en el mundo de los estudios, de las bestpractices, de las conferencias, de la innovación, de las novedades del management. De lo que los anglosajones llaman «state of the art». Es extremadamente fácil cambiar el discurso, lo que uno vende… cuando simplemente te mueves en el mundo de las ideas, de los conceptos, de las metodologías.
Mientras tanto, las empresas llevan otro ritmo. Para empezar, como decía antes, las implantaciones reales llevan tiempo. Mucho tiempo. Hasta la implantación más sencilla (no digamos las más complejas) implica cambios en las formas de actuar, y todo eso tarda en cuajar. Pero es que además, por una mera cuestión de rentabilidad, los cambios tiene sentido «hacerlos durar», consolidarlos, sacarles provecho real. Si me ha costado tiempo y dinero implantar un determinado proceso, o sistema, o política, o lo que sea, y funciona… tendrá que funcionar durante x años antes de volverte a plantear cambiarlo. ¿Que eso significa que no estás «a la última»? Amigo, es que esa es una de las cuestiones relevantes… las empresas en general no necesitan estar a la última. Dicho de otro modo, «estar a la última» en todo implica tal coste (de tiempo, dinero y esfuerzo) que en muy pocas ocasiones están justificados.
Y aquí es donde chocan los dos mundos. El mundo feliz de los consultores, llenos de ideas y encima enfatizados por la necesidad de vender (¡a por el próximo cliente!) y de diferenciarse (¿cómo vendo algo que parezca nuevo aunque no lo sea?). Y el mundo real de las empresas, donde lo que necesitan es fiabilidad, cosas que acaben funcionando de forma solvente y sólida durante un periodo largo aunque no sea «lo mejor» ni «lo más novedoso».
Y entre medias, ay, los directivos. ¿Qué hacer? ¿Aplicar el sentido común, centrarse en «pocos proyectos pero bien hechos», o incluso en el mero «gestionar la normalidad» (sin proyectos de por medio)? ¿O por el contrario dejarse seducir (o directamente ser quien los trae) por consultores para implantar más y mejores proyectos, más nuevos, más brillantes, más innovadores, más…?
Y aquí otro poco de cera para los directivos.
Porque lo cierto es que hay demasiados incentivos para que un directivo se ponga en manos de muchos y variados consultores (y no hablo ya de incentivos directos, «si me contratas te llevas una parte» o similar). ¿Qué directivo se resiste a «dejar su huella» en la organización, en implantar un proyecto que lleve su nombre y tenga impacto para la posteridad? (porque el directivo no es tan volátil como el consultor… pero a veces también viene y va). O bien, ¿qué directivo se resiste a tener a su disposición un gran presupuesto, un gran equipo a su cargo, otros símbolos de status… y qué mejor excusa para ello que «implantar proyectos»? ¿Qué directivo se resigna a la sorda (¿y aburrida?) labor de ejecución, coordinación, control… de proyectos que hicieron otros? De hecho, ¿y si el gran jefe piensa que para eso simplemente no hace falta un directivo, su sueldo, su gran despacho, su presupuesto…?
Y así, en un montón de empresas se suceden (o peor aún, se solapan) los proyectos. No se ha terminado de implantar uno (pero de verdad) y ya nos estamos planteando otro que lo enmienda, lo mejora, lo lleva a otra dimensión. O cada directivo de cada área haciendo su guerra por su cuenta, a lomos cada uno de sus consultores, sin mirar ni a derecha ni a izquierda, impulsando cambios a veces en direcciones divergentes cuando no opuestas. Vendemotos y compramotos en feliz connivencia. Y embarcamos a las organizaciones un un carrusel de proyectos sin terminar, en un batiburrillo entre lo de ayer, lo de hoy, y lo de mañana, lo de uno y lo del otro, sin extraer de cada uno todo el jugo posible. Y por el medio, una sangría de dinero, de esfuerzo, de dispersión de energías y de motivación.
¿Quién le pone el cascabel al gato?