Prototipar rápido y saber cuándo escalar a desarrolladores

El equipo de personas de una agencia quiere cambiar el mail eterno de bienvenida por una lista de tareas interactiva para los ingresantes. La líder propone pasar un mes escribiendo una especificación completa antes de mostrar nada. Un compañero propone lo contrario: armarla y mandarla directo a los treinta ingresantes del mes que viene. Mientras tanto, cuatro personas que entraron esta semana se ofrecieron a probar lo que sea.

Ninguno de los dos planes aprovecha lo mejor que tiene Claude: hacer una primera versión en minutos.

Primero una versión que se pueda tocar

Con Claude, una persona sin conocimientos técnicos puede armar un prototipo (prototype) funcional: una lista de verificación, una calculadora, un tablero simple, una plantilla interactiva. Muchas veces sale como un artifact (artifact), el panel donde Claude muestra contenido independiente que se puede ver, usar y ajustar.

El valor de un prototipo no es que esté completo, sino que alguien lo pueda usar y decir qué le falta. El ciclo es corto:

1. Armá una versión mínima que resuelva el caso más común.
2. Probala con pocos usuarios reales, los que van a usarla de verdad.
3. Juntá su retroalimentación (user feedback): qué no entendieron, qué buscaron y no encontraron, qué sobra.
4. Ajustá con Claude sobre esa misma versión y volvé a probar.

Cada vuelta es una iteración (iteration). Tres iteraciones con cuatro usuarios enseñan más que un mes de especificación, y mucho más que preguntarle a Claude “qué les va a molestar a los ingresantes”: una predicción no reemplaza una prueba.

Hasta dónde llega el prototipo

Un día el prototipo funciona demasiado bien. Una asociada de marketing armó una calculadora de puntaje de clientes potenciales: los vendedores pegan los datos y reciben un puntaje con los motivos. Después de un mes, los vendedores dicen que les ahorra tiempo. Ahora el director quiere que cada cliente nuevo se puntúe solo al entrar al CRM, que el puntaje se guarde en la ficha y que le llegue un aviso al vendedor.

Eso ya no es un prototipo más grande: es una integración (integration) con un sistema de la empresa, con escritura automática de datos y avisos. Le corresponde a quien desarrolla e integra sistemas, no a quien usa Claude como herramienta de productividad.

Señal	Qué significa
Conectarse a un sistema interno (CRM, ERP, base de clientes) y escribir en él	Escalar a desarrollo
Que corra solo, sin que nadie lo dispare, para cientos de casos	Escalar a desarrollo o arquitectura
Ajustar textos, reglas o formato de lo que ya existe	Lo seguís iterando vos

Escalar bien

Escalar (escalate) no es tirar el problema por encima de la pared. Lo que más le sirve al equipo técnico es lo que ya probaste:

• el prototipo que funciona;
• las reglas que usa (por ejemplo, los criterios del puntaje);
• los resultados de uso: cuántas personas, cuánto tiempo ahorraron, qué falló.

Con eso, desarrollo arranca con requisitos validados en vez de una idea.

Las trampas típicas

• Escribir la especificación perfecta antes de que nadie vea nada.
• Lanzar a todos de una sin una prueba chica.
• Pedirle a Claude que adivine las quejas en lugar de preguntar a usuarios.
• Seguir estirando el artifact hasta que “se conecte solo” al sistema.
• Decir que lo que pide el director es imposible.
• Resolverlo con trabajo manual: que cada vendedor pegue cada cliente nuevo a mano.

En el examen

Si hay usuarios disponibles para probar, la respuesta es una versión rápida probada con ellos y ajustada según lo que digan. Si el pedido incluye conectarse a sistemas, escribir datos o automatizar a escala, la respuesta es escalar a desarrolladores o arquitectos con el prototipo, las reglas y los resultados. Descartá la parálisis, el lanzamiento masivo, la predicción en lugar de prueba y el “lo hago igual” fuera del rol.