El botón que no construí: fronesis para decidir qué se implementa

Una peluquería de barrio, casi cuatro décadas abierta. La web que había que rehacer pedía a gritos, según el manual, un sistema de reservas online: calendario, franjas, confirmación por email. Lo tenía medio diseñado antes de la primera reunión.

Entonces pregunté cómo pedía cita la gente. La respuesta fue que llamando, y los más jóvenes por WhatsApp. Que el móvil está en el mostrador. Que a veces entras y esperas, y ese rato de espera es parte del sitio.

No construí el calendario. Fue la mejor decisión técnica del proyecto y no aparece en ninguna línea de código.

Techne no es fronesis

Aristóteles separaba dos formas de saber que solemos tratar como una. La techne es el saber del artesano: cómo se hace bien una cosa. La fronesis —sabiduría práctica— es otra cosa: saber qué conviene hacer en esta situación concreta, que no es deducible de ninguna regla general.

La distinción no es un matiz académico. La techne de un motor de reservas es aprendible: disponibilidad, colisiones, zonas horarias, recordatorios, cancelaciones. Cualquiera con oficio la adquiere. La fronesis es responder si esa peluquería necesita un motor de reservas, y esa pregunta no la contesta el manual, porque el manual habla de “webs de servicios” y aquí no hay una web de servicios: hay un local con un señor, un teléfono y una clientela que lleva treinta años entrando sin avisar.

Aristóteles decía que la deliberación no versa sobre lo eterno, sino sobre lo que está en nuestro poder y puede ser de otra manera. El sector tiene reglas buenas. Las reglas buenas describen el agregado. Ningún cliente es el agregado.

La regla general es verdadera y aquí no aplica

“Toda web de servicios necesita reserva online” es un enunciado razonable. En la mayoría de los negocios de ese tipo, reduce fricción y captura demanda fuera de horario.

Y aun así, en aquel local habría sido un error. No porque la regla sea falsa, sino porque una regla general se aplica a casos particulares y el caso particular tiene la última palabra. El error de juicio no es tener malas reglas: es aplicarlas sin mirar delante de quién estás.

Lo que se instala cuando aplicas la regla a ciegas no es una funcionalidad. Es una promesa. Un calendario público promete que las franjas que muestra son reales, que alguien las mantiene, que si reservas el jueves a las 17:00 el jueves a las 17:00 hay sitio. Esa promesa la sostiene una persona con las manos ocupadas todo el día.

La herramienta que estorba

Heidegger describió la diferencia entre el útil que está a la mano y el objeto que está ahí delante. El martillo, cuando funciona, desaparece: clavas, no piensas en el martillo. Solo cuando se rompe aparece como cosa, y entonces estorba.

Un panel de reservas que nadie abre es exactamente eso: una herramienta rota que se ha vuelto objeto. Ocupa sitio en el mostrador mental del cliente, le genera culpa cada vez que se acuerda de que no lo ha mirado, y acaba mintiendo a quien reserva. El teléfono, en cambio, ya era invisible: llevaba décadas siendo transparente para todos.

Sustituir una herramienta invisible que funciona por una visible que hay que aprender es un mal negocio, aunque la segunda sea técnicamente superior.

Lo que sí construí

Nada espectacular. Un botón de WhatsApp que abre el chat con el mensaje empezado. Un botón de llamar que llama. Horarios visibles sin scroll y dirección con enlace al mapa. Página estática, carga inmediata, sin panel de administración porque no hay nada que administrar.

Aburrido de contar y difícil de defender en una reunión donde alguien enseña un calendario animado. Pero es lo que la gente de ese barrio ya sabía usar, y lo que el dueño puede sostener sin cambiar cómo trabaja.

Fronesis corta en las dos direcciones

Esto no es una defensa del minimalismo. La sabiduría práctica no dice “construye menos”, dice “mira el caso”.

Ese mismo año, otro proyecto: un servicio de peritaje de vehículos a domicilio. Allí sí monté reserva de franja horaria con pago por adelantado, que es bastante más complejo que un calendario de peluquería. Y era lo correcto, porque el negocio ya funcionaba así —cerrando visitas y cobrando por teléfono, con dolor— y la reserva online no cambiaba el hábito: le quitaba trabajo. Cuando el sistema formaliza algo que ya ocurre, se adopta solo. Cuando pretende crear un hábito nuevo, hay que preguntarse quién va a pagar el aprendizaje.

Misma decisión de arquitectura, resultado opuesto. No porque una tenga mejor criterio técnico que la otra, sino porque son sitios distintos.

Las cuatro preguntas que me hago ahora

• ¿Quién mantiene esto un martes por la tarde? Si la respuesta es “nadie tiene tiempo”, la funcionalidad ya está rota, solo que todavía no se nota.
• ¿Sustituye a un hábito o compite con él? Lo que sustituye se adopta. Lo que compite con el teléfono, con el WhatsApp o con entrar y esperar, pierde.
• ¿Qué pasa si nadie lo abre? Si la respuesta es “el cliente queda mal con alguien”, eso no es una funcionalidad opcional: es un riesgo con interfaz bonita.
• ¿La alternativa aburrida ya funciona? Casi siempre sí. Y casi siempre la descarto por costumbre profesional, no por criterio.

El oficio de decidir

En la navaja de Ockham escribí que cada abstracción es una apuesta sobre el futuro. Cada funcionalidad lo es también, pero apuesta sobre algo más difícil de predecir que el código: apuesta sobre una persona, sus manos, su horario y sus costumbres.

Un desarrollador con techne sabe cómo se construye cualquier cosa. Es una condición necesaria y no es la parte difícil. La parte difícil, la que se paga y la que no se automatiza, es mirar un negocio concreto y decidir qué de todo lo que sabes hacer no hay que hacer aquí.

Aristóteles pensaba que la fronesis no se enseña con reglas: se adquiere deliberando en casos reales, y equivocándose. Después de unos cuantos proyectos, lo confirmo. La única regla que me ha servido es la de preguntar antes de diseñar, y aguantar la incomodidad de entregar algo más pequeño de lo que sabía construir.