De estimar "a ojo" a una herramienta calibrada
Cómo construí una app que estima el esfuerzo de DTP a partir de los archivos fuente, y la calibré con trabajos reales hasta que los números coincidieran con la realidad.
Este caso describe metodología y procesos de trabajo reales, sin exponer documentos, clientes ni datos concretos de ningún proyecto.
01
Contexto
Todo trabajo de DTP empieza con una pregunta: ¿cuántas horas va a llevar? La respuesta define presupuestos, planificación y plazos, pero se basaba en guías generales y en la experiencia. El mismo documento podía estimarse de forma muy distinta según quién lo mirara, y nadie comprobaba después qué tan cerca había estado la estimación.
02
Mi rol y objetivo
Me propuse construir una herramienta que leyera el archivo fuente y diera una estimación consistente y explicable, usando Claude como asistente de desarrollo. Mi rol fue el de especialista del dominio: decidir qué factores generan trabajo de DTP y cuánto pesa cada uno.
03
Proceso
Definir qué genera esfuerzo. Páginas, tablas, imágenes con texto, gráficos que hay que rehacer, campos de formulario, fuentes, el formato del archivo y el tipo de servicio. Separé el trabajo de pretraducción (preparar el archivo para la herramienta CAT) del de postraducción (maquetar el archivo traducido).
Construir el analizador. La app lee archivos PDF, Word, PowerPoint e InDesign (IDML), detecta esos elementos automáticamente y señala lo que necesita revisión humana, como imágenes que pueden contener texto o fuentes que no están instaladas.
Calibrar con trabajos reales. Después de cada trabajo real, comparé la estimación con las horas que de verdad llevó y ajusté las reglas. Cada cambio tuvo su número de versión y una nota explicando por qué. Por ejemplo, los íconos y logos pequeños dejaron de contar como imágenes a preparar, y los gráficos a rehacer pasaron de 15 a 20 minutos después de que un informe real mostrara la diferencia.
Reglas propias por servicio. La accesibilidad y los formularios PDF interactivos no se comportan como la maquetación estándar, así que tienen sus propias reglas (en los formularios, el esfuerzo depende de la cantidad de campos, no del cliente).
04
Decisiones clave
- Explicable antes que ingenioso. Cada hora de la estimación se puede rastrear hasta una regla y un elemento detectado.
- Deciden los datos reales. Una regla solo cambia cuando un trabajo real demuestra que estaba mal.
- Registrar los errores, no solo los aciertos. Los documentos largos de Word con muchas tablas de maquetación seguían subestimándose, y eso quedó como pregunta abierta para resolver con más datos, no como algo para esconder.
05
Solución final
Una app de estimación que analiza los archivos fuente, desglosa las horas de pre y postraducción, suma un margen de seguridad y exporta la estimación en un PDF limpio. Las reglas calibradas también se incorporaron a las guías de estimación del equipo.
06
Resultados y aprendizaje
En los tipos de trabajo ya calibrados, las estimaciones quedan cerca de las horas reales: una presentación de 28 diapositivas estimada en unas 2 h para un presupuesto de 2 h, un informe de 33 páginas en unas 4,8 h para unas 5 h reales.
El mayor aprendizaje: una buena estimación no es una fórmula que se escribe una vez, es un ciclo. Estimar, medir, ajustar y dejar por escrito el porqué.