¿Es un curso lo que necesitas?

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?

Contenido relacionado:

Continue Reading

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

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”).

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.

 

Contenido relacionado:

Continue Reading

Castillos de arena

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.

Contenido relacionado:

Continue Reading

De las ideas al impacto: aterriza como puedas

El mundo de las ideas es fascinante. Realmente entretenido. Lees libros, lees artículos, reflexionas, analizas, das forma, matizas… puedes pasarte horas y horas dándole vueltas a conceptos, emocionándote a medida que van adquiriendo coherencia, y con la sensación de que “ahí hay algo realmente potente”. Es un ejercicio estimulante a nivel intelectual. Y también, reconozcámoslo, bastante intrascendente en sí mismo.

Da igual de lo que hablemos. Productividad, transformación digital, industria 4.0, knowmads, empresas centradas en los clientes, gestión relativa, estrategia, marca personal, storytelling, minimalismo, fotografía, educación… escoja usted la temática que más le motive, o la que más esté de moda. Se pueden llenar estanterías enteras de libros dedicados a rumiar una y otra vez sobre ella, habrá charlas y eventos donde se hable del tema, cursos, “expertos”, cientos y miles de artículos en blogs dando vueltas y más vueltas a conceptos, recomendaciones, presuntos “casos de estudio”…

Es fácil enredarse en esa maraña. Yo mismo lo hago con demasiada frecuencia. ¿Acaso no lo estoy haciendo ahora mismo, mientras escribo esto; y tú, mientras lo lees?

Las ideas son un espejismo. Nos dan la (agradable y placentera) sensación de estar haciendo algo, cuando en realidad no estamos haciendo nada. Estamos dando vueltas y vueltas en el mismo sitio, sin ningún impacto.

Y es trasladar esas ideas a la vida real (de los individuos, de las organizaciones) es difícil. Requiere esfuerzo, tiempo. Mancharse las manos, enfrentarse a personas, a dinámicas preestablecidas. Supone contrastar esas ideas (tan sólidas, tan coherentes en su mundo ideal) con la realidad, mucho más compleja, más árida. Supone, en definitiva, ponerse a prueba con muchas probabilidades de no triunfar. Ser “el hombre que está en la arena, con el rostro desfigurado por el polvo, sudor y sangre; el que se esfuerza valientemente, yerra y da un traspié tras otro pues no hay esfuerzo sin error o fallo”. Demasiado polvo, demasiado sudor, demasiada sangre. Con lo fácil que es todo desde la barrera.

Hay quien hace del mundo de las ideas su “modus vivendi”. Quien se dedica a predicar, pero no a dar trigo. Investigadores, profesores, críticos, escritores de libros, conferenciantes y gurús varios. Elevados en sus púlpitos, desde donde es fácil dar consejos sin tener nunca que poner a prueba lo que aseveran. Como también acostumbran a hacer muchos (demasiados) consultores, y no pocos directivos de empresas. Proyectos que se quedan en conceptos de alto nivel, en “debería hacerse”, en reuniones llenas de divagaciones, en ideas que parecen muy coherentes y muy lógicas, pero que no son nada sin ser traducidas a las tripas, a tocar las palancas que realmente generan impacto. Pensadores que no se dignan a dedicar el esfuerzo y el tiempo necesarios, con su correspondiente cuota de sinsabores, contratiempos y fracasos. A respirar el polvo, a sudar, a sangrar. Todo eso es sucio, incómodo, lento; con lo bonitas y relucientes que son las ideas. Normal que prefiramos quedarnos calentitos con nuestras pajas mentales.

Pero no hay transformación real si no hay acción. No hay impacto si nos quedamos atrapados en las ideas. El valor no está en las ideas, si no en lo que somos capaces de hacer con ellas.

Ideas. Acción. Transformación. Impacto.

Contenido relacionado:

Continue Reading

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

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.

Contenido relacionado:

Continue Reading

El gestor de proyectos es un enfermo mental

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…

Contenido relacionado:

Continue Reading

Un sembrador fue a sembrar

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”

Contenido relacionado:

Continue Reading

De consultores, directivos y proyectos

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 :D

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?

Contenido relacionado:

Continue Reading

Cuánto de técnico debe tener un directivo

No deja de ser un tema tan antiguo como el ser humano. Hace ocho años ya me refería al principio de incompetencia de Peter, pero reciéntemente ha vuelto a surgir el debate en el entorno cercano, lo que me ha llevado a darle una nueva vuelta al tema.

La cuestión: ¿es un directivo, en esencia, “intercambiable”? ¿Puede hacerse cargo hoy de un área de finanzas, mañana de un área de recursos humanos, pasado de un área de operaciones y al siguiente ser un director general? ¿Hasta qué punto puede ser ajeno un directivo a la especialización técnica del área que gestiona?

Obviamente, parto de la base de que todo es un contínuo. Que cuanto más pequeños son los equipos, y por lo tanto menos personas hay en ellos, más probable es que el directivo de turno tenga que “arremangarse” y tratar temas con elevado contenido técnico. A medida que los equipos son más grandes, es más probable que el tiempo del directivo se dedique casi al 100% a “tareas de gestión”.

