aprendizaje

Año.10: balance y resumen

Se cumplen ahora 10 años de este blog, que languidece haciendo asíntota con ese mínimo autoimpuesto de 1 artículo al mes. Este año, con matemática exactitud, sigo manteniéndome fiel a esa disciplina personal para seguir escribiendo… porque en el fondo cuando lo hago me gusta.

He recuperado en estos últimos doce meses el gusto por temas de empresa, que aparecen no solo en las habituales sentadas reflexivas, sino también en alguna de las reacciones a sucesos imprevistos que aparecen a mi alrededor, esas vibraciones desencadenadas por lo que acontece. Esta es la lista:

Reflexiones:

Vibraciones:

Otros:

En la parte cuantitativa, un año más mis reflexiones sobre “Ventajas e inconvenientes de la gestión por competencias” siguen liderando la clasificación de artículos más vistos, con otras 1.200 nuevas visitas (ya son casi 17.000 acumuladas). Me ha gustado ver que dos de los artículos del año, la crítica de la creación colectiva y la experiencia en la lectura de una tesis doctoral, se han situado en el top-10 de las visitas de estos 12 últimos meses… aunque claro, me ha dado pena que no estuvieran ahí al menos el resto de mis “reflexiones”.

Está claro, por otro lado, que capta más la atención la crítica que los aprendizajes… 😉

Ya saben, si me siguen cada año en estos balances, que tengo una particular pelea con WordPress, a cuyos datos no veo por dónde agarrar a poco que los contraste con otros registros estadísticos de visitas. Van en este décimo aniversario las gráficas y cuadros de costumbre… pero será la última vez que lo haga si las cosas no cambian radicalmente. Y es que a la evidente pérdida de audiencia de esta bitácora, se da este efecto hipermultiplicador que, permítanme decirlo, me resulta MUY desmotivador… 😉

Así que acabo de llegar a la conclusión de que no hay por qué fustigarse más de la cuenta, ¿no creen? 😀

En contraposición, la suma-resta de suscripciones controladas sigue subiendo ligeramente, hasta las 136, a pesar de haber perdido algunos suscriptores con el cierre de alguna vieja plataforma de enlace. Como siempre, lo más agradecido han sido los comentarios, un paso más allá de la lectura que mueve a participar de la conversación, que han aparecido en varios de los artículos y en especial en la crítica a la creación colectiva.

Un año más… vamos a seguir.

Anuncios

Vibraciones: tesis doctoral, un respeto

Ayer tuve la fortuna de asistir a la defensa de la tesis doctoral desarrollada por Eneko Odiaga en el aula magna del campus de Oñate de MU.

Al parecer, Eneko había optado por algo poco frecuente últimamente: enfrentarse a la construcción de evidencias desde una investigación centrada en información no cuantitativa de la que, de alguna manera y a través de un par de largas entrevistas, yo había formado parte.

Nada tiene que ver este artículo con la tesis expuesta (“Diversificación e innovación abierta en el grupo MONDRAGON. Un estudio de casos“), ni con sus contenidos o con el juicio que me merece un asunto que me resulta muy cercano y con frecuencia amargo… sino con el acto en sí mismo.

Tengo que advertirles de que era la primera vez que yo asistía a la defensa de una tesis y, por consiguiente, que es de mi ignorancia subyacente de la que nacen estos párrafos… 😉 … y es que mi aproximación al acto fue exactamente la misma que la que habría tenido para asistir a una conferencia.

Y no…

No es lo mismo.

Muy posiblemente hay otras formas de defender y calificar una tesis de la que yo viví ayer, probablemente mucho más rígidas, más tensas, más formales… pero no cabe duda de que participé de algo muy diferente a la dinámica de una conferencia:

  • En primer lugar, la asistencia. Apenas una docena de personas nos podíamos denominar “público” en una sala con capacidad para más de 100; pero es que entre esa docena estábamos los dos directores de tesis, algunos familiares, tres compañeros de trabajo del doctorando y algunos de los que aportamos información sobre nuestras experiencias para la investigación.
  • En segundo lugar, el papel del tribunal. No solo porque existiera (lógico), sino porque asumió el rol protagonista que en ese acto le correspondía desempeñar. Tuve la impresión, equivocada o no, de que los 5 miembros del tribunal se habían leído la tesis 😮 y aún más, de que al menos 4 de ellos lo habían hecho con cierto detalle. Una buena parte del acto se centró en sus valoraciones sobre lo positivo del trabajo realizado y sobre aspectos que a su modo de ver hubieran aportado más solidez a la investigación o a sus conclusiones, o recomendaciones para futuros proyectos de investigación que hipotéticamente pudieran derivarse del presentado.
  • En tercer lugar, el papel del doctorando (hoy ya doctor). Su defensa de tesis fue firme, sobria, sólida y sintética, con dedicación de espacios tanto a la cuestión metodológica (la construcción de evidencias sobre información cualitativa) como a las conclusiones. Una exposición desde la sencillez, pero con una presencia y una autoridad que solo puede asumir quien habla desde la convicción sobre el trabajo desarrollado. Su respuesta a las aportaciones del tribunal fue igualmente ordenada, coherente y bien estructurada, pero sobre todo holística, centrada en el auténtico corazón de los postulados de la tesis.
  • En cuarto lugar, la emocionalidad dominante. Nada cercano a la curiosidad por descubrir o por aprender (a pesar de que existiera), nada tampoco relacionado con un espíritu de celebración (a pesar de que lo pareciera), ni nada ligado al juicio crítico sobre los postulados defendidos (a pesar de que se vertieran y de que formaran parte esencial del momento): desde mi punto de vista y sin lugar a duda, la emocionalidad dominante fue el reconocimiento. Todos tenían bien presente el esfuerzo continuado que exige la redacción de una tesis bien trabajada y eso se manifestaba a cada minuto del acto.
  • En quinto lugar, la idea de equipo. Para mí un pequeño descubrimiento porque visualizaba el doctorado como un reto esencialmente individual. Sin restar ni un ápice de valor al esfuerzo personal del doctorando, cuyo trabajo se desarrolló además en paralelo a su actividad profesional, salí con la idea de que había un cierto espíritu de equipo que incluía a los directores de la tesis. Los miembros del tribunal (obviamente todos doctores y con esa misma experiencia previa en primera persona), se encargaron de ponerlo de manifiesto en varias ocasiones y, lo que es más importante, los directores de la tesis desbordaban de orgullo por el broche al proceso del que sin duda se sentían partícipes.
  • Y en sexto y último lugar, la liturgia. Obviamente, nadie entra en la sala antes de que lo haga el tribunal. La palabra la tienen solo los miembros del tribunal y el doctorando (cada uno en el momento procesal que corresponde) y cuando el tribunal cede la palabra a alguien ajeno a ese proceso, solo lo hace con los directores de la tesis: el resto somos, realmente, solo observadores invitados. En la valoración del tribunal sobre la tesis defendida, todos salimos de la sala y finalmente y para mi sorpresa, fruto sin duda de la ignorancia… el dictamen del tribunal, al volver a entrar todos en el aula magna, se lee y escucha con todo el mundo de pie.

