No empieces una prueba. Decide antes qué vas a comprobar.

• Lo que encaja

  ¿Resuelve el problema que tienes de verdad, para el trabajo que haces de verdad?

• Lo que roza

  ¿Qué será incómodo de configurar, aprender, migrar o mantener cuando pase la novedad?

• Lo que cedes

  ¿Qué entregas a cambio: dinero, flexibilidad, control o la facilidad de marcharte?

La mayoría de las malas decisiones de software no vienen de una función que falta. Vienen de juzgar el encaje sin mirar el roce, o de aceptar una cesión que nadie escribió. Un producto puede hacer todo lo que pediste y seguir siendo una mala compra si configurarlo exige tres semanas que no tienes, o si salir de él más tarde obliga a rehacer un trabajo que no se exporta.

La utilidad práctica de las tres lecturas es obligarte a escribir una frase por cada una. Qué problema resuelve, en palabras que un compañero reconocería. Qué será incómodo, dicho con precisión y no con un encogimiento de hombros. Qué entregas a cambio: dinero, flexibilidad, control o la posibilidad de cambiar de idea barato.

La costumbre más útil es escribir el problema antes de que empiece la prueba. Una prueba sin pregunta se convierte en un paseo; una prueba con pregunta se convierte en un test con respuesta al final.

Trabaja con datos reales. Un espacio lleno de fichas de ejemplo se comporta de maravilla y no demuestra nada sobre el cliente cuyo apellido lleva apóstrofo, ni sobre la consulta que llegó sin teléfono. Una fricción encontrada durante la prueba sale gratis; la misma en el tercer mes, no.

Pregunta esto mientras aún tienes capacidad de negociación. Firmado el compromiso anual, «qué pasa si queremos irnos en marzo» se vuelve una pregunta teórica. La mayoría de proveedores responde con claridad; los que te derivan a una llamada también te están diciendo algo.

Una prueba te enseña el producto en su mejor momento: vacío, rápido, con avisos de bienvenida y un soporte que contesta. No te enseña el producto con tres mil fichas, dos años de historial, un compañero que se fue y una integración rota porque el otro proveedor cambió su API. Esas son las condiciones que deciden si sigues pagando, y ninguna prueba las reproduce.

Lo que una prueba sí enseña, si la usas a propósito: si la forma del producto encaja con la forma de tu trabajo, cuánto tarda una tarea real, cómo se comporta con datos imperfectos y si la gente que no eres tú lo va a tolerar. Esas cuatro respuestas valen más que una lista de funciones el doble de larga.

Imagina una agencia de cuatro personas evaluando una plataforma que promete sustituir tres suscripciones. Lo que encaja: el fallo que saben nombrar es que los presupuestos se quedan sin respuesta quince días, así que la prueba es si un presupuesto puede llevar responsable, fecha y recordatorio automático. Lo que roza: no tienen administrador, de modo que todo lo que exija un especialista es un coste que no pagarán. Lo que ceden: juntar tres herramientas en una significa que un solo proveedor guarda todo el historial del cliente, lo que hace innegociable la prueba de exportación. Eso es evaluar. Lo demás es mirar escaparates.

Tres páginas aplican el método a un producto, GoHighLevel, que además es aquel por el que este sitio cobra comisión. Está dicho al pie de todas las páginas, y por eso esas páginas citan al proveedor con fechas en vez de pedir que se les crea: las condiciones de prueba tal y como se publican, los precios tal y como se publican, y una evaluación que enumera roces y cesiones con la misma precisión que las virtudes.