Planificación de Implementación vs. Desarrollo: Un Modelo Mental al Que Siempre Vuelvo

Esto no es un estudio. No es un benchmark. Y definitivamente no soy yo intentando fingir que un gráfico puede explicar cada decisión de ingeniería.

Es solo un modelo mental al que vuelvo con frecuencia después de trabajar en funcionalidades, refactorizaciones, integraciones, migraciones y cambios más grandes en los que el verdadero desafío no era solamente escribir el código, sino entender qué estaba a punto de tocar ese código.

La idea se volvió más clara para mí después de un cambio en la forma en que nuestro equipo empezó a organizar parte del trabajo. En el proyecto en el que trabajo, comenzamos a crear tareas específicas para planes de implementación antes de iniciar las tareas reales de desarrollo. En algunos casos, la tarea de desarrollo solo se creaba, refinaba o dividía correctamente después de terminar la tarea de planificación de implementación.

Al principio, esa separación me pareció un poco inusual. Una parte de mi cerebro quería saltar directo al código, porque ahí es donde las cosas se sienten concretas. Pero después de ver este proceso unas cuantas veces, empecé a entender el valor de tratar el plan como una pieza de trabajo propia. No como burocracia. No como ceremonia. Más bien como una pausa para entender el terreno antes de comprometerse con una ruta.

Cuando digo Planificación de Implementación, me refiero al trabajo que ocurre antes de la construcción práctica: entender el impacto, revisar los límites del sistema, pensar en la estructura, leer código existente, identificar patrones, listar casos de prueba y exponer los pasos manuales aburridos, pero importantes, que pueden sorprender al equipo más tarde.

Cuando digo Desarrollo, me refiero a la parte práctica: escribir código, ajustar pruebas, revisar, integrar, depurar, desplegar y lidiar con las cosas que solo se vuelven visibles cuando el cambio empieza a existir.

La forma en que imagino esta relación se parece a esto:

Los números no son el punto. Son unidades relativas e ilustrativas. La forma de la curva es la parte útil.

La idea simple

Cuanta más planificación de implementación útil hacemos, menos esfuerzo innecesario de desarrollo solemos crear después.

No menos esfuerzo de desarrollo en el sentido de que programar se vuelva mágicamente fácil. No se vuelve.

Pero sí menos esfuerzo desperdiciado en confusión evitable.

Menos retrabajo causado por una regla de negocio escondida. Menos idas y vueltas porque la propiedad de un flujo no estaba clara. Menos descubrimiento tardío de un detalle de integración. Menos "ah, esto también afecta a aquel otro servicio". Menos adivinar cuando ya estamos dentro de la implementación.

Ahí es donde la planificación ayuda mucho.

Un buen plan de implementación no es un contrato con el futuro. Se parece más a un mapa. No elimina todas las sorpresas del camino, pero ayuda al equipo a evitar caminar en círculos.

Por qué una tarea separada de planificación puede ayudar

Algo que me gusta de tener una tarea dedicada de planificación de implementación es que le da al equipo permiso para desacelerar por la razón correcta.

Sin ese paso explícito, la planificación suele ocurrir en fragmentos: un comentario rápido aquí, un hilo de Slack allá, una pequeña investigación durante el desarrollo y algunos detalles importantes descubiertos solo después de que el trabajo ya empezó. A veces eso está bien. Pero para cambios más grandes, esos descubrimientos dispersos pueden volverse caros de forma silenciosa.

Una tarea separada de planificación crea un pequeño contenedor para las incertidumbres. Le da al ingeniero tiempo para leer el código, hacer preguntas, comprobar supuestos y convertir una tarea vaga de desarrollo en algo sobre lo que el equipo realmente puede razonar.

A veces el resultado no es un documento enorme. Puede ser un plan corto, una lista de áreas afectadas, una secuencia propuesta de implementación o algunos riesgos que necesitan alineación. El valor no está en producir un plan bonito. El valor está en hacer que la siguiente tarea sea menos ciega.

En ese sentido, la tarea de desarrollo que viene después del plan suele quedar mejor formada. Tiene límites más claros, mejores expectativas de pruebas, menos pasos manuales ocultos y una comprensión más honesta de lo que puede salir mal.

Qué intenta descubrir la planificación

Para mí, la parte más valiosa de la planificación no es crear un documento largo. Es obligar a que aparezcan las preguntas correctas antes de que el costo de cambiar de dirección sea demasiado alto.

Una funcionalidad o un cambio técnico grande normalmente carga más contexto del que muestra el ticket. Hay límites de sistema, reglas de negocio, decisiones heredadas, patrones de código, compromisos históricos, detalles de rollout y, a veces, algunas áreas del tipo "por favor no toques esto a menos que sepas por qué".

La planificación de implementación es el momento en que intento acercar esos detalles a la superficie.

Cosas como:

• ¿Qué sistemas, módulos, jobs, eventos o APIs se verán afectados?
• ¿Cuál es la estructura propuesta de implementación?
• ¿Qué patrones de código existentes deberían guiar la solución?
• ¿Qué patrones probablemente deberían evitarse?
• ¿Qué reglas de negocio o comportamientos heredados pueden cambiar la dirección del trabajo?
• ¿Qué casos de prueba deben cubrirse?
• ¿Qué casos límite son fáciles de pasar por alto?
• ¿Qué pasos manuales están involucrados?
• ¿Hay scripts, migraciones, backfills, feature flags, cambios de configuración o pasos de rollout?
• ¿Qué debe verificarse después del release?
• ¿Qué puede automatizarse y qué todavía necesita verificación humana?

Cuanto más complejo es el sistema, más importan estos detalles.