Me encantó haber tomado la decisión de asistir. Me hizo recordar algunas cosas que, a pesar de resultar con frecuencia obvias, olvidamos cara vez con mayor asiduidad por la cultura dominante del igualitarismo y lo políticamente correcto:

  • No es necesario, ni conveniente, ni deseable, que todo el mundo pueda asistir a cualquier cosa. Como en el gato de Schrödinger, la simple observación puede alterar el estado de realidad. 😉
  • No todo el mundo hace el mismo esfuerzo en la vida por alcanzar una meta. No todo el mundo está dispuesto a hacerlo. Y por lo tanto, no todo el mundo tiene derecho a un reconocimiento equivalente. :-/
  • El esfuerzo que alcanza metas reconocibles devenga en valor. Y eso significa que lo contrario también aplica. La igualdad debe defenderse en las oportunidades… pero la diferencia en las mismas no es justificación de casi nada: es raro que la vida no te permita de alguna manera acumular méritos y, si alguien no quiere hacerlo, debería notarlo. 😡
  • Los ritos y las liturgias son esencialmente respeto. Por una persona, por un momento, por un acontecimiento, por un trabajo… Y están bien: ayudan a reconocer y ser justos con lo diferente y bueno. Si se producen desde la honestidad y la sencillez y se alejan de lo casposo, no solo están bien… es que están muy bien. 😎

Enhorabuena, Eneko.

Sin duda alguna… no estuve en una conferencia, sino en un acto esencialmente académico.

Oigan, una tesis doctoral.

Un respeto.

Reflexiones: la cara “B” de los modelos para la gestión

Un modelo solo sirve para quien no sabe. Y no siempre le sirve para algo que sea útil.

Hala… hoy toca provocar.

Intentaré ser breve y conciso, para variar… aunque sea tirando de viejos recursos “ingenieriles”, llenando el texto de apartados con viñetas para “distinciones precisas y clave”… 😉 😛

30 años de idas y venidas alrededor de la gestión empresarial me han dado para construir varios modelos de muy diversos pelajes, descubrir alguno desconocido, aprender de otros ya experimentados y, finalmente, asistir a varios solemnes funerales… fruto de defunciones por muerte natural o violenta, que de todo ha habido.

Se supone que un modelo de gestión (de gestión-de-lo-que-sea) es algo que uno debería configurar desde las experiencias vividas, desde el conocimiento de la cultura en que se trata de desarrollar y desde el aprendizaje de lo que otros hubieran ya experimentado antes, pero SOBRE TODO, se supone que es algo debería plantearse como una reflexión previa a su despliegue, como un mapa de carreteras que ayudara a la organización a recorrer un proceloso camino desconocido para ella, o como mínimo para ordenar las cosas que debiera llevar en la maleta.

Se supone… y no lo voy a discutir. Pero el tiempo me ha enseñado también otras cosas:

  • A veces, definir un modelo es una forma de autoengaño: pensar que “EL problema” es “que no tenemos un modelo” es en numerosas ocasiones un error, pues el verdadero problema es que la organización no desea realmente enfrentarse a ese asunto en cuestión, o no hay suficiente poder o liderazgo interno para ello, o no hay una visión realmente compartida sobre la necesidad de abordarlo. Pero claro, el simple hecho de ponernos a definir “el modelo”:
    • nos tranquiliza (“ya hemos empezado, se calmen todos, ya estamos en ello”).
    • nos ilusiona (“esta vez sí que lo vamos a hacer bien”).
    • nos da la sensación de que avanzamos (definir el modelo es la fase que siempre se consigue acabar).
  • A veces, el encargo a terceras partes (aka consultores) de construir un modelo, encubre una falta de confianza: alguien que no tiene ni idea del tema te encarga que lo contrates… entre otras cosas porque, además de desear que se avance en ese terreno (vamos a reconocerle honestidad), no cree que tú tampoco la tengas (idea del tema, me refiero). [Tú que vas a saber, claro, si aquí nunca lo hemos hecho… y además, si no sé yo, por qué vas a saber tú…]
  • A veces, definimos un modelo que responde a lo que ya estábamos haciendo. Digo “a veces”… pero igual tendría que decir “muchas veces”. En especial, cuando tratamos de poner en marcha una disciplina de gestión que no es tradicional, que debe ser definida de manera específica, o que responde a una necesidad nueva y sin demasiados referentes externos (en temas tan diversos como diversificación, política industrial, gestión estratégica o transformación social, por poner algunos ejemplos):
    • primero recorremos un camino y aprendemos a base de observar los resultados que vamos consiguiendo,
    • y es luego… cuando resulta que un buen día, mirando hacia atrás, descubrimos que lo que hacemos se puede describir y contar como “un modelo”, que todo cobra sentido y que “los puntos se conectan“. 🙂

