Dimensionar Trabajo de IA para Clientes No-Técnicos: Rangos, Spikes, y Escribir qué es 'Suficientemente Bueno'
Resumen
Los clientes no-técnicos hacen dos preguntas sobre el trabajo de IA: cuánto tiempo, y cuánto dinero. Responder con un solo número es como la mayoría de los proyectos de IA empiezan a mentirle a quienes los patrocinan. Lo aprendí a la mala construyendo agentes de voz para pequeños negocios en Shining Image, y aplico la misma disciplina al trabajo de plataforma ahora. El método tiene cuatro partes. Divide cada proyecto en la parte determinística, que puedes estimar como software normal, y la parte incierta, que depende de qué tan bien un modelo maneja datos reales. Vende un spike de descubrimiento corto y con tiempo fijo sobre la parte incierta que termine en una decisión explícita: seguir, acotar o parar. Da rangos, y nombra qué los mueve. Y antes de construir nada, escribe qué significa 'suficientemente bueno' como ejemplos concretos con los que el cliente esté de acuerdo. La meta no es una estimación perfecta. Es una estimación que no sorprenda a nadie.
Hace años en Shining Image, el dueño de un pequeño negocio de servicios me hizo una pregunta que he escuchado en cien variaciones desde entonces: "¿Puedes hacer que el teléfono se conteste solo cuando estamos ocupados? ¿Cuánto tiempo tomaría eso?"
Le dije tres semanas.
No estaba mintiendo. Tenía una imagen mental del trabajo: un número de Twilio, voz a texto, un modelo para entender a quien llama, una conexión al calendario, texto a voz de regreso. Había construido la mayoría de esas piezas antes. Tres semanas se sentía generoso.
La integración telefónica estuvo lista en más o menos una semana. La conexión al calendario tomó unos días. Y luego pasé un tramo largo y humillante descubriendo que las personas reales que llaman no hablan como mis guiones de prueba. Murmuran direcciones. Llaman desde una camioneta con la ventana abajo. Hacen tres preguntas en un solo respiro y luego cambian de opinión sobre la segunda. Lograr que el agente manejara esas llamadas lo suficientemente bien como para confiarle un cliente real tomó mucho más que las tres semanas que había prometido para todo.
El dueño fue comprensivo. Pero recuerdo la llamada donde tuve que explicar el retraso, y recuerdo que no pude explicar el porqué de una forma que tuviera sentido para alguien que no construye software. Para él, el teléfono contestaba o no contestaba. Contestó en la semana uno. ¿Qué seguía haciendo yo?
Esa llamada me enseñó más sobre dimensionar trabajo de IA que cualquier cosa que haya leído desde entonces. Este es el método que uso ahora — para pequeños negocios, y para trabajo de plataforma en TheGreyMatter.ai, donde los interesados son distintos pero la pregunta es exactamente la misma.
La Pregunta Detrás de "¿Cuánto Tiempo Va a Tomar?"
Cuando un cliente no-técnico pregunta cuánto tiempo tomará algo, rara vez está pidiendo un número. Está preguntando tres cosas a la vez:
- ¿Puedo planificar alrededor de esto?
- ¿Me voy a llevar una sorpresa?
- ¿Esta persona me va a decir la verdad cuando las cosas cambien?
Un solo número seguro responde la primera pregunta y falla en silencio las otras dos. Con software tradicional, normalmente te sales con la tuya, porque la incertidumbre está mayormente en el esfuerzo, y el esfuerzo se puede empujar. Con trabajo de IA, una gran parte de la incertidumbre está en si la cosa funciona siquiera con los datos de este cliente, y ninguna cantidad de esfuerzo garantiza que la respuesta sea sí.
Esa es la raíz de casi todos los proyectos de IA estancados que he visto, y es por eso que escribí sobre por qué se estancan los pilotos de IA. La mayoría no murieron por mala ingeniería. Murieron por una estimación que fingió que la parte incierta era cierta.
1. Divide el Trabajo en Dos Montones
Lo primero que hago con cualquier proyecto de IA es dividirlo, en papel, en dos montones.
┌─────────────────────────────────────┐
│ EL PROYECTO COMPLETO │
└──────────────────┬──────────────────┘
│
┌───────────────────────┴───────────────────────┐
▼ ▼
MONTÓN DETERMINÍSTICO MONTÓN INCIERTO
(estima como software normal) (estima como experimentos)
- número telefónico + enrutamiento - ¿entiende el modelo a quienes
- integración de calendario / CRM llaman lo suficientemente bien?
- auth, almacenamiento, logs - ¿puede extraer los campos
- pantalla de admin para el dueño correctos de entradas confusas?
- respaldo: tomar un mensaje - ¿qué tan seguido necesita a un
- notificaciones, cobros humano, y está bien eso?
incógnitas conocidas, forma de esfuerzo incógnitas desconocidas, forma de datos
El montón determinístico es software normal. Integraciones, pantallas, almacenamiento, auth, notificaciones. He construido suficientes de estos como para estimarlos de la forma normal, con el margen normal, y usualmente me acerco.
El montón incierto es todo aquello cuyo éxito depende de cómo se comporta un modelo con entradas del mundo real. Entender voz. Extraer campos de documentos que nadie estandarizó. Clasificar solicitudes que no encajan limpiamente en categorías. Estas no son tareas de ingeniería en el sentido usual. Son experimentos, y los experimentos no tienen fechas de entrega. Tienen presupuestos.
Mostrarle esta división a un cliente es, por sí solo, la mitad de la conversación. Las personas no-técnicas lo entienden de inmediato una vez que está dibujado. "Este lado es como construir un sitio web. Este lado es como entrenar a un empleado nuevo — no sabremos qué tan bueno es hasta verlo trabajar." Ese encuadre nunca me ha fallado.
La mayor parte del proyecto no es IA
En casi todos los proyectos de IA que he dimensionado, el montón determinístico es más grande que el incierto. Eso es una buena noticia: significa que la mayor parte del trabajo se puede estimar con confianza. Dilo. Los clientes se relajan cuando aprenden que la parte desconocida que da miedo es una tajada, no todo el pastel.
Un efecto secundario útil: la división a menudo revela que parte del montón incierto no necesita un modelo para nada. Una solicitud que sonaba como "la IA entiende al cliente" resulta ser "un menú desplegable y dos reglas." Mover trabajo del montón incierto al determinístico es la reducción de riesgo más barata que existe.
2. Vende un Spike de Descubrimiento que Termine en una Decisión
Para el montón incierto, no doy una estimación por adelantado. Vendo un spike.
Un spike de descubrimiento es corto y con tiempo fijo — usualmente una o dos semanas, según el proyecto. Tiene exactamente un trabajo: poner a prueba la suposición más riesgosa contra los datos reales del cliente y regresar con una decisión. No un demo. Una decisión.
La decisión tiene tres resultados posibles, y le digo al cliente los tres antes de empezar:
SPIKE DE DESCUBRIMIENTO
(tiempo fijo, precio fijo)
│
probar la suposición más riesgosa con datos reales
medir contra el "suficientemente bueno" acordado
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
SEGUIR ACOTAR PARAR
funciona bastante funciona para todavía no funciona
bien un subconjunto lo suficiente
→ estimación → alcance menor, → te ahorraste el costo
completa con re-estimar de construir todo
confianza
La opción "parar" importa más de lo que parece. Cuando un cliente sabe desde el primer día que parar es un resultado legítimo, incluso exitoso, el spike se vuelve una investigación honesta en vez de una presentación de ventas que estoy presionado a hacer funcionar. Y cuando un spike sí dice parar, el cliente gastó una cantidad pequeña y conocida para evitar una grande y desconocida. Varios de los clientes más agradecidos que he tenido fueron aquellos donde el spike dijo "todavía no."
"Acotar" es el resultado más común, y el más valioso. El agente de voz que no puede manejar todas las llamadas podría manejar extremadamente bien la agenda de citas y tener problemas con cotizaciones complicadas. Entonces el alcance se vuelve: el agente agenda citas, y todo lo demás se convierte en un mensaje bien escrito para el dueño. Ese es un producto real, entregado antes, que hace una cosa de forma confiable.
Un spike produce un memo, no un prototipo
El entregable de un spike de descubrimiento es un memo de una página: qué probamos, con qué datos, contra qué definición de suficientemente bueno, qué encontramos, y cuál de seguir, acotar o parar recomiendo. Los prototipos son seductores y se confunden con productos casi terminados. Un memo se lee como lo que es — evidencia para una decisión.
3. Da Rangos, y Nombra Qué los Mueve
Después del spike, puedo estimar todo el proyecto. Igual doy un rango, no un punto.
La diferencia es que ahora el rango es explicable. Puedo decir: "Las integraciones, pantallas y flujos de respaldo son más o menos tanto trabajo, y tengo confianza en esa parte. El trabajo del modelo es un rango porque depende de cuántos casos borde aparezcan una vez que clientes reales lo usen. Esto es lo que nos empujaría al extremo bajo, y esto es lo que nos empujaría al extremo alto."
malo: "Va a tomar seis semanas."
mejor: "De cuatro a siete semanas.
- La integración y el trabajo de admin son unas tres semanas;
tengo confianza en eso.
- El ajuste del agente es de una a cuatro semanas. Cae en el
extremo bajo si tus llamadas se parecen a las que probamos en
el spike. Cae en el extremo alto si descubrimos tipos de
llamada que no hemos visto, como llamadas en español o
cotizaciones de varias propiedades.
- Al final de la semana dos te digo hacia qué extremo vamos."
La última línea es la importante. Un rango no es una forma de evitar el compromiso. Es un compromiso de estrechar el rango con un calendario. A los clientes no les molesta la incertidumbre ni de cerca tanto como les molesta no saber cuándo va a terminar.
También mantengo los números ilustrativos aquí deliberadamente redondos. En la práctica, los números exactos dependen por completo del proyecto. Lo que se transfiere es la estructura: la parte segura, la parte incierta, qué la mueve, y cuándo sabrás más.
4. Escribe Qué Significa "Suficientemente Bueno"
Este es el paso que habría salvado mi promesa de tres semanas, y es el que ahora me niego a saltar.
Antes de que empiece cualquier construcción real — idealmente durante el spike — me siento con el cliente y definimos, por escrito, qué significa "suficientemente bueno." No en métricas que no le importan. En ejemplos que reconoce.
Para el agente de voz, esa conversación se ve así. Juntamos veinte o treinta llamadas reales, o recreaciones realistas de ellas. Para cada una, escribimos cuál es un buen resultado, y qué sería inaceptable. Luego acordamos una vara.
# Criterios de aceptación — agente de llamadas fuera de horario (ilustrativo)
suficientemente_bueno:
llamadas_de_agenda:
muestra: "las 30 llamadas que reunimos juntos"
meta: "agenda el servicio y la hora correctos en la mayoría"
fallo_aceptable: "toma un mensaje claro en vez de agendar"
nunca_permitido:
- "agenda la dirección equivocada"
- "confirma una hora que el calendario muestra ocupada"
- "da un precio"
todo_lo_demas:
comportamiento: "toma un mensaje con nombre, número y motivo, con cortesía"
nunca_permitido:
- "finge ser humano cuando se le pregunta directamente"
revision:
quien: "el dueño escucha una muestra de llamadas cada semana el primer mes"Dos cosas sobre este documento importan. Primero, las listas de nunca_permitido. Los clientes usualmente tienen mucho más claro lo que nunca debe pasar que cómo se ve el éxito, y esas líneas se convierten en barandas duras en el sistema. Segundo, está escrito en el lenguaje del cliente — direcciones, precios, citas — no en el mío.
Esto es un set de evaluación disfrazado. Escribí todo un post argumentando que el set de evaluación es la especificación, y el dimensionamiento es donde esa idea paga primero. Los ejemplos que reunimos son contra lo que el spike mide, de lo que depende el rango, y contra lo que probamos cada versión después. Sin ellos, "terminado" es un sentimiento. Con ellos, "terminado" es una conversación que realmente puedes terminar.
Sin una vara escrita, la vara se mueve
Si "suficientemente bueno" no está escrito antes de construir, se definirá después — por la única mala llamada que el cliente casualmente escuche. Los sistemas de IA siempre tienen algunas fallas. Acordar de antemano cuáles son aceptables y cuáles nunca se permiten es lo que evita que un proyecto muera por una sola anécdota.
El Mismo Método, a Escala de Plataforma
Supuse que estas lecciones eran sobre pequeños negocios. No lo son.
En TheGreyMatter.ai, trabajo en la plataforma detrás de una familia de aplicaciones verticales de IA, y las personas que preguntan "¿cuánto tiempo?" son líderes de producto y ejecutivos en vez de dueños de negocios. Son más agudos sobre software en general, pero están exactamente igual de expuestos a la misma trampa: una estimación segura sobre trabajo cuyo éxito depende de cómo se comporta un modelo con documentos y datos que nadie ha mirado de cerca todavía.
El método se transfiere casi sin cambios. El montón determinístico a escala de plataforma son los servicios compartidos: auth, manejo de archivos, notificaciones, conectores, RBAC, registros de auditoría. Esos los estimo con confianza, porque son ingeniería bien entendida. El montón incierto son cosas como qué tan bien un agente extrae estructura de un nuevo tipo de documento, o qué tan confiable se sostiene un análisis entre los datos de distintas empresas. Esos reciben spikes, rangos, y una vara escrita, igual que el agente de voz.
El vocabulario cambia. El memo recibe una plantilla más formal. Pero la forma — dos montones, un spike con una decisión, un rango con fecha para estrecharse, y lo suficientemente bueno por escrito — es la misma que aprendí en aquella llamada hace años.
Un Alcance de Una Página que Realmente Envío
Cuando lo junto todo, el documento que recibe un cliente no-técnico cabe en una página:
PROYECTO: manejo de llamadas fuera de horario
1. QUÉ ESTAMOS CONSTRUYENDO
Un párrafo, en tus palabras, no en las mías.
2. LA PARTE PREDECIBLE estimación: rango seguro
Integraciones, pantalla de admin, respaldo de mensajes, notificaciones.
3. LA PARTE INCIERTA estimación: después del spike
Qué tan bien maneja el agente tus llamadas reales.
4. SPIKE DE DESCUBRIMIENTO tiempo fijo, precio fijo
Prueba con tus llamadas reales. Termina en: seguir / acotar / parar.
5. QUÉ SIGNIFICA "SUFICIENTEMENTE BUENO"
Los ejemplos que acordamos. Lo que nunca debe pasar.
6. CUÁNDO SABRÁS MÁS
Fechas en que el rango se estrecha, y quién te avisa.
La sección seis es la que los clientes más mencionan cuando hablamos después. No es técnica en absoluto. Es una promesa sobre comunicación.
El Hilo
Si comprimo todo esto en una oración: separa lo que sabes de lo que estás adivinando, y cobra por averiguar antes de cobrar por construir.
Los clientes no-técnicos no están pidiendo certeza. Saben que el software se atrasa. Lo que piden es no llevarse sorpresas, y que se les diga la verdad con un calendario. Dos montones, un spike que termina en una decisión, un rango que se estrecha, y una definición escrita de suficientemente bueno son solo las herramientas que uso para cumplir esa promesa.
Todavía pienso en esa estimación de tres semanas. El teléfono sí contestó en la semana uno. Todo lo que vino después era la parte que no había sabido cómo explicar. Ahora la explico primero.
Si estás dimensionando un proyecto de IA para un cliente, un jefe, o una junta directiva que solo quiere saber cuánto tiempo y cuánto dinero, y quieres ayuda separando lo predecible de lo incierto, contáctame. Una estimación honesta es la función más barata que cualquier proyecto de IA va a entregar.
Frequently Asked Questions
Artículos Relacionados
El Demo Que Miente: Por Qué los Pilotos de IA se Estancan Antes de Producción
El demo de IA 90% impresionante es una trampa. El último 10% — casos extremos, integración, confianza, seguridad, gestión del cambio — es donde los pilotos mueren silenciosamente en el 'purgatorio de pilotos'. Aquí está cómo escapar.
El Eval Set Es la Especificación
Para una feature de LLM, tu eval set codifica qué significa 'correcto' con más precisión que cualquier doc de producto. Cómo construir uno a partir de fallas reales, mantenerlo adversarial, versionarlo como verdad de producto, y dejar que él — no las opiniones — guíe cada cambio de prompt y modelo.
Lo Que Construir Software para Pequeñas Empresas Me Enseñó Sobre Ingeniería
Historias de guerra construyendo software real para pequeñas empresas — sistemas de reservas, flujos de pago, y la humillante lección que un tipo de detallado automotriz me enseñó más sobre producto que toda mi carrera en CS.
No te pierdas nada
Artículos sobre IA, ingeniería y las lecciones que aprendo construyendo cosas. Sin spam, lo prometo.
Osvaldo Restrepo
Senior Full Stack AI & Software Engineer. Building production AI systems that solve real problems.