Desperdicio 2: Funciones Adicionales
Construir cosas que nadie necesita—el desperdicio más costoso de todos.
1La Trampa de la Sobreproducción
En manufactura, la sobreproducción significa hacer más de lo que los clientes ordenaron. En software, significa construir funciones que nadie usa.
Los estudios muestran consistentemente que 60-80% de las funciones rara vez o nunca se usan. Piensa en eso. La mayoría de lo que los equipos de software construyen no crea valor.
Este es el desperdicio más costoso porque tiene costos compuestos:
- Costo de desarrollo: Tiempo para construir la función
- Costo de mantenimiento: Cada función agrega complejidad para siempre
- Costo de oportunidad: ¿Qué más podrías haber construido?
- Costo para el usuario: Más funciones significan productos más difíciles de usar
Una función que nunca se usa no es gratis—te cuesta cada día en carga cognitiva, carga de pruebas, documentación y posibles errores.
El Costo de Mantenimiento
Cada función tiene un costo de mantenimiento. Necesita pruebas. Puede fallar. Complica el código base. Confunde a los usuarios. Las funciones no utilizadas tienen valor negativo—cuestan más que nada.
2Por Qué Se Construyen Funciones Adicionales
Los equipos construyen funciones innecesarias por muchas razones:
"Ya que estamos en eso": Agregar alcance porque parece eficiente agrupar. No lo es—retrasa el trabajo valioso y agrega desperdicio.
Requisitos imaginados: Construir para usuarios con los que no has hablado. Las suposiciones se acumulan en desperdicio.
Pulido excesivo: Ingenieros agregando sofisticación técnica que no sirve a los usuarios. Abstracciones que nadie reutilizará. Optimización de rendimiento para funciones que nadie usa.
Funciones por FOMO: "¡El competidor X tiene esta función!" Tal vez sus usuarios tampoco la usan.
Funciones políticas: Funciones construidas porque alguien importante las solicitó, no porque los usuarios las necesiten.
Sobre-ingeniería: Construir para una escala que nunca alcanzarás. Diseñar para flexibilidad que nunca usarás. "¿Pero qué pasa si necesitamos soportar un millón de usuarios?" Probablemente no lo harás.
Lo opuesto a funciones adicionales no es pobreza de funciones. Es enfoque. Construye exactamente lo que se necesita, nada más, y constrúyelo bien.
Un equipo pasó dos meses construyendo exportación CSV/Excel/PDF para una función de reportes. Las analíticas mostraron que 3 usuarios alguna vez usaron la exportación. La función permanece en el código base, agregando carga de pruebas y costo de mantenimiento para siempre.
Un equipo necesitaba soportar un proveedor de pagos. Construyeron exactamente eso—sin abstracción para múltiples proveedores. Más tarde, cuando realmente necesitaron un segundo proveedor, refactorizaron. El costo total fue menor de lo que hubiera sido la abstracción inicial.
3Prevenir Funciones Adicionales
Valida antes de construir: Habla con los usuarios. Ejecuta experimentos. Usa prototipos. La función más barata es la que no construyes.
YAGNI (No Vas a Necesitarlo): No construyas para requisitos futuros imaginarios. Construye lo que necesitas ahora. Refactoriza después si los requisitos cambian—y a menudo no cambian.
Mínimo Viable en Todo: ¿Qué es lo más pequeño que probaría esta hipótesis? Construye eso. Aprende. Itera.
Depreciación basada en datos: Mide el uso de funciones. Elimina funciones que no se usan. El valor de eliminar es tan importante como la disciplina de no agregar.
Di no más que sí: El valor predeterminado para nuevas funciones debe ser "no". Las funciones necesitan justificarse. Decir no a una buena idea a menudo es correcto porque deberías estar trabajando en una gran idea en su lugar.
Presupuestos de funciones: Por cada nueva función, elimina una antigua. Esto fuerza la priorización y previene la hinchazón.
Los mejores equipos no están orgullosos de lo que construyeron—están orgullosos de lo que eligieron no construir.
Cada función que no construyes es un ahorro infinito: sin desarrollo, sin pruebas, sin mantenimiento, sin documentación, sin errores, sin confusión—para siempre.
- 60-80% de las funciones de software rara vez o nunca se usan
- Las funciones adicionales tienen costos compuestos que nunca se detienen
- Construye para necesidades validadas, no requisitos imaginados
- YAGNI: No construyas para necesidades futuras que tal vez nunca lleguen
- Los mejores equipos están orgullosos de lo que no construyeron
- •Agrupar alcance adicional porque ya estás 'en el código'
- •Construir abstracciones antes de tener múltiples casos de uso
- •Asumir que los usuarios quieren funciones porque los competidores las tienen
- •Sobre-ingenierizar para una escala que nunca alcanzarás