Luego está la semántica… y la nomenclatura de gestión que nos inunda cada día. Echen un vistazo a este cuadro que he completado sobre la marcha:

No voy a explicarles por qué deberíamos hablar de un “sistema de gestión de compras” y no de un “proceso de gestionar las compras”, ni por qué de un “modelo de promoción” y no de un “proceso de promoción”, ni por qué de un “sistema de innovación” y no de un “modelo de innovación”: estaría lleno de matices y no es el momento ni el caso. Pero sigan las instrucciones, por favor:

  1. Elijan del cuadro anterior una columna cualquiera.
  2. Elijan a continuación una fila cualquiera.
  3. Lean el encabezado de la primera seguido del título de la segunda… y díganme si no tiene sentido.
  4. Repitan el ejercicio “n” veces.
  5. Sustituyan los puntos suspensivos de la última fila por cualquier ámbito de gestión que se les ocurra y prueben de nuevo tantas veces como deseen. 😉 😛

¿Han conseguido distinguir las frases? ¿Les ha generado esto algún nivel de confusión mental?

Con el caos hemos topado (jejeje…) —> terreno de consultores ávidos de ayudarles, deseosos de aclararles las ideas:

  • para que las entiendan y las pongan en orden en sus casas “con sencillez”. 😎 😡
  • para que piensen que con el proyecto de definición del modelo ya han hecho lo que debían y asuman que, “como es tan bueno y está tan bien hecho”, cuando se lo encarguen a alguien, al fin y al cabo “solo se trata de desplegarlo”. 😥 😡
  • para que puedan dedicarse personalmente a definir nuevos modelos y a poner más orden en sus casas, “que falta hace”. 🙄 😡

Con demasiada y creciente frecuencia, los proyectos de consultoría se plantean últimamente con una primera fase que consiste en “definir el modelo”. Incluso cuando ya hay un modelo establecido, que igual alguien piensa que “no es bueno” o que peca de haber sido definido por compañeros “no expertos”, pero que en realidad podría funcionar muy bien…

  • si el liderazgo de la implantación fuera el que debería ser,
  • si la persistencia y la paciencia organizativas en el asentamiento del cambio fueran las necesarias,
  • si el ejemplo de los que ejercen el papel de liderazgo mostrara la urgencia e importancia precisas al resto de la organización…

Sin cuestionar el trabajo de consultoría, que valoro muchas veces como necesario y que uso con frecuencia, conviene no olvidar que:

  • Un modelo de gestión de cualquier cosa, sea la que sea, nunca es LA clave para conseguir un objetivo o introducir un cambio. No digo que no haga falta, ni que no sea útil… pero si piensan que es la clave de todo o simplemente la clave principal, es que aún no han experimentado lo suficiente.
  • “La cultura se come a la estrategia para desayunar”. La frase de Drucker aplica muy bien aquí: es infinitamente más efectivo (a pesar de que parezca que todo se alarga en el tiempo), aprender de la observación y la experimentación para después, solo después, definir el modelo propio.
  • El clamor por disponer de un gran modelo respaldado por “expertos”, o la crítica destructiva de uno ya existente, esconden muchas veces una atroz falta de visión o confianza.

Bueno… no caigamos en el tremendismo tampoco… Construir un modelo siempre aporta “grandes beneficios”:

  • Recuerden: tranquiliza, ilusiona y da sensación de que avanzamos… 😉 😀
  • Permite a las empresas de consultoría facturar algo más, paquetizar su oferta… y entregar al menos una parte de lo contratado con la seguridad de que:
    • se hará,
    • se hará bien,
    • y se hará en plazo. 😉 😉

Termino diciendo que los modelos de los que más orgulloso me siento de entre los que he creado, han sido los definidos mirando hacia atrás: “conectando los puntos”.

Cuando explican el orden que ha emergido como forma de ordenar el caos.

Porque, que conste, yo soy muy de hacer modelos… 😀 😀

Año.9: balance y resumen

Desde el rol de escribidor, el número 9 me lleva a esas 9 musas, nacidas en 9 noches de amor, que a veces se entretienen bailando con Apolo y dejan de iluminar la inspiración necesaria para escribir.

Y es que 9 años hace ahora esta bitácora, con frecuencia abandonada al baile de esas musas.

Suma uno más los escritos al registro del año anterior, para cerrar con el 15 el número de artículos publicados en estos últimos 12 meses, quizá los de menor contenido profesional de la pequeña historia del blog (ya decía hace un año que se avecinaba un 2017 de crisis en el terreno profesional… y se nota) y casi con seguridad los de mayor contenido en imágenes.

En sentido radicalmente contrario a anteriores balances anuales, esta vez casi todo lo he escrito como respuesta a lo que me ha ido sucediendo. Dos ciudades (Barcelona… y sobre todo Bilbao) dibujan un escenario yin y yang para este año, en el que también una palabra lo ha llenado todo y exige ser nombrada por derecho propio: arte. Esta es la lista:

Reflexiones:

Vibraciones:

Otros:

