En el proceso de documentar tu producto, estructurar adecuadamente la información es tan crítico como el contenido mismo. Al abordar tanto avalanchas de documentación existente como situaciones donde hay poco o ningún material previo, el desafío reside en cómo organizar este conocimiento de manera que sea intuitivo y accesible para el usuario. Este capítulo explora métodos efectivos para organizar y relacionar las diversas partes de la documentación, asegurando que cada pieza contribuya al entendimiento holístico del producto.
¿Cómo organizo “La Avalancha”? ¿Cómo relaciono las partes al documentar?
Aunque en esta serie estamos dando por hecho que algo de contenido hay, si tu reto es que hay cero unidades de documentación, también es importante tener una estructura antes de escribir.
Aquí buscamos trazar los grandes temas y aunar el enfoque y los límites para, por un lado, ordenar lo existente (nuestra avalancha) y, por otro lado, redactar lo que falta en la documentación del producto. Es importante recordar que nadie se lo va a leer entero en una tarde y seguido, sino que la gente irá saltando de un tema a otro, buscará respuestas a preguntas concretas o querrá actualizar parte del contenido. La documentación de un producto en desarrollo está viva, y se debe estructurar de manera flexible.
Con lo que hemos visto en capítulos anteriores, casi todo debería estar listo para elaborar un mapeo de la documentación y saber cómo se va a organizar la información: puede que te sirva una cronología de cómo ha ido evolucionando el producto, un índice de capítulos que van desde el frontend hasta el backend, un user journey que desgrane los requerimientos y decisiones de negocio tomadas…
Aquí tomaríamos los métodos de Diseño y montaríamos nuestra Arquitectura de la Información. Cada cual usa sus maneras de aterrizar, yo suelo comenzar con una hoja de cálculo (sí, el reducido tamaño de las celdas y su disposición en filas y columnas me ayuda a pensar), pero otros recurren a un cuaderno, un tablero digital, unos post-it… Aún no estamos escribiendo, así que es recomendable estructurar usando algo que permita pensamiento paralelo para ir moviendo los módulos de contenido.
Por ponerte un ejemplo…
Como la organización para la que trabajo es muy grande, mapeé la documentación de dos productos complejos (una en la parte de ejecución y otra en la de funcionamiento) de maneras muy distintas.
En una ocasión, lo hice por niveles de profundidad y frecuencia de uso: coloqué de manera más prominente aquellos artículos que se iban a consultar frecuentemente o que explicaban de manera eficiente (aunque superficial) los componentes y áreas. Los contenidos más en detalle y que se miraban para actualizar cada cuatrimestre o tras un post-mortem, estaban enlazados en un índice y en un menú secundario.
En la otra, los módulos se organizaban en torno a una página principal, tipo portada, que respondía a las preguntas básicas de quién (squad y stakeholders), qué (producto), cómo (diseño y desarrollo), por qué (negocio) y cuándo (roadmap).
Si quieres saber cómo continua la historia, haz click aquí: El Formato - Docutopía #7
