¿Te acuerdas qué edad tenías cuando empezaste a estudiar cómo resolver problemas?
¿7 años? – más o menos.
Yo he estudiado resolver problemas de matemática, física, química, definir algoritmos para realizar las soluciones a distintos problemas. Tú también, en estas u otras asignaturas.
Año tras año en las aulas nos han enseñado métodos para llegar a la solución correcta de un problema, suponiendo que las técnicas necesarias están en los libros y hay que combinarlas de una manera apropiada para dar con la solución. Además, la profesora siempre sabe la respuesta esperada.
Sin duda ninguna estos conocimientos son esenciales.
Pero entrando en las organizaciones tecnológicas, el entorno en el que estamos tú y yo (y todo el mundo), ¿esperas poder encontrar la solución a cualquier problema prescrita en algún sitio?
Aunque estamos muy acostumbrados a ellos, hay que recordar que el iPhone entró en nuestras vidas hace sólo 8 años, google maps hace 10, instagram hace 5, dropbox hace poco más de 2. Las soluciones en-la-nube todavía no han salido del área I+D+i y algunos clientes ya las solicitan como algo habitual
¿Estas empresas siguen algunos pasos predefinidos para llegar a la solución actual?
Apenas una década atrás muchas personas opinaban que había que encontrar un trabajo estable para toda la vida y simplemente seguir las instrucciones del manager superior. A la vez algun@s directiv@s pensaban que la toma de decisiones les correspondía a ell@s por tener más información.
¿Puedes tener hoy un negocio flexible y competitivo con esta mentalidad?
Desde principios de 2016 vivimos ya en la época de orientación al cliente y esto nos hace pensar, actuar y organizarnos de otra manera.
Muchas de las situaciones se producen por primera vez y, lógicamente, las actuaciones adecuadas todavía no están documentadas.
Esto no significa que no puedes abordar problemas complejos. Has aprendido a hacer muchas cosas sin saber cómo exactamente.
¿Cómo?
Tienes la base apropiada. Conoces el dominio de tu trabajo, el producto que estáis desarrollando, las personas con las que llevas a cabo los proyectos, vuestros clientes.
A veces la gente se empeña en soluciones complejas técnicamente porque en esto ha estado centrada la gran parte de su formación.
El primer paso en la resolución de cualquier problema es entender el problema. Desde el punto de vista del cliente, el futuro usuario de la solución.
Muchas veces, nada más oír dos frases del cliente, damos el problema por entendido y saltamos a la solución. Luego resulta que algún aspecto se nos ha escapado.
Tanto si hablamos de un producto o de un proceso, la solución exitosa de un problema no es la que funciona sino la que produce un efecto positivo para el cliente. Que le facilite una necesidad concreta y de manera cómoda, o bien que le permita hacer su trabajo de forma natural y sencilla.
Por eso es importante que tu equipo y tu entendáis la perspectiva del cliente, qué necesidades espera que le resolváis y cuál será la manera más cómoda para él/ella.
5 porqués es una buena técnica de entender un problema. Haz todas las preguntas que se te ayuden para:
Varia las preguntas. Entienda lo máximo posible.
Si necesitas más inspiración, vuelve a ver la charla de Simon Sinek "How Great Leaders Inspire Action".
¿Qué hacer si el problema es suficientemente complejo, combina varios aspectos y aunque tienes claro hacia dónde tienes que ir, no sabes cómo abordar todas las consideraciones?
Trocéalo.
Un elefante se come a trozos.
A la meta final se llega pasando por las metas intermedias.
Un patrón que podrías usar para desglosar una solución es el siguiente:
En [circunstancias; condiciones] Cuando [el Actor hace la Acción], Entonces [el resultado o efecto deseado].
Por ejemplo:
En servicio de mantenimiento, cuando por norma limitamos a 2 los tickets que un técnico puede gestionar en un momento, entonces las personas no sufren una carga excesiva de trabajo y pueden concentrarse mejor en la resolución de cada incidencia.
En servicio de mantenimiento, cuando por norma limitamos a 2 los tickets que un técnico puede gestionar en un momento, entonces las personas no sufren una carga excesiva de trabajo y pueden concentrarse mejor en la resolución de cada incidencia.
Trocear una solución, sin embargo, es más fácil decir que hacer.
Para esto ayuda estudiar diferentes opciones y valorar los efectos que producirá cada una de ellas, el valor que aportará al cliente.
También acuérdate que hay que ver el resultado en un tiempo razonable, cuánto más rápido mejor.
Podemos hablar de definición de opciones (alternativas, preferencias) cuando conocemos las características de la solución que queremos implementar y buscamos diferentes formas de realización.
La situación se complica más cuando no tenemos claras estas características o bien porque el cliente no sabe definirlas o bien porque está buscando una solución innovadora o muy personalizada.
En situaciones como esta determinamos objetivos y límites y experimentamos con diferentes hipótesis para que veamos cuál funciona y se puede adoptar. El estudio "Marshmallow" enseña mucho acerca de la búsqueda de soluciones.
Reúne a tu equipo de diseñadores, desarrolladores, comerciales, y déjales que hagan preguntas, suposiciones y que prueben a ver qué funcionaría.
3 son las preguntas que os tenéis que hacer mientras estáis comprobando vuestra hipótesis:
No te olvides del problema principal que quieres resolver porque mi experiencia es que a veces inconscientemente nos desviamos del objetivo y pasamos un buen rato hablando y tratando otros asuntos que no necesariamente aportan algo de valor.
Precisamente para abordar el tema de la búsqueda de la respuesta más adecuada a un problema el método "Lean Startup" propone descubrir la solución en ciclos de aprendizaje validado. Paso a paso, terminando cada etapa con un resultado que permite al equipo entender mejor el problema que está solucionando y aprender de lo que NO ha ido según las expectativas.
Si comprobar una hipótesis te suena complejo en sí y Lean Startup poco adecuado para ponerlo en uso en tu organización, prueba OKR. Es un método que utilizan unas cuantas empresas.
En resumen, OKR sugiere que visualices el objetivo (el problema que quieres resolver), 2-3 resultados clave que quieres conseguir (las características de la solución esperada) y definir acciones que puedes realizar en un tiempo razonable. Mantener esta imagen actualizada y a la vista de todas las personas de tu equipo hasta que terminéis el trabajo.
Al terminar y sin duda ninguna, reflexionar sobre qué no ha ido según lo esperado y por qué.
¿Qué opinas de éstas 4 pautas?
¿Las ves aplicables en tu contexto?
Mi experiencia con ellas es muy diversa y lo que veo como resultados depende notablemente del ambiente que se vive en el grupo de las personas involucradas.
Por eso quiero que prestes atención al segundo complemento necesario en la resolución de un problema:
Después de años dedicados a la mejora de los procesos en organizaciones tecnológicas te puedo decir con plena confianza que, si obligas a un grupo de personas a seguir un proceso, lo que consigues es lo siguiente:
El aprendizaje se limita a los responsables de los procesos y las anécdotas que se cuentan de vez en cuando después de la tercera cerveza.
Si se impone qué-cómo-quién, la gente se suele retirar detrás de sus escudos (roles y responsabilidades) y espera, lógicamente, que el responsable de coordinar todo el trabajo tome las decisiones.
De esta manera es difícil buscar soluciones out-of-the-box.
Lo que te ayuda a salir de una situación como esta, aunque no es fácil e inmediato, es proporcionar la información completa necesaria para que tu equipo pueda resolver un problema, aclarar las fronteras de la solución y dejarles a ellos la autonomía de organizarse.
Esto sí, tú estás con ellos para que facilites el mantener el foco en el problema y ayudar a aclarar las dudas que surjan.
No te olvides de valorar el efecto de la solución, así como de aprender de lo que no haya ido según lo esperado.
Y por supuesto, celebrar el logro.
¿Cuál es tu experiencia?
¿Qué añadirías tú a estas pautas?
