Que tus clientes (o tú mismo) quieran añadir una funcionalidad nueva a tu programa no significa que darles la razón e implementarla sea una buena idea. De hecho, seguramente es una muy mala idea.

Ya sabéis que aquí somos seguidores de la filosofía Basecamp para startups, que incluye el “menos es más”.

Di que no a cada petición para integrar una nueva funcionalidad. Cada vez quedices que sí a una nueva feature estás adoptando un hijo. Y te va a salir caro. No vas a poder darlo en adopción. Share on X

Lo que muchas veces no llegamos a comprender es hasta qué punto nos sale caro añadir una nueva funcionalidad. En este tweet, John Cutler hizo una lista del precio real de implementar una nueva funcionalidad, lista que rápidamente se vio ampliada por un gran número de contribuciones de otros que hemos sufrido este optimismo típico de todo programador: “nada, esto te lo hago en un par de días”.

Os hago mi interpretación / resumen de la discusión. Veamos pues, todos los costes de implementar una funcionalidad:

  1. Coste de implementar la funcionalidad (incluyendo la funcionalidad en sí pero también la interfaz, el testing,…)
  2. Coste de oportunidad (si implementamos ésta, no implementamos otra)
  3. Coste de todas las mejoras incrementales a esa misma funcionalidad
  4. Coste de desplegar y ejecutar esa funcionalidad
  5. Coste de entrenar a los comerciales para que conozcan y puedan vender la funcionalidad
  6. Coste de entrenar a la gente de soporte para que puedan contestar dudas acerca de la funcionalidad
  7. Coste de anunciar la funcionalidad a los clientes (nuevos y futuros)
  8. Coste de documentar la funcionalidad y entrenar a los usuarios
  9. Coste de mantener un código global ahora un poco más complejo
  10. Coste de tener un código global menos flexible debido a su creciente complejidad y dependencias
  11. Coste de contratar más gente para poder gestionar mejor esta mayor complejidad
  12. Coste de todas las reuniones asociadas a todos los puntos anteriores
  13. Coste legal de añadir la nueva funcionalidad  a los términos y condiciones de uso del producto

Y podríamos seguir (¿Cuál añadiríais vosotros?), pero creo que ya pilláis la idea. Claro que si tenemos que tener en cuenta todo esto a lo mejor no implementaríamos nunca nada. Pues casi. Sólo cuando una funcionalidad pueda llegar a tener un ROI que permita contrarrestar toda esta lista (sobre todo el coste de oportunidad) id a por ella. Para todo lo demás, utilizad esta lista para sentiros mejor al decir no a un cliente entusiasta. Y es que como también dicen los amigos de Basecamp:

 Muchas de las veces que un cliente te pide una funcionalidad “clave” resulta que al final no era tan importante y si le dices que no se olvida de ella rápidamente.

 

Otra opción como también comenta Eduards Sizovs (ver el hilo del tweet que añado a continuación) es “empoderar” a los usuarios para que sean capaces de, hasta cierto punto, crear ellos mismos sus adaptaciones con herramientas tipo no-code.