Plan Review Dual Mode: Pensamiento de CEO + Arquitectura de Ingeniero — Por Qué Usarlos Separadamente

Al diseñar funcionalidades, la mayoría de los ingenieros se saltan dos de las preguntas más importantes:

"¿Vale la pena construir esta funcionalidad?" — La mayoría asume que la respuesta es "obviamente sí, el requisito ya está aquí."
"¿Tiene esta arquitectura modos de fallo ocultos?" — La mayoría asume que si funciona, pasó.

El Plan Review de Gstack maneja una pregunta cada uno.

Dos Skills, Dos Frecuencias Cognitivas Completamente Diferentes

/plan-ceo-review y /plan-eng-review suenan ambos como "revisión de plan," pero las preguntas que hacen son completamente diferentes —

/plan-ceo-review es la perspectiva de Fundador / CEO:

¿Qué problema estás resolviendo realmente?
¿Qué hace el usuario ahora mismo? ¿Cuánto mejor es esta funcionalidad que lo que ya están haciendo?
¿Hay una solución más sencilla que entregue 10x el impacto?
¿Hará esta funcionalidad que la experiencia central sea más compleja?

/plan-eng-review es la perspectiva de Engineering Manager / Tech Lead:

¿Cuál es el flujo de datos? ¿Dónde se gestiona el estado?
¿Dónde están los límites asíncronos? ¿Cuáles son las posibles condiciones de carrera?
¿Cuáles son los casos extremos y los modos de fallo?
¿Cuánta cobertura de tests necesitamos? ¿Hay un diagrama?

Uno da un paso atrás y pregunta "¿vale la pena?"; el otro avanza y pregunta "¿cómo lo hacemos bien?" Mezclarlos hace que ninguno funcione bien.

Qué Te Pregunta Realmente `/plan-ceo-review`

Digamos que le dices a Gstack: "Quiero añadir una funcionalidad de comparación de productos a una plataforma de e-commerce, permitiendo a los usuarios comparar las especificaciones de tres productos simultáneamente."

Con un asistente de IA general, probablemente obtendrías directamente un diseño de tabla comparativa.

Con /plan-ceo-review, primero pregunta:

¿Cómo comparan actualmente los productos tus usuarios? ¿Capturas de pantalla a Notas? ¿Abriendo múltiples pestañas manualmente?
¿Qué tipos de usuarios necesitan más la funcionalidad de comparación? ¿En qué etapa del proceso de compra?
¿Es posible que el problema real sea "la información de especificaciones del producto no es suficientemente clara" en lugar de una funcionalidad de comparación que falta?
Si se añade "comparación de productos" pero las tasas de conversión no mejoran, ¿cómo evaluarías esta funcionalidad?

Tu PM puede haber hecho algunas de estas preguntas. Puede que no. Pero Gstack las hará — cada vez, sin falta. No te dejará construir la solución correcta al problema incorrecto.

Qué Genera Realmente `/plan-eng-review`

Misma funcionalidad, cambia a /plan-eng-review, y el formato de output de Gstack cambia significativamente:

Diagrama de arquitectura (diagrama de secuencia o de componentes) — visualiza tu diseño, forzando que las suposiciones ocultas salgan a la superficie
Análisis de límites asíncronos — ¿qué partes de esta funcionalidad pueden ser asíncronas? ¿cuáles deben ser síncronas?
Lista de modos de fallo — si la base de datos es lenta, si una API falla, si el usuario tiene dos pestañas abiertas simultáneamente — ¿qué pasa?
Matriz de tests — qué partes necesitan tests unitarios, cuáles tests de integración, cuáles tests E2E

No necesariamente tienes que recorrer todo esto cada vez, pero tener una lista que diga "estas preguntas vale la pena considerar" ahorra mucho tiempo comparado con empezar desde cero.

Cómo Usar los Dos Skills Juntos

Flujo estándar: CEO primero, luego Ingeniero.

El orden es lógico — si /plan-ceo-review cambia la definición o el alcance de la funcionalidad, /plan-eng-review necesita volver a ejecutarse. Al revés significa que podrías pasar tiempo significativo en diseño de arquitectura para una funcionalidad que no vale la pena construir.

Confirma "vale la pena construir" primero, luego confirma "cómo construirlo correctamente."

Para funcionalidades pequeñas: ejecuta solo uno de ellos.

No toda funcionalidad necesita la presión de prueba del pensamiento de CEO — cambiar el color de un botón no necesita "¿vale la pena hacer esto?"
No toda decisión necesita una inmersión profunda del Engineering Manager — la arquitectura para añadir un campo de configuración normalmente es obvia.

El criterio es simple: ¿cuánto dolor causaría si tomamos mal esta decisión? Cuanto más doloroso, más vale la pena ejecutar Plan Review.

Un Patrón de Uso Incorrecto Común

El uso incorrecto más común del Plan Review de Gstack es: ejecutarlo después de que todo el código ya esté escrito.

En ese punto, si el modo CEO dice "la definición de esta funcionalidad debería ser diferente," ¿qué haces? ¿Descartarlo y reiniciar, o ignorar la retroalimentación? Ninguno es bueno.

El momento de Plan Review es antes de que la decisión esté bloqueada y antes de escribir cualquier código — es literalmente "revisión durante la fase de planificación." Trátalo como pensamiento pre-implementación obligatorio, no como una lista de verificación post-hoc.

Tip: Pega Tu Especificación o User Story Directamente

No necesitas describir la funcionalidad en vivo en la conversación con Gstack. Solo pega tu documento de requisitos, user story o descripción de especificación de diseño, luego activa el comando:

/plan-ceo-review

[Tu documento de requisitos o user story]

Comenzará desde tus materiales y los analizará a través del framework de pensamiento CEO — funciona más rápido, y es menos probable que pierdas detalles.

Plan Review hecho, siguiente paso: después de que el código está escrito, cómo hacer una revisión de nivel de producción y cómo entregar con un solo comando.

→ Code Review y Ship: De la Revisión Paranoica a la Entrega con Un Solo Comando

Volver a la Visión General de la Serie

Esta es la tercera parada de la serie Gstack, enfocada en el dual mode de Plan Review. Para el camino de lectura completo y otros temas de artículos, vuelve al Curso Gstack para Principiantes.