Costovación, cuando menos es más
#InformeLanaspa
A los que trabajáis conmigo o me seguís en Twitter ya estabais en sobreaviso, mi lema de este año va a ser “menos es más”. Lo voy a repetir hasta la saciedad. Lo llevaré por bandera durante todo el año y he escrito este #InformeLanaspa para que también podáis hacerlo vuestro.
Tendemos a pensar que mejorar un producto o servicio debe pasar indiscutiblemente por añadirle una nueva funcionalidad, una nueva característica o un nuevo proceso. Sin embargo, en muchas ocasiones no nos paramos a pensar en los costes y peajes de incluir nuevas funcionalidades.
Además, es obligatorio entender que el valor no lo aporta lo que se construye, sino lo que se construye y se usa. Construir algo no implica que vaya a ser usado.
Menos es más, less is more en inglés que queda más cool o costovación tal y como dirían en 1000lemons. Cualquiera de las 3 sirve según las preferencias de vuestro departamento de marketing interno.
Calidad vs. Cantidad
Me pongo como propósito demostrarme a mi mismo y a los que me rodean que es mejor que lo que creamos haga una sola cosa muy bien hecha que muchas reguleras. El modelo navaja suiza, un producto o servicio que lo haga todo tiene sus pros, pero muchas contras también.
Cuando vamos a abrir una botella de vino en la mesa no nos paramos a pensar en utilizar el sacacorchos de una navaja suiza, aunque la navaja tenga una herramienta que nos puede ayudar a descorchar un buen vino.
Sin embargo, para ello instintivamente pensamos en una herramienta específica para la tarea y no en una herramienta multiusos. Un buen sacacorchos, bonito, fácil de usar. Una buena experiencia, simple pero buena.
El sacacorchos es lo primero que piensa nuestra cabeza, lo vemos más natural, nos gusta más.
Peajes del más
Más allá de que nuestra mente piense primero en herramientas que nos solventen una cosa de forma sencilla y bien hecha antes que una multiusos que nos proporcione más capacidades pero que no nos resuelvan tan bien el problema del momento. Añadir una funcionalidad, proceso o servicio lleva consigo una serie de tareas y costes que muchas veces subestimamos o que olvidamos de incluir en la ecuación.
Añadir una nueva funcionalidad y crear un sistema de múltiples funcionalidades y capacidades tiene su riesgo y sus costes. He creado una lista, construyendo sobre la de John Cutler con todos los que he sufrido en mis propias carnes. Me he sorprendido a mi mismo porque aunque era consciente de todos ellos verlos en una lista asusta mucho:
- Coste de creación de la propia funcionalidad (desarrollo, UX…)
- Costes de llevar la funcionalidad a producción (empaquetados, releases, CD/CI setup…)
- Costes de investigación de mercado, usuario y de analítica de la funcionalidad
- Costes de coordinación interna con otros equipos, productos y roadmaps
- Costes de entender y tener respuesta para cada corner-case
- Costes de mantenimiento de la funcionalidad versión trás versión
- Costes derivados de la mejora paulatina de la funcionalidad
- Costes de crear documentación útil interna y para usuarios finales
- Costes de entrenar al departamento de ventas o delivery para vender la funcionalidad
- Costes de entrenar a los usuarios para utilizar la funcionalidad
- Costes de incluir la funcionalidad dentro del plan comercial
- Costes de dar soporte a usuarios y equipos internos sobre la funcionalidad
- Costes de refactorización del sistema
- Costes de eliminación en un posible futuro
- Costes asociados al tener un sistema más complejo
- Ingeniería avanzará más lento en futuros desarrollos por tener que trabajar con un sistema más complejo
- Costes de contratar a más equipo para hacer frente a un sistema más grande y complejo
- Costes asociados a una curva de aprendizaje más elevada a toda nueva persona que trabaje con el producto
- Menor flexibilidad del sistema
- Coste de mantener el sistema usable tanto de manera interna como de cara al usuario al hacerlo cada vez complejo
- … Costes de tener reuniones para que todo lo anterior suceda.
Y seguro que me dejo muchos más.
La complejidad mata
Me resulta curioso como entre todo este impresionante listado de costes que tenemos identificados el coste de aumentar la complejidad del sistema sea el que menos veces oigo pronunciar, siendo que en mi opinión personal es el peor de todos.
La complejidad es al final del día una deuda que se va acumulando al complicar las funcionalidades o la tecnología para resolver los problemas a los que nos enfrentamos.
Una aplicación que hace cien cosas es más difícil de refactorizar que una aplicación que hace solo una. Cualquier cambio en su código es más costoso.
A veces, la complejidad es un coste necesario, la clave reside en reflexionar sobre si realmente la complejidad añadida por cada nueva funcionalidad que entregamos compensa mirando la foto global.
La complejidad funciona como el interés compuesto a lo largo del tiempo, es una losa cada vez más pesada. Si no mantenemos el producto simple perderemos la agilidad necesaria para reaccionar cuando es realmente necesario.
Roadmaps negativos
Saber lo que debemos quitar para mejorar nuestro producto es altamente complicado y requiere de un grado de autocrítica elevado, de saber dar pasos hacía detrás sobre apuestas que han fallado. Recordemos de nuevo que el valor lo aporta lo que se usa, no lo que se construye.
Y si sabemos que más funcionalidad implica inequívocamente mayor complejidad, ¿por qué no tenemos planificaciones para simplificar? ¿Tienen sentido los roadmaps negativos? ¿Roadmaps de eliminación de funcionalidad?
Tan apenas nadie invierte en eliminar funcionalidad, por lo que con cada nueva funcionalidad se hace la bola más grande. Invertir en eliminar una funcionalidad no significa simplemente deshacerla, si no limpiar la base de código del producto y simplificarla.
No invertir en reducir complejidad implica que se creen cuellos de botella en ingeniería y acabemos echando la culpa de todos nuestros males, de manera injusta, a los departamentos de desarrollo.
Os invito a uniros en mi cruzada de este año, sumaros al movimiento “menos es más”.