Porque aquí está mi punto. La labor de un directivo tiene mucho de transversal. Hay que establecer estrategias, gestionar proyectos, gestionar equipos, presupuestos, comunicación, definir planes, indicadores, coordinar con otras áreas. Eso, en esencia, va a ser lo mismo sea cual sea el área que estés gestionando. La gestión es un “área técnica” en sí misma, una serie de conocimientos, habilidades, herramientas… que tienen que ver más con “la labor de dirigir” que con el contenido específico de “lo que estoy dirigiendo”.

Este “salto” es el que hace que en muchas ocasiones salga a la luz el principio de incompetencia de Peter. Excelentes técnicos que son promocionados a labores de gestión sin haber desarrollado ese conjunto de competencias. Allí, su conocimiento técnico pierde relevancia, lo que necesita es otro tipo de habilidades. Lo bueno es que, si se consiguen desarrollar, te permiten “romper” la barrera de tu área de especialización y saltar a otras diferentes.

¿Significa eso que a un directivo se le puede poner a la cabeza de cualquier área? En el extremo, me posicionaría en que sí. Obviamente, cualquiera con dos dedos de frente se da cuenta de que se gestiona mejor sabiendo “algo” del tema que gestionas que si no tienes ni puta idea, y el directivo será el primero en aplicarse el cuento. Pero ese “algo” no tiene que ser un conocimiento profundo, especializado, como el que tiene un experto técnico (que será normal, incluso deseable, que “sepa más” que su jefe). Es más una visión global, amplia, conectada además con otros campos. El nivel necesario para no decir tonterías, para enterarse de lo que le cuenta su equipo, para tomar decisiones de alto nivel. Porque esto es importante: las decisiones de pequeño nivel, el micromanagement, lo tiene que llevar su equipo; mientras tanto, el directivo aplica su propio cuerpo de conocimientos de gestión para la coordinación.

Contenido relacionado:

Continue Reading

Gestionar el presente, soñar el futuro, liderar el cambio

Vale, un título ligeramente grandilocuente, me doy cuenta. En realidad, estaba intentando homenajear a “El bueno, el feo y el malo”, identificando tres roles fundamentales en cualquier empresa. Los tres son necesarios, pero los tres son diferentes.

En primer lugar, alguien tiene que gestionar el presente. Es quien está metido en el día a día, quien se encarga de poner soluciones a los problemas cotidianos, de ser más eficiente, de hacer que las cosas fluyan. Es quien lidia con personas, con máquinas, con recursos financieros, con clientes, con procesos…Y, sobre todo, quien es responsable de los beneficios y la rentabilidad hoy, el que da de comer a todos los demás.

Por otro lado, es necesario que alguien esté pensando en el futuro. En diez, en cinco, en dos años hacia adelante. En cómo quiere que sea la empresa, en cómo se imagina la realidad. Aquí hay pocas cosas tangibles, pero por el contrario hay muchas ideas, tendencias que tener en cuenta, creatividad, asunción de riesgos. Mucho mirar al exterior, mucho otear el horizonte. Y este rol es tan importante como el anterior, porque de él depende la rentabilidad de mañana.

La cuestión es que estos dos primeros roles, siendo fundamentales, son esencialmente incompatibles. El que piensa en el hoy, es muy difícil que piense en el mañana. Primero porque “el hoy” requiere 100% de atención si se quiere hacer bien, no se puede/debe distraer uno con ensoñaciones. Y segundo, porque “el hoy” condiciona irremediablemente nuestra visión del futuro (como ilustran esta serie de curiosas postales). Es muy difícil que alguien que está metido en el día a día sea capaz de elevarse, de liberarse de las restricciones y los sesgos, para imaginar un futuro con libertad.

Del mismo modo, el encargado de soñar con el futuro no puede estar metido en las miserias cotidianas de la ejecución. Tiene que tener la mente abierta, relacionarse con un montón de personas y entidades diferentes y alejadas de la empresa, del sector, del país. Tiene que leer, conversar, reflexionar, madurar ideas. Cambiar el chip entre la ensoñación y la operación es sumamente complicado.

Finalmente, entra en juego el tercer rol, el líder del cambio, el encargado de conseguir que la empresa “de hoy” gestionada por el primero se convierta en la empresa “del mañana” soñada por el segundo. Probablemente es el rol más difícil de todos, porque tiene que navegar entre dos aguas. Tiene que tener 100% interiorizada la visión de futuro, y también tiene que tener un conocimiento profundo de la realidad presente. Tiene que tener altura de miras, y también conocer los detalles del barro. Tiene que tener habilidades de visualización (para tener claro dónde se quiere llegar), de ejecución (para definir los planes de cambio y su ejecución) y también (imprescindible) de comunicación. Porque en un proceso de cambio no solo existen “transiciones organizativas” (proyectos con sus planes, fases, recursos, control de ejecución…), sino fundamentalmente “transiciones personales” (conseguir que las personas “se suban” convencidas al tren del cambio).

Y para colmo, esto es algo completamente dinámico. No es que estemos en la situación A, imaginemos un futuro B, y hagamos una transición A-B para llegar a un nuevo valle donde podemos mantenernos durante un tiempo. Es que mientras se está produciendo la transición, hay que seguir gestionando el presente. Es que mientras estamos construyendo el futuro B hay que estar imaginando ya el futuro C.

Tres roles, tres. Si cualquiera de ellos falla, si no hay alguien prestándole atención, hay un problema.

Contenido relacionado:

Continue Reading