En la parte cuantitativa, mis reflexiones sobre “Ventajas e inconvenientes de la gestión por competencias” siguen liderando la clasificación de artículos más vistos, con otras 1.500 nuevas visitas (ya son más de 15.000 acumuladas). Ninguno de los del año se sitúa en el top-10 de las visitas de estos 12 últimos meses, aunque un par de ellos, la noche en blanco en El Prat y la hibridación entre SCRUM y 5M sí aparecen entre los 20 primeros.

Eso sí, definitivamente… esto de las estadísticas de WordPress no hay por dónde agarrarlo, así que lo seguiré como a una tradición y no como a una referencia de lo que realmente sucede. Ya hace un año, en el paralelo ejercicio de balance, apunté mi extrañeza sobre las discrepancias notables observadas en la contabilización de visitas al artículo sobre Solana, entre LinkedIn y WordPress (818 frente a 134, en aquel momento).

Hace 3 meses confirmaba esa misma contradicción en el artículo sobre los números del blog, en el que me maliciaba de que este asuntillo solo podría estar pasándonos a los “pobres” de WordPress.com frente a los “profesionales” del .org.

Y en esta ocasión me reafirmo en ello. Vean en el siguiente cuadro la comparación entre las supuestas visitas totales registradas por WordPress en los últimos 8 artículos y las registradas solo por LinkedIn en sus páginas:

Añado más. Para una última comprobación, hace tan solo unos días volví a publicar en LinkedIn (y solo ahí) un enlace al artículo que sobre SCRUM y 5M escribí hace 10 meses. Pues bien, esto es lo que observé:

  • WordPress: 35 visitas (34 en sitio + 1 distribuida).
  • LinkedIn: 745 visualizaciones (con 4 recomendaciones).

No tengo más que decir.

La suma-resta de suscripciones controladas sigue subiendo ligeramente, hasta las 133, aunque lo más satisfactorio ha sido la aparición de algunos “brotes verdes” que han reverdecido los comentarios, casi un recuerdo de tiempos pasados que sigue resultando para mí lo más valioso y gratificante del blog.

Termino con los ya sospechosos y oscuros números de costumbre y con un agradecimiento enorme a quienes, amables lectores, continúan pasando por estas páginas… sean los que sean. 😉

¿Números de blog?

Solo habían transcurrido tres meses de la vida de esta bitácora cuando escribí el artículo “Números de blog” para celebrar las 1.000 primeras páginas vistas.

Desde entonces, cada año he ido haciendo balance de cómo me va en esta historia, incluyendo los datos de visitas y la evolución del grado de atención que esta modesta casa despierta en su apreciada comunidad… aunque en varias ocasiones advirtiendo de las dudas que las “estadísticas” de WordPress me ofrecían en cuanto a fiabilidad de los datos.

Hoy ya no me cabe ninguna duda.

Desde la última gran renovación de LinkedIn, esta red profesional contabiliza las visualizaciones que dentro de ella se realizan a las publicaciones que uno hace allí. Como tengo ligada la publicación de artículos del blog desde el propio WordPress a mi perfil en LinkedIn, dispongo de una contabilización específica del tráfico que llega a mi bitácora exclusivamente en ese origen… hecha por ese origen.

El pasado viernes día 10 hice un balance de vistas en ambas fuentes de datos, desde la fecha de publicación de cada uno de los últimos 5 artículos, hasta dicha fecha… y el resultado fue el siguiente:

Como ven, LinkedIn registra 775 páginas vistas desde su propia plataforma (de la que no tengo por qué desconfiar, porque me he ido fijando en cómo iba creciendo cada una día a día hasta estancarse, en este periodo de control), algo imposible si WordPress me dice que sólo se han visualizado 111 en el conjunto de todas las fuentes de acceso en el mismo periodo.

Fuentes que para mí son:

  • Facebook (en mi caso desde luego con un tráfico nada desdeñable),
  • Twitter (que ha ido disminuyendo, pero que aún me sostiene una cierta actividad de enlace),
  • otras redes como Viadeo o Xing donde también publico (admito que en estos casos, cantidades despreciables),
  • Whatsapp (sí, también aquí… y en este caso, por ejemplo, he podido verificar que solo entre los días 12 y 13 hubo casi 100 páginas vistas de la serie “Arte y Bilbao” por este canal),
  • búsquedas de términos o imágenes (siempre hay una cantidad modesta, pero continua, de visitas a través de los motores de búsqueda como Google),
  • feeds sindicados (los Feedly de rigor, que “haberlos hailos”),
  • suscripciones al blog (a través de WordPress, por correo electrónico o por Networked Blogs).

Así que… no solo LinkedIn me muestra que debería multiplicar por 7 los registros de las estadísticas de WordPress, sino que, en función de las otras fuentes de visitas que no puedo controlar, ¿por cuánto tendría que multiplicarlos? ¿Por 10? ¿Por 15? ¿Por…?

Ya… ya sé que los pobres de WordPress.com no tenemos derecho a quejarnos, que todo es gratis y que se trata de un asuntillo amateur… que si uno quiere conectar su blog a Google Analytics u otros servicios, “hay que profesionalizarse” y pasar a WordPress.org…

Bueno, pues no.

Cuando a uno le ofrecen estadísticas desde quien es el indiscutible número 1 del mundo en su campo, espera fiabilidad.

Y si no, que las quiten.

¿No crees, WordPress.com?

Reflexiones: SCRUM y 5M

Tenemos visiones parciales, incompletas, segregadas… Es inevitable.

Fue hace unas semanas.

A los alumnos de un grado en informática (es un ejemplo, pero es real) les enseñan ya metodologías ágiles e incluso cómo desencadenar un proceso de design thinking para afrontar un wicked problem, con toda su artillería metodológica… pero nadie les habla de cómo resolver un problema que probablemente tenga poco de wicked.

