Los 4 cuadrantes de los productos de software
En algún momento te habrás cuestionado si la forma en la que estás desarrollando software es la adecuada, o directamente, al enfrentarte a un resultado negativo tras un desarrollo, te has cuestionado qué podrías haber hecho mejor.
En esos momentos de reflexión, tu mente se puede nublar ante la alta cantidad de variables que han podido afectar al resultado, convirtiendo la reflexión en una caminata en círculos que nunca acaba.
Para estos casos, la simplificación de la realidad aislando ciertas variables y utilizando mapas mentales, te puede dar un poco de luz ante la niebla densa que tienes delante.
En este artículo te comparto uno de esos mapas mentales que uso para reflexionar sobre el software, y que me ayudará también a explicar algunas ideas en futuras publicaciones.
Los 4 cuadrantes
En esta ocasión vamos a sobresimplificar la realidad al aislar y polarizar 2 variables:
- La utilidad del producto: útil vs inútil
- El correcto funcionamiento del software: software que funciona vs software que falla
Y con esto, ya tenemos los 4 cuadrantes:
Ahora que ya te las he presentado, vamos a ir explorando y desgranando cada una.
🌈 Software útil y funcional
Tu aspiración debería ser construir software que acabe en este cuadrante, lo que significa entregar y mantener productos que sean útiles y que no tengan fallos que impidan su funcionamiento.
Si además consigues hacer esto con un buen equilibro entre el esfuerzo que supone el desarrollo y la utilidad entregada, te puedes ir a casa con la satisfacción de haber realizado un gran trabajo y afrontar el próximo reto con optimismo.
Pero si ya has entregado software alguna vez, ya sabrás que estar siempre en este cuadrante no es una tarea tan fácil y seguro que te identificas en el resto de cuadrantes.
🌫️ Software irrelevante
Tú y tu equipo empezáis a desarrollar o iterar una parte del producto, con la expectativa de ofrecer una gran utilidad al usuario, pero al entregarlo en producción las expectativas se rompen: has invertido tiempo de desarrollo en algo que el usuario no necesitaba o le perjudica.
Este cuadrante es especialmente doloroso cuando trabajamos en ciclos de desarrollo y feedback largos. El alto esfuerzo invertido no tiene un retorno, y te cuestionas qué sentido ha tenido dedicar tanto tiempo a algo que nadie necesita, siendo por tanto además de un desperdicio un resultado que puede afectar a la moral del equipo.
Éstas iteraciones largas no tienen por qué deberse siempre a seguir una metodología Waterfall, sino que a veces se debe a la sobrecomplejización de la parte técnica antes de haber validado el producto. Nos venimos arriba con el diseño y arquitectura, nuevas tecnologías y herramientas, etc. pero no nos hemos parado a pensar si realmente el producto va a ofrecer suficiente utilidad.
Ahora bien, entregar software irrelevante no tiene por qué ser algo negativo si se hace de forma controlada para obtener feedback con experimentos o desarrollos de bajo coste para validar el producto. En ese caso, caer en este cuadrante te está ofreciendo información a un bajo coste.
Relacionado con esto, en este tweet Allen Hollub nos señala que no caigamos en la trampa de creer que vamos a crear un producto de software útil a la primera, sino que vamos avanzando hacia una mayor utilidad a través de iteraciones.
Don’t fall into the trap of thinking that you have to “get it right.” We approach “right” gradually, though iteration. - Allen Holub
😢 Software disfuncional
Hemos entregado al usuario algo que necesita, un producto bien diseñado que potencialmente le va a dar una gran utilidad, pero cuando se dispone a usarlo, éste falla, impidiendo obtener la utilidad esperada, y que no podrá obtener hasta que el problema técnico se corrija.
Hay muchos motivos por los que el software puede funcionar mal:
- Errores de programación
- Fallos de seguridad
- Problemas de hardware
- Problemas de rendimiento y escalabilidad
- y un largo etc.
Independientemente del tipo de fallo, el problema de caer en este cuadrante no es solo la pérdida de utilidad temporal por no poder usar el producto, sino la ruptura de las expectativas del usuario. Aquello que tenía la expectativa de hacer, no ha podido completarlo por un problema técnico, produciendo así una utilidad negativa.
Una situación así repetida en el tiempo puede llevarle al usuario a perder la confianza en el producto y buscar otras alternativas. Al final, lo que para nosotras es "un pequeño bug" más acumulado en el backlog, quizá es la gota que colma el vaso de la paciencia de un usuario parcialmente descontento.
Por supuesto, no es un todo o nada. Es inevitable que el software falle en algún momento, pero cuanto menos falle, menor sea su impacto y antes nos recuperemos del mismo, menos impacto negativo generaremos tanto a los usuarios como al foco y motivación del equipo que lo desarrolla.
💾 Software obsoleto
Este cuadrante tiene todo lo malo junto: el software falla y además aunque lo arregles al usuario no le sirve. Es como un disquete vacío y roto, que aunque lo arregles nadie lo va querer usar.
El nombre obsoleto viene a raíz de que inicialmente podemos construir software útil y funcional, pero el paso del tiempo puede empujar el software hacia su obsolescencia.
Entregar software que no es útil y no funciona desde el inicio no tienen ningún sentido, y si estamos entregando software que falla con frecuencia o que es un desperdicio porque nadie lo usa, deberían dispararse todas nuestras alarmas.
Si bien hay algunos tipos de desarrollo como la programación hedonista, las pruebas de conceptos y la práctica deliberada, que nos hacen caer en este cuadrante con frecuencia, no suponen ningún problema, debido a que estamos quitando a las usuarias de la ecuación, y que en estos casos que el software funcione no es un fin en sí mismo.
Entrega software útil que funcione
El mapa mental que te he compartido deja muchas variables y matices de lado, pero te puede ayudar a reflexionar sobre qué tipo de software estás creando y manteniendo.
Si bien entregar y mantener software útil y funcional debe ser tu aspiración, no siempre lo conseguiremos, ya que hay muchas variables que pueden afectar al resultado, como por ejemplo:
- La salud del equipo de desarrollo
- La información disponible
- La experiencia
- El azar
- La obsolescencia
En futuros artículos nos centraremos en la obsolescencia, una mirada hacia al software que puede complementar a ideas como la deuda técnica, las tareas de cuidado y el legacy.
Veremos cómo existen fuerzas que hacen que todos los productos de software caminen hacia su obsolescencia y qué podemos hacer para evitarlo.
Mientras tanto, ¡espero que estas ideas te sirvan para seguir construyendo software útil y funcional!
✉️ Apúntate a Reflexiones de Software
Recibe mis reflexiones más significativas sobre desarrollo de software, solo cuando surjan.
👷 Por aquí irán los comentarios y esas cosas. Mientras tanto puedes: