Idea principal

La complejidad de un producto se lee de ordinario en su código: tamaño de los archivos, número de capas, dependencias. Es la parte menos costosa. Una funcionalidad entregada se paga después en el usuario que debe entender para qué sirve, en los tickets de soporte que abre, en la documentación que hay que escribir y mantener, en la coherencia de una experiencia que se enturbia con cada añadido, y en la capacidad de la organización de explicar lo que fabrica.

Esas partidas no se aceleran. Cuando el código se convierte en el eslabón rápido, los cuellos de botella se desplazan hacia la revisión, la seguridad, el encuadre funcional, la integración y la absorción humana, que se vuelven incluso más críticos que antes, puesto que reciben más.

Un producto se vuelve, pues, ilegible, tanto para sus usuarios como para sus equipos, en cuanto se añaden funcionalidades más rápido de lo que se entiende su uso. Producir más código no es producir más valor; es desplazar la factura hacia servicios que no la han provisionado.

Por qué es importante

Esto cambia lo que se cuenta al arbitrar un añadido. El coste de desarrollo, hoy bajo, deja de ser un indicador del coste total, y una estimación que se detiene en el código subestima sistemáticamente lo que una funcionalidad compromete.

También da al soporte y a la documentación un estatus de alerta temprana: son los primeros lugares donde una complejidad decidida en otra parte se vuelve medible.

Matices y límites

No toda complejidad la sufre el usuario. Una funcionalidad invisible, activada por defecto y sin superficie de uso, puede recargar considerablemente el código sin costar nada en adopción ni en soporte: la factura sigue entera, pero dentro del equipo.

Y el razonamiento tiene un límite: una organización que solo entregara lo que el soporte absorbe sin esfuerzo entregaría poco y dejaría a un competidor ocupar el sitio. La cuestión es la provisión, no la abstención.

Preguntas abiertas

• ¿Cómo estimar, antes de entregar, la carga de adopción y de soporte de una funcionalidad, de otro modo que constatando a posteriori los tickets que genera?