Enamórate del problema, no de la solución
Hace unos años, tuve la suerte de asistir a una conferencia impartida por Uri Levine (cofundador de Waze) en la Global Mobility Call de Madrid. El discurso giraba en torno a la importancia de entender los problemas, el mercado y las necesidades de los clientes, con el propósito final de diseñar la mejor solución. El ponente contaba su experiencia personal como emprendedor y lo que él consideraba una de las claves del éxito – “enamorarse del problema y no de la solución” – haciendo referencia a que la solución no es más que el medio para alcanzar el objetivo final.
Si tu solución no resuelve el problema, no es válida, da igual lo bonita o bien hecha que esté.
Esta filosofía y forma de emprender, está descrita por el propio Uri Levine en un libro con el mismo título: “Enamórate del problema y no de la solución”.
Es el momento de anotar esta lectura en tus notas.
Startups: La ilusión del principio
Si hablamos de startups, como en todo comienzo, esto es algo que se lleva al extremo. Normalmente, se está intentando encontrar una solución a un problema sin resolver, y no es común dar con la solución idónea a la primera. Esto fuerza a los emprendedores a focalizarse en iterar el diseño de las soluciones de forma ágil hasta que, en la mayoría de casos, a base de prueba y error acabas entendiendo mejor el problema y diseñando la mejor solución (o quedándote sin tiempo/dinero y aprendiendo en el intento).
En este contexto, no suele haber otro camino, la supervivencia de una startup diría que está profundamente arraigada a este concepto. Son unos enamorados del problema, de ahí que estén enfocados en diseñar la mejor solución.
Empresas consolidadas: ¿Después de 20 años existe el amor?
Da igual si han pasado 3 años o 25 años desde que todo empezó. Si hacemos analogía con el ecosistema startup, la afirmación: “Enamórate del problema, no de la solución”, sigue siendo válida. El amor por el problema sigue presente, o al menos debería. El principal obstáculo en el mundo empresarial y en la forma de abordar las soluciones IT, es que muchas veces, desde el punto de vista de ejecución, nos olvidamos de qué problema estamos resolviendo. El paso del tiempo juega en contra. Así es, nos olvidamos de ese primer enamoramiento hacia el problema y perdemos el foco hacia la solución.
Esta afirmación tiene multitud de matices, pero en muchas ocasiones, podemos considerar que todo empieza porque el problema se analiza desde un prisma demasiado técnico, sin entender realmente las necesidades del negocio que queremos resolver, algunos ejemplos son:
- Demasiado foco en la descripción funcional, sin entender el para qué de la funcionalidad
- Delegar la definición de la solución en actores equivocados (jefes de proyecto, usuarios de la aplicación, responsable del departamento, equipo técnico)
- Elección de arquitecturas de referencia o tecnologías, sin reflexionar sobre su idoneidad, teniendo en cuenta otras variables no técnicas: talento, riesgos, mercado, competencia, agilidad, etc.
- Falta de visión estratégica a medio – largo plazo
- No implicación de perfiles clave en el proyecto
A diferencia del mundo startup, en el mundo de las empresas consolidadas, normalmente se espera que el diseño de las soluciones sea algo que perdure en el tiempo y aporte valor durante un periodo más o menos largo. Esto indirectamente implica que la aproximación prueba/error no suele ser válida, a cambio, tenemos escenarios más estables donde nos podemos permitir disponer de más tiempo e inversión para analizar y diseñar mejor las soluciones.
Entendido, ¿y ahora qué?
Activemos el punto de vista técnico para entender esto y aplicarlo en nuestro día a día de proyectos y tecnología. Hemos entendido que las soluciones tecnológicas son el medio, no el fin, por lo tanto, para abordar la solución de un problema, nunca empecemos hablando de tecnología, ni siquiera de funcionalidad. Has leído bien. Hay que conocerse a fondo para enamorarse.
Todo empieza entendiendo qué problema queremos resolver, e interiorizar que durante toda la vida del proyecto, es muy importante que esto no se nos olvide.
Profundizando en el «para qué»
Antes de lanzarnos a diseñar soluciones, es crucial hacernos las preguntas correctas:
- ¿Cuál es el problema real que estamos tratando de resolver?
- ¿Cuáles son las necesidades del negocio que queremos satisfacer?
- ¿Qué quiero mejorar? ¿Qué considero que es un éxito? ¿Cuál es el resultado con el que vamos a comparar el éxito?
- ¿Quiénes son los usuarios y cuáles son sus necesidades?
- ¿Cuáles son las restricciones del proyecto?
En muchas ocasiones, las respuestas a estas preguntas no están claras por parte del cliente y será necesario hacer una reflexión previa con analistas de negocio y consultores estratégicos externos para obtener las respuestas. Es clave entender bien esta parte para poder poner el foco en el problema, ¿no? Si no conocemos el problema real, nos será imposible o muy difícil resolverlo.
La clave es conocerse
Es fundamental involucrar a todas las partes interesadas. Normalmente, las respuestas a estas preguntas pueden variar en función de qué interlocutor tengamos en las primeras sesiones, pero involucrar varios puntos de vista, nutrirá nuestra información. Ya sabes, hay que ir más allá del equipo técnico, hay que involucrar, al menos:
- Dirección
- Negocio
- Usuarios
- Equipo técnico
- Otros departamentos afectados
Deben existir perfiles que pongan coherencia y medien entre los diferentes stakeholders. La figura del arquitecto de soluciones y/o arquitecto empresarial son claves en el diseño de la solución.
Acotando el problema
Una vez que hemos comprendido el problema en profundidad, es importante definir su alcance.
- ¿Cuál es el problema principal y cuáles son los problemas secundarios?
- ¿Qué aspectos del problema abordaremos en esta solución y cuáles dejaremos para futuras fases?
- ¿Cuáles son los límites del proyecto?
Documentar y hablar en un mismo lenguaje
Es fundamental tener recuerdos, bueno más bien hablamos de documentar el problema y las hipótesis que nos llevan a la solución, de forma clara y concisa. Esta documentación será el nexo entre todas las partes y permitirá que diferentes grupos de personas adquieran compromisos desde el entendimiento de unas bases bien documentadas, específicas y concretas.
Igual de importante es hablar todos el mismo lenguaje, si no habrá malentendidos a la hora de revisar requerimientos o adquirir compromisos, que se materializarán en riesgos en el futuro proyecto. Este concepto apareció hace años en el diseño de arquitecturas, conocido como Ubiquitous Language.
Conclusión
Estaréis pensando que todo este proceso no aplica a vuestro problema, y que en vuestro caso la solución es menos compleja y directa. Seguramente tengáis parte de razón, pero os diría que este ejercicio debería realizarse siempre.
La parte “accesoria” es la intensidad con la que se lleva a cabo y los riesgos que se decidan asumir por parte de la empresa. Os invitaría a aplicar estas pautas siempre, adecuando la intensidad o la metodología a aplicar en cada caso.
Y recordar, evitar enamorarse de vuestras soluciones, no serán buenas si no han resuelto el problema que motivó su existencia.
Feliz San Valentín
Trabajo en equipo: Contenido elaborado por Ernesto Espinosa y con un toque marketero de Alba López
