Christian F. Rojas
ENES
Todos los casos

Caso 02

Una metodología de planes de cambio documentales, en producción en tres releases

Los pedidos de cambio nos llegaban como correos, historias de Jira y comparaciones entre versiones de miles de líneas. Los convertí en una metodología versionada y trazable, y la apliqué a tres releases de producto.

115
cambios trazados en 3 releases (43 + 56 + 16)
54
preguntas para expertos
27 · 14
historias de Jira trazadas y comentarios de revisores incorporados
Diagrama del sistema: trazabilidad y escalamiento en la metodología de planes de cambiosCada elemento se traza en ambos sentidos a lo largo de la cadena cita textual, REQ, CH, P. Cuando las fuentes se contradicen, la contradicción va a un registro de contradicciones, resaltado, y se escala; no la resuelvo por criterio propio. La metodología está en producción: 3 releases, 115 cambios trazados.cita textualREQCHPregistro de contradiccionesse escalano lo resuelvo yotrazable en ambos sentidoslas fuentes discrepanen producción · 3 releases · 115 cambios trazadosDiagrama del sistema: trazabilidad y escalamiento en la metodología de planes de cambiosCada elemento se traza en ambos sentidos a lo largo de la cadena cita textual, REQ, CH, P. Cuando las fuentes se contradicen, la contradicción va a un registro de contradicciones, resaltado, y se escala; no la resuelvo por criterio propio. La metodología está en producción: 3 releases, 115 cambios trazados.cita textualREQCHPregistro de contradiccionesse escalano lo resuelvo yotrazable en ambos sentidoslas fuentes discrepan3 releases · 115 cambios
Fig. 02 · Diagrama del sistema

Mis decisiones 04

  • Fijar las reglas duras de la metodología, entre ellas "nada se descarta en silencio".
  • Quitar las estimaciones de esfuerzo de los entregables, porque no podía justificar cómo se midieron.
  • Separar los entregables por audiencia: un one-pager de aprobación para el PM y una guía de ejecución para el writer.
  • Adoptar GitHub como fuente de verdad versionada y el dashboard compartido como capa visual viva.

Ejecución asistida 02

  • Claude Code indexó los manuales con subagentes en paralelo y redactó cada plan bajo las reglas de la metodología.
  • Claude Code construyó el one-pager HTML que se guarda solo y generó las guías de ejecución en Word.

Contexto

Respondo por la documentación técnica de una línea de productos de prevención de fraude en ciberseguridad empresarial. Los pedidos de cambio llegaban sin estructura: correos, historias de Jira y comparaciones entre versiones de manuales de miles de líneas. Cada release obligaba a rehacer el mismo razonamiento desde cero.

Qué decidí

Convertí el trabajo en una metodología reutilizable, y cada corrección que hice al usarla se volvió una regla. Algunas de esas correcciones:

  • Sin estimaciones de esfuerzo. Las quité de los entregables. Mi razón en ese momento: no sabía cómo se habían medido y no tenía cómo justificarlas.
  • Quien aprueba solo ve contenido. El one-pager muestra los cambios de contenido. Los cambios editoriales y el manejo de archivos van solo a la guía del writer.
  • El borrador de Ingeniería es insumo, no trabajo terminado. El contenido que Ingeniería ya había escrito en los manuales nuevos se procesa como cualquier otra fuente. Eso reclasificó 5 cambios.
  • Nada se mueve una vez publicado. Un cambio nunca se borra y un ID publicado nunca cambia de lugar. El estado guardado desde el dashboard vivo prevalece sobre el plan.

Cuando varias personas necesitaron editar el dashboard de seguimiento, elegí un modelo híbrido: GitHub como fuente de verdad versionada y el dashboard compartido como capa visual viva.

Cómo funciona

  • Insumos y reglas. Cuatro insumos (la versión base, la versión destino, el pedido pegado sin editar y el contexto) y diez reglas duras. Entre ellas: no inventar contenido técnico, citar textualmente, anclar cada cambio a archivo, sección y línea, y separar los cambios pedidos de los derivados.
  • Seis fases. Validación, indexación con subagentes en paralelo, estructuración del pedido en requisitos y cambios atómicos, impacto y propagación, brechas y riesgos, y entregables.
  • Una cadena de trazabilidad completa. Cita → requisito (REQ) → cambio (CH) → pregunta abierta (P), con identificadores propios para las contradicciones y los comentarios de revisores.
  • Una taxonomía de tres ejes. Tipo (añadido, modificado, eliminado), clase (contenido, editorial) y estado (ejecutable, pendiente de validación técnica, bloqueado). Un cambio bloqueado siempre dice qué falta y quién debe darlo.
  • Un chequeo de cierre de diez puntos. Identificadores contiguos, conteos calculados y nunca escritos a mano, tildes y contraste WCAG.
  • Dos entregables para dos audiencias. Un one-pager HTML de aprobación para el PM, con un dashboard de seguimiento que se guarda solo y admite comentarios; y una guía de ejecución en Word para el writer, con una tarjeta por cambio, preguntas a expertos y una lista de control de calidad.

La regla más citable: “nada se descarta en silencio”.

Qué produjo

La versión 2 de la metodología salió del uso real en dos productos. Se aplicó a tres releases:

  • Producto A, vN → vN+1. 6 manuales comparados, 43 cambios, 27 preguntas a expertos y 27 historias de Jira trazadas. El equipo guardó el dashboard vivo y pasó cambios a ejecutables.
  • Producto B, vN → vN+1. 56 cambios en 86 unidades de seguimiento, 27 preguntas a expertos y 14 comentarios de revisores incorporados al plan.
  • SDK móvil del Producto A, vN → vN+1. 16 cambios de contenido y 3 enlaces rotos encontrados en el análisis de cambios; una revisión bilingüe aparte encontró 3 brechas.

Los dos productos comparten ahora el mismo formato de dashboard y de guía.

Lo que aún no prueba

No he medido las horas por plan antes y después de la metodología. Tampoco tengo un conteo de los cambios que llegaron al release sin retrabajo, ni de los bloqueados que se resolvieron antes del release. La metodología está en uso; su eficiencia aún no está probada.

Qué haría después

Registrar las horas por plan en los próximos releases y compararlas con la forma anterior, sin método. Seguir cuántos cambios bloqueados se resuelven antes de cada release, con el dashboard que el equipo ya mantiene.