Y es que espero que nadie, a estas alturas, estimados lectores, se plantee siquiera que SCRUM pueda garantizar un camino de éxitos, exento de problemas y solo sujeto a un número incierto de iteraciones tras las cuales, sin duda alguna, aparecerá el santo grial…

Es más, las metodologías ágiles y el pensamiento de diseño están concebidos como un reto y no como un proceso de resolución de un problema, porque incluso cuando el problema es el origen de todo (algo extremadamente frecuente e incluso recomendable), el trabajo se centra en el reto de superarlo y no en corregirlo, independientemente de si se atacan las causas o no, mediante dosis masivas de observación, pensamiento lateral y experimentación.

El camino es diferente, gratificante, desafiante y motivador… pero no siempre resuelve un problema, sino que en muchas ocasiones elimina sus efectos o la necesidad de que éstos nos afecten o de que ni siquiera nos lo tengamos que plantear.

Y claro… a veces los problemas son tozudos y no quieren “dejarse desaparecer”, jejeje…

Un buen SCRUM trata de garantizar que se alcancen las funcionalidades requeridas y un buen diseño de UX se preocupa de satisfacer e incluso superar las expectativas del cliente… pero en cualquier caso, durante el desarrollo de un proyecto, en su implantación y posteriormente a su implantación, surgen problemas que muchas veces los equipos no saben cómo afrontar.

Y si han trabajado con proveedores recientemente en un marco SCRUM, estoy seguro de que entienden de qué les hablo.

¿Cómo han tratado de corregir sus proveedores un problema relacionado con la entrega de un producto con rendimientos insatisfactorios o claramente por debajo de lo esperado, a pesar de numerosas interacciones? ¿Cómo han abordado retrasos significativos que incluso han afectado el potencial de su negocio como cliente? ¿Cómo han gestionado el aprendizaje posterior y cómo se lo han comunicado?

Mira, lo hemos hecho mal… pero hemos aprendido. Nos vamos a hacer cargo de esta y esta otra manera y, además, te vamos a contar cómo hemos analizado los problemas, cuáles han sido las causas que creemos los han motivado y qué cambios vamos a introducir para que no nos vuelva a ocurrir“. ¿Recuerdan a algún proveedor que haya adoptado una iniciativa similar? ¿La han adoptado en sus propios equipos para con sus clientes? No, ¿verdad?

El mundo de los servicios de consultoría, ingeniería o diseño no está en general acostumbrado a este tipo de relación con sus clientes. Para un desarrollador de software, que su cliente haga de beta tester, o que incluso lo haga durante semanas y en correcciones sobre correcciones, entra dentro de lo que cabe esperar, dentro de lo que puede ser normal que pase.

Eso es un anatema en el mundo de la industria. Pecado mortal. Si haces algo así, estás fuera.

Y sin embargo, muchos de los problemas que surgen en el desarrollo de un proyecto de software no son diferentes a los problemas que surgen en cualquier otro orden de la vida, en cualquier otro tipo de negocio, tecnología o disciplina. O sea, que las metodologías clásicas de resolución de problemas (sí, incluidas las viejas y nuevas herramientas de calidad y calidad total) son perfectamente aplicables.

A los que ya hemos pasado de los 50, nadie nos enseñó en nuestras carreras cómo resolver un problema en una empresa. El conocimiento y las técnicas implicadas formaron parte del aprendizaje experimental que luego fuimos desarrollando en nuestras actividades profesionales, en función del sector o de la función que nos hubiera tocado en suerte. Entonces, la mejora continua, los conceptos lean o la calidad total no formaban parte de los estándares de aprendizaje y, aunque parezca mentira hoy, conformaban la cultura emergente… 😮

Lo alucinante es que, hoy en día, el poder de lo cool esconda muchas veces carencias que, en estos tiempos, es increíble que se permita permanezcan en el territorio de la ceguera cognitiva de un profesional. Como en el caso del grado en informática con el que abría el post, el adiestramiento en los procesos de resolución de problemas está universalmente al margen del aprendizaje académico, cuando en mi opinión debería formar parte de una cultura generalizada de estar en el mercado de trabajo. Su transversalidad es absoluta.

Incluso si adoptamos SCRUM como metodología de desarrollo de proyectos. Veámoslo.

Imaginemos un “proyecto A” en el que se ha generado un conflicto con el cliente: se ha entregado con un retraso considerable, la calidad del producto está lejos de satisfacer las expectativas de quien paga, los costes de desarrollo se han disparado y ha habido que renegociar el contrato, o han surgido dificultades técnicas que han forzado al cliente a renunciar a determinadas funcionalidades deseadas.

Venga… seguro que no les es muy difícil acordarse de un proyecto en el que haya surgido alguno de estos “problemillas”… o varios de ellos a la vez…

Imaginemos pues que hemos hecho uso como estándar de metodologías ágiles y singularmente SCRUM. ¿Qué podemos hacer para aprovechar la experiencia para aprender y mejorar nuestro desempeño? ¿Cómo nos podemos hacer cargo del problema para robustecer nuestras competencias y habilidades en la gestión de proyectos? ¿Cómo identificamos nuestros errores para aprender de ellos y ser más competitivos, más eficientes, más efectivos y en definitiva mejores?

Da igual si se han sentido aludidos como clientes o como proveedores. Se trata de un problema para ambos y por lo tanto ambos pueden exprimirlo para aprender.

Es perfectamente posible hibridar el pensamiento de diseño con la utilización de herramientas de resolución de problemas. De hecho, y aunque los guay del design thinking no lo sepan, algunas de las herramientas que usan son o derivan directamente de aquéllas, jejeje… >:D

