La bifurcación de la que depende todo
Un cambio que decide algo se planea antes de construirse. Un cambio que no decide nada se construye directo. Esa sola pregunta es la que parte el camino en Qué ruta toma tu cambio, así que vale la pena poder contestarla tú antes de escribir nada.
La planeación no escribe código. Lee, pregunta, revisa contra el código lo que concluyó, y deja un plan escrito.
Qué cuenta como decidir algo
Una decisión es una petición con dos rutas reales y ninguna respuesta obvia, donde la elección cambia el alcance, el costo o lo que una persona termina viendo. Un modal o una pantalla aparte. Extender el flujo que ya existe o agregar un segundo. Este servicio o aquel. Algo que sale de una forma para un registro y de otra para el siguiente, sin que nadie haya dicho qué regla aplica.
Cuál de dos cosas querías decir también es una decisión, pero solo cuando se comportan distinto — dos botones que mandan cosas diferentes, dos pantallas que muestran registros diferentes. Dos candidatos que solo se diferencian en dónde vive su código no son una decisión: no hay nada que elijas tú, y se resuelve leyendo.
Un dato que nadie escribió no es una decisión. Cómo se comporta hoy el flujo, qué muestra ya una pantalla existente, si algo se reutiliza en otro lado, qué dicen las convenciones del proyecto: eso tiene respuesta, y la respuesta se busca en lugar de ponértela enfrente. Una pregunta sobre un dato que leer podía resolver es una pregunta que no debió hacerse.
Dos cosas más que no son decisiones, por técnicas que suenen: dónde va el código y cómo se escribe. Un plan dice qué tiene que pasar y en qué estados, no qué archivo lo guarda. El resto lo deciden los estándares.
Una elección técnica es una decisión cuando de ella depende el riesgo, el costo o la prueba. Atender los avisos de un proveedor de pagos en el orden en que llegan o en el que se mandaron, dejar una tarea larga en la pantalla o pasarla a segundo plano: eso se pregunta mientras planeas, junto con lo demás, y la respuesta queda registrada con las otras. Una elección técnica de la que no depende nada sigue sin ponértela enfrente.
Qué te pregunta, y cómo
Primero se resuelve la ambigüedad que decide qué se va a investigar: qué quieres realmente y qué problema se está resolviendo. Esa se pregunta al inicio, porque todo lo que viene después depende de la respuesta.
Todo lo que se encuentra después se junta y se te pone de una sola vez. El alcance completo llega junto y se confirma una vez — el comportamiento, los estados que hay que distinguir, qué no debe cambiar, cómo se va a probar y la tecnología al nivel de "un modal" o "un formulario" y no de una lista de archivos. Corriges una parte y solo esa parte se vuelve a proponer; el resto no se recorre otra vez desde arriba.
Las decisiones reales te llegan como preguntas. Los datos faltantes no te llegan. Y cuando una revisión posterior levanta varias cosas a la vez, llegan en un solo mensaje en lugar de una por una.
Antes de que las preguntas te lleguen, el plan se revisa en busca de lo que deja sin decidir. Además de los estados, los permisos y lo que se entrega con el cambio, esa revisión mira cuatro cosas que tu petición rara vez nombra por sí sola: los otros lugares donde pasa lo mismo — cada camino por el que un registro llega al estado que cambias, cada pantalla que lo muestra, cada tipo de persona a la que aplica —; dos mecanismos que llegan a la misma persona o registro, y qué pasa cuando aplican los dos; lo que apunta a lo que se cambia o se quita; y el flujo que ya hace casi lo mismo, y si este debe comportarse como él. Solo cuentan los lugares que de verdad comparten el estado que tu cambio altera. Al final, lee cada punto del plan como lo leería quien lo construya, y lo que esa persona tendría que preguntarte se suma a las mismas preguntas. Cada pregunta llega con lo que depende de la respuesta y la respuesta que recomienda.
Las preguntas se quedan dentro de lo que pediste. Una pregunta sobre un área que nadie mencionó no es una aclaración — es una segunda petición que nunca hiciste —, así que algo no relacionado que se note en el camino se nombra en una línea al final, para retomarlo en su propio hilo, en vez de volverse pregunta o meterse callando en tu cambio.
Lo que apruebas se revisa antes de escribirse. Cada afirmación que hace el plan sobre cómo se comporta hoy el sistema se verifica contra el código que tendría que sostenerla: que un flujo que se promete reutilizar de verdad acepte tu caso y no solo exista, que un nombre propuesto para algo nuevo no esté ya usado en esa pantalla para otra cosa, que un comportamiento compartido que se va a cambiar se haya rastreado hasta todos los que lo consumen. Lo que esa revisión encuentra o se resuelve en silencio o te llega como hallazgo primero y pregunta después.
Lo que ves antes de que se construya
Cuando tu cambio agrega o modifica algo que una persona ve, el alcance te llega con un dibujo: la pantalla como se ve hoy y como se vería. La de hoy se dibuja a partir de la pantalla real, con sus datos reales, y se compara con ella antes de enseñártela — una pantalla sin nada se dibuja vacía y lo dice. La de mañana se dibuja con los componentes y los estilos de tu propio producto. Cuando el diseño de tu producto ya decide cómo debe verse, recibes una propuesta; cuando el diseño es nuevo o tiene más de un camino, recibes varias para elegir. Eliges una o pides cambios, y aprobar el alcance aprueba ese diseño.
El dibujo aparece en la conversación cuando tu asistente puede mostrarlo ahí, y si no, como una página guardada fuera de tu repositorio cuya ubicación se te da. Solo se guarda el aprobado, junto al plan y con datos de ejemplo, nunca los datos reales de la pantalla de hoy. Es hacia donde apunta la construcción y contra lo que la revisión en el navegador compara la pantalla terminada. Un cambio tan chico que va por la ruta directa, descrita más abajo, no se dibuja.
Qué deja escrito
Un plan, guardado en la carpeta analysis/ de tu proyecto en el toolkit para que sobreviva a la conversación que lo produjo — numerado por el servidor, con la rama en la que lo planeaste y listado en el índice de la carpeta. Lo lees en la sección Proyectos; a tu repositorio no se le agrega nada y no se hace ningún commit por él. Ve Tus proyectos y sus documentos. Dice cuál es el problema y dónde se ve, qué estableció la investigación, qué tiene que pasar y en qué estados, por qué vale la pena, qué no debe cambiar, las preguntas que se hicieron con las respuestas que recibieron, y cómo se prueba el resultado. Salvo que el cambio haya ido por la ruta directa, descrita más abajo, termina con un plan técnico: por dónde pasa el cambio, qué ya existe y sirve, qué choca, dónde el código se aparta de los estándares y los riesgos a cuidar — el orden en que llegan los avisos de un proveedor, los datos que ya existen, cómo se acomoda una línea en una pantalla angosta. Nombra módulos y archivos para orientarse, nunca el código que hay que escribir.
Debajo lleva una lista — un renglón por cada cosa que el plan prometió — que se mueve de pendiente a hecho o bloqueado conforme el trabajo de verdad pasa. Quien retome la tarea después lee eso en vez de adivinar hasta dónde llegó.
Antes de guardarlo se te pregunta si lo dejas esperando o lo marcas listo para correr. Listo lo mete en la cola que el toolkit va vaciando; esperando lo deja como un documento que le puedes entregar al paso de construcción cuando quieras.
Una decisión que tu proyecto toma una y otra vez se ofrece para su visión. Cuando una decisión que confirmas ya la resolvieron igual tres planes anteriores, y es una decisión de producto — a quién sirve el producto, cómo habla, qué tan consistente tiene que ser, qué no hará nunca, cómo se nombran las cosas, qué va primero —, después del plan llega una pregunta: ¿esa respuesta va en la visión del proyecto? Nombra la pregunta, la respuesta que se repite y los planes anteriores que la dieron. Si dices que sí, te dice en qué parte de la visión va y qué escribir ahí, para que lo registres con /vision; la planeación nunca escribe en la visión. Una vez que la respuesta está en la visión, los planes siguientes la leen y dejan de preguntar. Si dices que no, esa vez se descarta.
El paso de construcción lo sigue en lugar de improvisar. Las decisiones registradas en el plan se tratan como resueltas y no se reabren a mitad del camino, que es todo el punto de tomarlas una vez. El plan técnico es la excepción, a propósito: es una guía, que se sigue mientras el código coincide con ella, y donde el código resulta distinto la construcción decide, anota en el plan lo que encontró y sigue, sin detenerse a preguntarte, salvo que la corrección cambie lo que el plan pide. Lo único que regresa un plan es que el código contradiga algo de lo que el plan partía: ahí la corrida se detiene y lo devuelve acá, porque todo lo que se decidió encima de esa afirmación se decidió a partir de algo falso, y ninguna respuesta sola repara eso.
Cuándo no vale la pena
Una petición que no decide nada no necesita nada de esto. El texto de una pantalla, un espaciado, un color, el orden en que van dos elementos, un componente que ya existe puesto donde estaba otro: ya sabes qué quieres y no hay nada que elegir. Planearlo te compraría una conversación y un documento más, y no cambiaría el resultado en nada.
La ruta directa igual revisa que lo que nombraste de verdad tenga lo que dijiste, e igual busca en dónde más se lee antes de tocarlo. Lo que se salta es la investigación, nunca la prueba: el analizador sigue corriendo, y todo lo que se ve se sigue abriendo en un navegador.
Ante la duda, planea. Mandar un cambio chico por la planeación cuesta una conversación que nadie necesitaba. Mandar uno de verdad directo a construirse publica una decisión que nadie miró.
Sigue por aquí
- Qué ruta toma tu cambio — los cuatro tipos de cambio, y dónde cae este.
- Cómo pido un cambio — el camino completo, con el diagrama.
- Qué hace cada comando — el comando de planeación junto a los otros quince.