Una idea de producto necesita convertirse en una especificación clara y consistente antes de poder convertirse en software funcional — normalmente eso significa que alguien busca entre documentos y chats antiguos, redacta a mano un documento de diseño técnico, y espera que nada contradiga una decisión tomada hace tres meses que nadie dejó por escrito. Solo una vez que esa especificación está lista, un ingeniero la retoma, escribe el código, escribe pruebas, abre un pull request y espera a un revisor que atiende su propia cola. La mayor parte del trabajo real ocurre antes de escribir una sola línea de código, y la mayor parte es manual.
Así es como se ve eso al pasar por el flujo gobernado de ContextTogether.
Varias entradas, al mismo tiempo
todo converge a la vez
Construyendo la especificación
Creando el Código
Fuentes. La llamada inicial, una grabación de pantalla, un documento de diseño antiguo, un montón de capturas de pantalla — cualquier material que ya exista se carga como una Fuente, ya sea archivo, audio o video. Se extrae en conocimiento canónico de la misma forma que cualquier otro documento, para que una decisión tomada en voz alta durante una reunión sea tan recuperable como una que quedó por escrito.
Investigación. La idea se explora en el chat, incorporando decisiones previas relevantes, especificaciones existentes y contexto de código relacionado desde la Memoria Organizacional — incluyendo lo que acaba de ingresar a través de Fuentes — para que la especificación parta de lo que realmente está en archivo, no del recuerdo de alguien sobre una reunión.
Redacción desde una plantilla. Se produce un documento de diseño técnico a partir de la plantilla de desarrollo de software — la misma estructura que sigue cada especificación en el sistema, en lugar de partir de una página en blanco.
Revisión de consistencia. Antes de que alguien la revise, el borrador se verifica contra sí mismo y contra todo lo que ya está en archivo — los vacíos y las contradicciones salen a la luz automáticamente, en lugar de esperar a que se detecten tres pasos después.
Aprobación humana de la especificación. Quien es dueño de la decisión resuelve cualquier pregunta pendiente y da el visto bueno — el primero de dos puntos donde el criterio de una persona realmente importa.
Creación del código. El código se escribe a partir de la especificación aprobada en un solo paso — sin que un ingeniero empiece desde un archivo en blanco, sin armado manual previo.
PR automático. El código pasa por pruebas y verificaciones automáticas, y se abre un pull request por sí solo — nada llega a revisión solo por la confianza de un modelo, y nadie tiene que abrirlo manualmente.
Aprobación humana del código. Un revisor da el visto bueno antes de que algo se integre — el segundo y último punto donde el criterio de una persona es lo que importa.
Recuperación. La idea, la especificación, cada paso del camino, los resultados de las pruebas, ambas aprobaciones — todo queda recuperable con comprobantes, para que dentro de seis meses "por qué lo construimos así" tenga una respuesta que se remonte hasta donde realmente empezó.
La atención del ingeniero va a las dos decisiones de criterio que importan — aprobar la especificación, aprobar el código — no a las partes intermedias que no necesitan a una persona.