Veamos las clásicas 5M. Se trata de ser sistemático en el análisis de causas para que no se nos escape ninguna cuando tratamos de identificar el origen de un problema. El objetivo es siempre determinar todas las causas que provocan su aparición, para atacar la raíz de las mismas y evitar que en el futuro se reproduzcan.

Suelen ser preludio del uso de otras herramientas adicionales (los 5 WHY o el diagrama de Ishikawa, por ejemplo) que nos ayudan a ello, pero hoy nos quedaremos en este primer paso, el más básico.

Cuando uno comienza a enfrentarse al análisis de un problema, es muy recomendable escoger un esquema mental que ayude a colocar el foco de nuestra mente en todos y cada uno de los ingredientes relevantes que suelen ser origen de cualquier problema, sin olvidar ninguno. Un brainstorming simple, abierto y no guiado por restricciones bien segmentadas, suele conducir siempre a lugares comunes, lo que implica que habrá aspectos que se nos escapen del análisis y, en definitiva, que el problema conservará potencial de reaparición.

Si hemos sido buenos profesionales y hemos tratado de corregir nuestros errores y aprender de ellos, pero no lo hemos hecho con método y los problemas se repiten a pesar de las acciones tomadas, acabaremos pensando en lo buenos o malos que somos… y no en cómo hacemos lo que hacemos. Mal camino.

Las 5M proponen que concentremos nuestra mente en identificar las causas de un problema (las razones por las que un proyecto ha sido fallido) en 5 focos diferentes:

  • Máquina: causas relacionadas con el mal funcionamiento o la insuficiente capacidad de proceso de máquinas, equipos o herramientas.
  • Método: causas relacionadas con el mal uso o la no aplicación adecuada de metodologías contrastadas o de estándares de trabajo definidos.
  • Materiales: causas relacionadas con el uso de materiales de insuficiente calidad o inadecuados para la función a desarrollar.
  • Mano de obra: causas relacionadas con bajos rendimientos personales, insuficientes competencias técnicas, errores humanos o comportamientos dañinos para el proyecto.
  • Medio: causas relacionadas con factores del entorno que tienen capacidad de influir en el rendimiento de producto o en el desarrollo del proyecto.

Pues vayamos a analizar cómo aplicar las 5M al “proyecto A” que mencionábamos antes, un proyecto gestionado con SCRUM… que no ha ido bien.

A pesar de que SCRUM es en sí mismo una metodología y de que por lo tanto lo más fácil es que nos surjan preguntas sobre el funcionamiento del método en sí mismo o sobre las personas (al ser un proyecto donde los recursos fundamentales suelen ser de conocimiento), en función del tipo de proyecto o problema podríamos hacernos preguntas como las siguientes:

  • Máquina:
    • ¿Se adecuaban las interfaces, nuevas o disponibles, que hemos utilizado, a las especificaciones técnicas? ¿Y al lugar de uso? ¿Por qué no?
    • ¿Su robustez y calidad eran las necesarias para un funcionamiento continuo y sin fallo? ¿Estaba todo ello garantizado? ¿Por qué no?
    • ¿Estaba la máquina en que se insertaba o integraba nuestra solución, preparada para ello? ¿Cumplía las necesidades mínimas para absorber el funcionamiento del nuevo sistema? ¿Por qué no?
    • ¿Eran las plataformas tecnológicas usadas las adecuadas para las necesidades del proyecto? ¿Estaban suficientemente disponibles? ¿Eran seguras? ¿Se disponía de redundancia, respaldo o alta disponibilidad? ¿Por qué no?
    • ¿Se disponía de la suficiente capacidad de cálculo y en el tiempo preciso? ¿Por qué no?
    • ¿Disponíamos de planes de contingencia para el fallo en nuestras instalaciones? ¿O frente a fallo catastrófico? ¿Por qué no?
  • Método:
    • ¿Se definió adecuadamente la misión del proyecto? ¿Representaba fielmente el objetivo deseado? ¿Existía una comprensión compartida en el equipo y con el cliente del significado, las limitaciones y las implicaciones de la misma? ¿Por qué no?
    • ¿Era claro el campo de decisión interna del equipo y los elementos que necesitaban de validación externa? ¿Se respetó? ¿Por qué no?
    • ¿Recogía adecuadamente el contrato las expectativas para el producto, los plazos, las limitaciones y condicionantes del proyecto, las formas y penalizaciones de pago, la propiedad de los fuentes y de los datos o los niveles de servicio, por poner algunos ejemplos? ¿Por qué no?
    • ¿Se definieron con la suficiente precisión las funcionalidades del product backlog? ¿Y las de los sucesivos sprint backlog? ¿Por qué no?
    • ¿Se construyó una estructura de releases y sprints razonablemente ajustada a la naturaleza y necesidades del proyecto? ¿Por qué no?
    • ¿Se definieron con suficiente detalle las acciones a desarrollar en cada sprint? ¿Se desglosaron lo suficiente, en dimensiones manejables? ¿Había suficiente conocimiento en el equipo como para estimar con la suficiente aproximación el coste en horas de cada acción? ¿Por qué no?
    • ¿Se ajustaron las dedicaciones previstas a las disponibles? ¿Mostró habitualmente el burn down chart un ajuste razonable de recursos y necesidades? ¿Se establecieron acciones para corregir las desviaciones? ¿Por qué no?
    • ¿Se realizaron sistemáticamente las reuniones diarias? ¿Y los cierres de sprint? ¿Por qué no?
    • ¿Se utilizaron como herramienta eficaz de gestión las herramientas de gestión visual? ¿Por qué no?
    • ¿Fueron los entregables, en general, bien recibidos por el cliente? ¿Estaba su estructura y contenido bien definidos con antelación? ¿Respondían claramente a una funcionalidad del backlog que podía ser testada? ¿Respondían a una necesidad de feedback para consolidar el avance del proyecto? ¿Por qué no?
  • Materiales:
    • ¿Las carcasas, los soportes del interfaz y en general de los equipos instalados, eran adecuados a la agresividad del entorno de trabajo (acidez, salinidad, partículas en suspensión, humedad, presión, temperatura…)? ¿Por qué no?
    • ¿Los materiales de los soportes eran adecuados para la transmisión o recepción de señales inalámbricas (evitando encajonar en aluminio, por ejemplo, la recepción de señales de geoposicionamiento)? ¿Se había previsto prestar atención a este asunto? ¿Por qué no?
    • ¿Eran los equipos, interfaces físicas, soportes y conexiones, suficientemente robustos como para impedir casos de daño accidental, vandalismo o robo? ¿Por qué no?
    • ¿Respetaban los materiales utilizados las normativas del sistema en que se integraban, incluyendo compatibilidad electromagnética, reglamentación, seguridad, eficiencia energética o reciclabilidad? ¿Por qué no?
  • Mano de obra:
    • ¿Hemos destinado al proyecto a las personas adecuadas? ¿Eran técnicamente competentes y profesionalmente responsables, a los niveles necesarios? ¿Por qué no?
    • ¿Hemos podido atender a las puntas de trabajo con la flexibilidad necesaria en el equipo o fuera del mismo? ¿Por qué no?
    • ¿Ha habido un nivel de dedicación y compromiso con el proyecto que impida negligencias? ¿Por qué no?
    • ¿Ha habido un nivel de comunicación fluido entre los miembros del equipo, entre éstos con el product owner, entre éste y el scrum master y, en definitiva, entre el equipo y el cliente? ¿Por qué no?
    • ¿Se han cubierto adecuadamente las funciones de product owner o scrum master? ¿Se han sabido separar bien del trabajo operativo, cuando procedía? ¿Por qué no?
    • ¿Ha estado el proceso libre de interferencias significativas de elementos externos (jerárquicos, por ejemplo, o presiones procedentes de entornos multiproyecto) en la capacidad del equipo de gestionar el proyecto y tomar decisiones? ¿Por qué no?
  • Medio:
    • ¿Ha sido posible asegurar la buena marcha del proyecto frente a la aparición de tensiones laborales o sociales? ¿Por qué no?
    • ¿Ha estado el proyecto libre de herencias nocivas fruto de experiencias previas cliente-proveedor o de relaciones personales tóxicas internas o externas al equipo? ¿Se previeron y gestionaron? ¿Por qué no?
    • ¿Han aparecido, en el transcurso del proyecto, limitaciones no previstas (internas o externas) o modificaciones en los objetivos, que introducían variaciones relevantes en la misión asignada al mismo? ¿Se han negociado a satisfacción de todos los stakeholders implicados? ¿Por qué no?
    • ¿Se disponía de los espacios y medios de trabajo necesarios para el proyecto y para las dinámicas de trabajo en equipo? ¿Por qué no?
    • ¿Ha funcionado adecuadamente la estructura corporativa que aportaba los recursos auxiliares necesarios (en compras, subcontratación, asesoría legal o selección de personal, por ejemplo)? ¿Por qué no?

