Beakman, Ford y el arte de dividir para entregar

Cuando era niño, no me perdía El mundo de Beakman en TV Cultura. Era ruidoso, era raro y le enseñó a toda una generación de niños brasileños cómo funcionan de verdad las cosas. Un episodio se me quedó para toda la vida: el de Henry Ford y la línea de montaje. La idea de que podías agarrar una tarea enorme e intimidante, armar un auto entero, y convertirla en una secuencia de pasos pequeños y repetibles que cualquier persona podía hacer bien. No necesitabas un genio capaz de armar un auto solo. Necesitabas un proceso que partiera el auto en pedazos.

Décadas después, sigo pensando así en cómo entregar software. El instinto de la mayoría de los equipos, frente a algo grande, es mapear todo primero. Cada requisito, cada caso borde, cada endpoint, en papel, antes de una sola línea de código. Parece responsable. Casi nunca lo es. Así es como los proyectos se traban.

Cuarenta endpoints y un squad trabado en la especificación

Un ejemplo al que siempre vuelvo: un squad estaba atrasado en una integración con unos cuarenta endpoints. El equipo estaba paralizado, tratando de especificar los cuarenta antes de construir nada. La especificación solo crecía, el plazo solo se movía, y nada funcionaba de verdad.

Entonces hice una pregunta distinta: ¿y si, en vez de mapear los cuarenta endpoints, hacemos el sistema de punta a punta con uno solo? Un endpoint, pero conectado por el sistema entero, de la petición a la respuesta, autenticación, manejo de errores, logs, todo. De repente el equipo tenía algo real andando. Se podía validar el enfoque en la práctica, y no en papel. Y, igual de importante, llegó la sensación de completitud, la prueba de que el camino funcionaba. Después de eso, los endpoints restantes dejaron de ser un muro y se volvieron un checklist. Cada uno era solo un tramo más de un camino que ya habían pavimentado.

El mismo truco, en migraciones de CRM

Hago lo mismo en migraciones de datos. La tentación es siempre mapear cada campo, cada relación, cada excepción antes de mover un solo registro. En vez de eso, arranco con un ejemplo simple y representativo y lo llevo hasta el final. Ese único registro te enseña la forma real de la conexión, las mañas de la autenticación, los límites de tasa, los campos que no coinciden, mucho más rápido que cualquier documento de mapeo. Y le da al cliente algo para ver y comentar en días, no en meses. Feedback temprano le gana a un plan perfecto entregado tarde.

No cambió con la IA. Se volvió más importante.

Veo gente cometiendo el mismo viejo error con una herramienta nueva y brillante: tratar de construir una solución de IA compleja en un solo tiro heroico. Prompt, agente, herramientas, evaluación, todo de una vez. Como ya dijo Matt Pocock, los procesos de ingeniería de software siguen valiendo, incluso con IA en el medio. El modelo cambia cómo escribes el código. No deroga la disciplina de entregar una rebanada fina, validarla e iterar.

Simplicidad, iteración incremental y validación práctica le ganan al exceso de planificación, siempre.

Ford no hizo el auto más simple. Hizo el proceso de construirlo más simple, una estación a la vez. Esa es toda la lección, y un programa de ciencia para niños me la enseñó antes de que yo escribiera mi primera línea de código.