En una base de código limpia y aislada, tal vez el plan pueda ser muy pequeño. Pero en un producto real con historia, dependencias, lógica heredada, reglas específicas del negocio y decisiones técnicas anteriores, la planificación de implementación deja de ser tanto sobre escribir un plan y pasa a ser más sobre reducir la cantidad de sorpresas caras.

Por qué la primera parte de la curva cae rápido

Al principio, la planificación suele tener un retorno alto.

Incluso una conversación corta, una pequeña nota de diseño o una exploración rápida del código puede eliminar una cantidad sorprendente de incertidumbre.

A veces una hora de planificación ahorra muchas horas de desarrollo porque evita que el equipo empiece en la dirección equivocada.

Esa es la parte empinada de la curva.

El equipo descubre que un flujo ya existe. O que un campo tiene un significado oculto. O que una dependencia se comporta de forma diferente en producción. O que un cambio parecido causó problemas antes. O que la implementación puede ser mucho más simple si sigue un patrón existente.

Ese es el tipo de planificación que se siente valiosa de inmediato. Convierte "empecemos a programar y veamos qué pasa" en "conocemos el camino principal, los riesgos principales y las primeras decisiones".

Por qué la curva eventualmente se aplana

Pero la planificación tiene límites.

En algún punto, más planificación todavía ayuda, pero la ganancia se vuelve menor. Esa es la parte donde la curva se aplana.

Hay algunas razones para eso.

Primero, el desarrollo nunca puede llegar a cero. Incluso con un gran plan, alguien todavía tiene que escribir el código, probarlo, revisarlo, integrarlo, desplegarlo y corregir las cosas que solo aparecen cuando se ejercita el sistema.

Segundo, cierta incertidumbre no puede eliminarse de antemano. Algunas preguntas solo se vuelven reales cuando el código se encuentra con el sistema existente. Puedes leer, inspeccionar y discutir mucho, pero a veces la respuesta honesta es: necesitamos construir una parte pequeña y validarla.

Tercero, demasiada planificación puede empezar a darle al equipo una falsa sensación de certeza. El documento se hace más grande, pero el riesgo no necesariamente disminuye al mismo ritmo.

Por eso no veo la planificación como algo que deba maximizarse.

La veo como algo que debe calibrarse.

Una pequeña ecuación para el modelo mental

Me gusta esta ecuación como una forma simple de representar la idea:

Desarrollo(P) = D_min + (D0 - D_min) * e^(-kP)

Donde:

• P es el esfuerzo de planificación de implementación
• Desarrollo(P) es el esfuerzo esperado de desarrollo
• D0 es el esfuerzo de desarrollo cuando la planificación está cerca de cero
• D_min es el mínimo práctico de esfuerzo de desarrollo
• k es qué tanto la planificación reduce incertidumbre y retrabajo

Esta no es una fórmula que usaría para estimar un sprint real.

No pondría estos números en una hoja de cálculo fingiendo que son precisos.

La ecuación solo es útil porque captura la forma de la intuición: la planificación reduce el esfuerzo de desarrollo rápidamente al principio, y luego el retorno se vuelve menor con el tiempo.

Las dos trampas

La primera trampa es planificar de menos.

Esto ocurre cuando el equipo empieza a desarrollar antes de entender lo suficiente sobre el impacto, las dependencias, la estructura, las pruebas, el rollout y las restricciones específicas del sistema. La planificación que faltaba no desaparece. Se mueve a la fase de desarrollo, donde se convierte en interrupciones, retrabajo y descubrimientos de último momento.

La segunda trampa es planificar de más.

Esto ocurre cuando el equipo intenta responder todas las preguntas posibles antes de construir cualquier cosa. El plan se hace más largo, pero el equipo no siempre se vuelve proporcionalmente más seguro. A veces el siguiente paso útil de aprendizaje no es otra reunión ni otro diagrama. Es un pequeño spike de implementación, una prueba o validar un supuesto en el código.

Ambas trampas son comprensibles.

Planificar de menos suele venir de la presión por moverse rápido. Planificar de más suele venir del deseo de evitar errores.

He hecho ambas cosas. La mayoría de los equipos probablemente también.

Lo difícil es encontrar el punto medio.

Cómo se siente "suficiente planificación"

Para mí, suficiente planificación suele sentirse así:

El equipo entiende el camino principal. Las áreas de riesgo están visibles. La estructura de implementación no es un misterio. Los patrones de código son conocidos. La estrategia de pruebas está lo suficientemente clara. Los pasos manuales están listados. El rollout no depende de la esperanza. Las incertidumbres que quedan son aceptables e intencionales.

Esa última parte importa: aceptables e intencionales.

Un buen plan no elimina toda incertidumbre. Hace que las incertidumbres restantes sean lo suficientemente explícitas para que el equipo pueda decidir llevarlas al desarrollo.

Esa sensación es muy distinta a descubrirlas por accidente más tarde.

Mi conclusión actual

La planificación de implementación es una forma de mover la incertidumbre hacia antes, cuando normalmente es más barato discutir, cuestionar y ajustar.

Ayuda a que el desarrollo sea más enfocado, pero tiene retornos decrecientes. El objetivo no es crear el plan más completo posible. El objetivo es crear suficiente claridad para construir con confianza.

Para mí, el punto ideal está en algún lugar entre caos y teatro.

No "programemos y resolvamos en el camino".

No "planifiquemos hasta que nada se sienta incierto".

Más bien:

"Entendamos lo suficiente para tomar las siguientes decisiones con responsabilidad, y después dejemos que la implementación nos enseñe el resto."

Ese es el equilibrio en el que todavía intento mejorar.