El cementerio de funciones: ¿qué pasa con las funciones que nadie usa?

Todos los productos las tienen.

Funciones que llevaron días construir.

Funciones que sonaban emocionantes en las reuniones de planificación.

Funciones que todo el mundo estaba convencido de que a los usuarios les iban a encantar.

Y luego…

Nadie las usó.

Se quedan ahí, calladas dentro del producto, ocupando espacio, sumando complejidad y convirtiéndose poco a poco en algo en lo que el equipo deja de pensar.

Bienvenido al cementerio de funciones.

Toda función nace por un motivo

La mayoría de las funciones que nadie usa no son malas ideas.

Eso es lo que hace interesante este problema.

Normalmente, un equipo no construye algo porque sí.

Quizá los usuarios lo pidieron.

Quizá un competidor lo lanzó.

Quizá las analíticas mostraban una oportunidad.

Quizá el fundador pensó que mejoraría el producto.

O quizá el equipo simplemente creyó:

«A los usuarios les va a encantar».

Así que lo construyen.

Lo prueban.

Lo lanzan.

Y entonces llegan los números.

Casi nadie hace clic.

Construir es más fácil que quitar

Una vez que una función existe, quitarla puede sentirse como admitir un fracaso.

Las conversaciones suelen sonar más o menos así:

• «Pero si nos pasamos tres semanas construyendo esto».
• «¿Y si los usuarios lo necesitan más adelante?».
• «A lo mejor la gente todavía no lo ha descubierto».
• «Dejémoslo por ahora».

Y la función se queda.

Luego se añade otra función.

Y otra.

Y otra.

Con el tiempo, el producto se vuelve complicado. No porque nadie lo planeara así, sino porque nunca se quita nada.

El costo oculto de una función que nadie usa

Una función sin uso no te pasa una factura cada vez que alguien la ignora.

Pero aun así le cuesta al equipo.

Puede:

• Hacer que la interfaz sea más difícil de recorrer.
• Aumentar el trabajo de mantenimiento.
• Añadir más pruebas.
• Generar más documentación.
• Aumentar las consultas a soporte.
• Hacer el onboarding más confuso.
• Quitar atención a funciones más importantes.

Una función puede tener casi cero usuarios y aun así generar trabajo.

Esa es una de las cosas raras del software.

El código que nadie usa también tiene un costo.

Más funciones no siempre significan más valor

Es fácil medir el progreso por el número de funciones lanzadas.

Cinco funciones este mes.

Diez el mes que viene.

Veinte a final de año.

Da sensación de productividad.

Pero los usuarios no eligen un producto porque tenga la lista de funciones más larga.

Lo eligen porque les ayuda a hacer algo mejor, más rápido o más fácil.

A veces una función nueva mejora esa experiencia.

A veces solo les da a los usuarios una cosa más que descifrar.

Más no es automáticamente mejor.

A veces es solo más.

¿Y si los usuarios no encuentran la función?

Aquí es donde la cosa se pone interesante.

Una función con poco uso no es necesariamente una función inútil.

Quizá los usuarios simplemente no saben que existe.

Esa diferencia importa.

Antes de quitar algo, pregúntate:

«¿Los usuarios ignoran esta función o es que no la encuentran?».

Una función útil enterrada en un menú confuso puede parecer completamente inútil en tus analíticas.

Un mejor onboarding podría ayudar.

Una navegación más clara podría ayudar.

Una etiqueta mejor podría ayudar.

Un pequeño aviso dentro del producto podría ayudar.

Así que, antes de mandar una función al cementerio, asegúrate de que de verdad merece acabar ahí.

Habla con los usuarios que sí la usan

Las analíticas te dicen qué está pasando.

Los usuarios a menudo te dicen por qué.

Si solo el 2% de los usuarios usa una función, habla con algunos de ellos.

Pregúntales:

• «¿Por qué la usas?».
• «¿Qué problema te resuelve?».
• «¿Qué harías si esta función desapareciera mañana?».

Puede que descubras que la función no es popular, pero que es muy valiosa para un grupo pequeño de usuarios.

Y esa distinción es importante.

Una función no tiene que ser popular para ser valiosa.

La pregunta a la que se enfrenta toda función tarde o temprano

En algún momento, todo equipo de producto debería preguntarse:

«Si hoy no tuviéramos esta función, ¿la volveríamos a construir?».

Si la respuesta es no, merece la pena investigarlo.

Quizá la función necesita un rediseño.

Quizá debería quedar oculta para la mayoría de los usuarios.

Quizá debería combinarse con otra cosa.

O quizá… debería desaparecer.

El tiempo que ya se invirtió en construir algo no debería decidir si merece quedarse.

Eso es caer en la trampa del costo hundido.

Quitar una función también es desarrollo de producto

Borrar algo puede sentirse como dar un paso atrás.

No lo es.

Quitar complejidad innecesaria también puede ser progreso.

Cuando una función desaparece, el producto puede volverse:

• Más fácil de entender.
• Más fácil de mantener.
• Más fácil de aprender a usar.
• Más fácil de explicar.
• Más fácil de recorrer.

A veces la mejor actualización de producto no es:

«Hemos añadido algo nuevo».

Es:

«Hemos simplificado el producto».

Y puede que los usuarios lo agradezcan más que otro botón en la interfaz.

Pero no lo conviertas en una limpieza a ciegas

Aquí hay otra trampa.

Un equipo puede obsesionarse con quitar todo lo que no tenga cifras de uso enormes.

Eso no siempre es buena idea.

Algunas funciones se usan poco, pero se vuelven importantísimas cuando alguien las necesita.

Piensa en un botón de exportar.

Puede que la mayoría de los usuarios no lo toque nunca.

Pero los que sí lo usan pueden depender de él.

Así que el uso, por sí solo, no debería decidir el destino de una función.

Mira el panorama completo:

Uso + valor + opiniones de los usuarios + costo de mantenimiento.

Es una forma mucho mejor de evaluar si algo merece quedarse.

Construye a partir de una pregunta, no solo de una función

Antes de construir algo, pregúntate:

¿Qué problema estamos resolviendo?

Después:

¿Quién tiene realmente este problema?

Y por último:

¿Cómo sabremos que lo hemos resuelto?

Son preguntas que parecen sencillas.

Pero pueden ahorrar semanas de desarrollo.

En lugar de celebrar cuántas funciones ha lanzado el equipo, celebra cuántos problemas reales se han resuelto.

Es una medida de progreso mucho mejor.

El cementerio no siempre es algo malo

Todo producto acabará teniendo funciones que no salieron bien.

Es normal.

Algunas ideas fracasarán.

Algunos experimentos no despegarán.

Algunas funciones quedarán obsoletas.

Es parte de construir software.

El objetivo no es evitar del todo el cementerio de funciones.

El objetivo es aprender de lo que termina ahí.

Si cinco funciones fracasan por el mismo motivo, eso es información útil.

Si los usuarios ignoran sistemáticamente cierto tipo de funcionalidad, eso es una señal.

Si quitar algo mejora la interacción, eso es una lección.

El fracaso se vuelve valioso cuando le prestas atención.

Reflexiones finales

Los buenos productos no se construyen añadiendo sin parar.

Se construyen entendiendo qué merece quedarse.

Cada función debería ganarse su sitio. No porque el equipo pasara semanas construyéndola, sino porque de verdad ayuda a alguien.

A veces eso significa construir algo nuevo.

A veces significa mejorar algo que ya existe.

Y a veces…

significa abrir el cementerio de funciones y, por fin, dejar ir algo.

Porque en el software, menos no siempre es más.

Pero lo innecesario nunca sale gratis.