Una vez obtenidas las primeras respuestas, conviene preguntar de nuevo a cada una “¿por qué?”, sucesivamente hasta 5 veces (como los niños en periodo de descubrimiento), para acercarnos a la verdadera causa raíz. Y una vez identificada una causa raíz, las soluciones se mostrarán evidentes en un alto porcentaje de las veces.

Para terminar, es altamente recomendable hacer un test de coherencia con un análisis de potenciales causas derivadas de posibles fallos en personas que hubieran podido intervenir, directa o indirectamente, en el proyecto. Se trataría de seguir los siguientes pasos:

  1. Identificar las personas implicadas: scrum master, product owner, miembros del equipo, director de proyecto, cliente, responsable de compras, proveedores, responsable de infraestructuras, comercial, responsable de control de costes…
  2. En cada una de ellas, pensar si se han producido fallos de rigor o de competencia, siempre teniendo en cuenta dos facetas de cada fallo: por qué sucedió algo indeseable, por un lado… y por qué no nos enteramos, o nos enteramos demasiado tarde como para mitigar sus efectos, por otro.
  3. Verificar que los fallos que así encontremos estaban ya contemplados, aunque fuera de otra manera, en el análisis de causas anterior.

El objetivo de este test de coherencia no es “meterle el dedo en el ojo” a nadie. No se trata de buscar culpables sino soluciones, no lo olvidemos. Se trata de un proceso metodológico que busca exclusivamente robustecer nuestro desempeño y evitar la reproducción de un problema en el futuro.

Obviamente, la lista anterior de preguntas asociadas a cada una de las 5M no es exhaustiva (cada proyecto tendrá sus preguntas adecuadas)… y el ejemplo no es exclusivo: SCRUM puede utilizarse para gestionar un proyecto de desarrollo de producto físico o incluso de creación de una nueva línea de negocio. Cualquier entorno donde la incertidumbre sea elevada y exija moverse en ese escenario.

De hecho, si el proyecto descansa, total o parcialmente, sobre un producto físico, la aplicabilidad es incluso más evidente.

¿Y sobre un intangible, como un “negocio”? Imaginen, por ejemplo, un desarrollador de software que decide “montárselo por su cuenta”: darse de alta como autónomo, construir su propio modelo de negocio y enfrentarse al mercado como empresa independiente o como freelance. Imaginen que… no le va bien. Que no vende, a pesar de ser una persona técnicamente competente y de volcarse personalmente en construir su marca personal y en conseguir que ello le reporte ingresos suficientes como para que merezca la pena. “¿Por qué no vendo?” es una pregunta que se hará cada noche, ¿verdad? “¿Qué puedo hacer para cambiar la situación?”

Pues les aseguro que pensar en clave 5M sobre lo que identifique que no funciona en cada uno de los elementos de su canvas de negocio (supongo que a definirlo ya habrá llegado, claro) le va a ayudar a afrontar ese problema porque aflorará preguntas tan importantes como las siguientes:

  • ¿Qué tecnología estoy utilizando y qué alternativas tendría?
  • ¿Qué me están aportando realmente (y cómo) mis aliados y mi red de apoyos para la configuración de equipos de proyecto o para completar mi propuesta de valor?
  • ¿Gestiono los capítulos principales de mi estructura de costes?
  • ¿Sé realmente quiénes son mis clientes o quiénes tendrían que ser? ¿Me ayuda a entenderlo la estratificación que he hecho… suponiendo, claro está, que la haya hecho?
  • ¿Cómo me relaciono con mis clientes? ¿Sé qué necesitan? ¿Y el mercado? ¿Cómo lo averiguo? ¿Cómo lo conecto con mi propuesta de valor? ¿Cómo les hago percibir que me necesitan a mí?
  • ¿Con qué recursos cuento, con qué tecnología o equipos, para mi trabajo o para soportar mi propuesta de valor?
  • ¿Cómo lleno mi dealflow de proyectos?
  • ¿A qué he decidido expresamente renunciar? ¿Qué renuncias estoy dispuesto a hacer?

Lo hará en otro orden, adaptando estas preguntas genéricas a su circunstancia particular y probablemente desglosándolas en otras más específicas… pero lo hará.

Venga… Les dejo un ejercicio para casa: ¿identifican de cuál de las 5M puede haber procedido cada una de estas preguntas? 🙂

Año.8: balance y resumen

ajedrez-tableroLa esencia del número 8 es carretera inacabable, doble loop imposible que puede recorrerse imaginariamente hasta el infinito, infinito que dibuja al acostarse, cada noche, cuando nadie ve. 😉

La cuadratura de su doble círculo se logra en un tablero de ajedrez, un 8 casillas al cuadrado, en cada una de las cuales solo cabe colocar una ficha a la vez. Casi como este blog, que a los 8 años va asumiendo como norma (y a pesar de algunos voluntariosos intentos siempre de vida breve) el rellenarse con un post cada mes.

inquietos ha seguido en 2016 la senda de estabilidad de los últimos años, pugnando por superar cada mes la muy modesta barrera de las 1.000 lecturas, muy lejos de sus mejores aunque igualmente discretas cifras del pasado.

Y así tiene que ser, porque es el lugar que le ha quedado en este camino, que por otra parte cada vez recorro con menos compañía: a pesar de la limpieza de hace seis meses, aún les puedo contar que en casi un tercio de los feeds que decidí conservar no se ha registrado movimiento alguno en este tiempo.

El año pasado les hablaba de la impactante experiencia como vlogger de mi hija… Bien, pues ya no está. Ha experimentado, ha crecido, ha conversado, ha aprendido, ha disfrutado… y a otra cosa: ha cerrado al público su canal. Todos los vídeos. Tuvieran cientos de miles o medio millón de visitas en menos de dos años… Y no la veo muy arrepentida tras varios meses.

Es obvio que es otra generación. o_O

2016 se va a cerrar con 14 artículos que combinan la reflexión y la reacción a un momento vivido, casi al 50%. Por volumen, destaca la serie de reflexiones sobre innovación empresarial hacia modelos sostenibles (un conjunto de propuestas al hilo de mi participación en un seminario inesperado), aunque al margen de ello, les diré que de varios de los artículos restantes de 2016 estoy francamente satisfecho. Los publicados son los siguientes:

Reflexiones:

Vibraciones:

Otros:

En la parte cuantitativa, mis reflexiones sobre “Ventajas e inconvenientes de la gestión por competencias” siguen liderando la clasificación de artículos más vistos, con otras 2.100 nuevas visitas (ya son casi 14.000 acumuladas). El post navideño es el único de los del año que se sitúa en el top-10 de las visitas de estos 12 últimos meses.

Parece que lo de la sostenibilidad empresarial no “vende” mucho… 😉

Un apunte para centrar mi atención en los próximos meses en este proceloso mundo de los números: según las estadísticas del propio WordPress, al artículo sobre Javier Solana ha recibido hasta ahora solo 134 visitas, pero… el nuevo diseño de LinkedIn ofrece el dato de que exclusivamente a través de este canal (solo uno de los que tengo conectados al blog)… ¡ha habido 818 visualizaciones del mismo!

¿Cuál es el dato real? ¿Y pasará lo mismo en Facebook o Twitter o…? Porque he notado también que en las gráficas de WordPress aparecen casi siempre “a cero” los registros gráficos de lo que llama “visitas distribuidas”, que yo siempre había relacionado con los feeds de suscripciones (y que, al contrario que en el pasado, hoy son algo casi residual en mi blog). ¿O es que tampoco cuenta WordPress bien aquí?

Pues me quedaré en la duda, porque me niego a entrar en el universo del SEO…

La suma-resta de suscripciones controladas vuelven a subir ligeramente, hasta las 130, pero los comentarios han brillado por su ausencia (salvo en el artículo sobre Solana y en el de mi declarada intención de hacer limpieza en esta casa), aunque los pocos que ha habido siguen resultando para mí muy valiosos y les aseguro que también muy agradecidos.

Termino. Con los números de costumbre y con un agradecimiento ampliado a quienes, amables lectores, continúan pasando por estas páginas.

2017 se plantea con una crisis en el terreno profesional… pero aquí seguimos.

tabla-ano8

mensual1702