Plan de documentacion

​

Objetivo

Este plan define como debe crecer la documentacion funcional de Nubidoc para que una persona nueva pueda entender el producto, configurarlo y empezar a trabajar sin depender de explicaciones sueltas. La guia debe resolver tres necesidades:

• Orientar al usuario nuevo en el primer acceso y en la navegacion general.
• Explicar los flujos operativos habituales con pasos verificables.
• Mantener una relacion clara entre documentacion, cambios de producto y pruebas funcionales.

​

Alcance

La documentacion publica debe cubrir el uso real de Nubidoc desde el punto de vista del centro medico: configuracion inicial, usuarios, pacientes, agenda, historia clinica, facturacion, comunicacion, inventario, listados y administracion. Treebole Clinicas debe documentarse solo cuando el comportamiento, la pantalla o el flujo sean especificos. Cuando el flujo sea comun, se documenta una vez y se indica cualquier diferencia relevante. Quedan fuera de esta guia publica:

• Detalles internos de codigo, clases, tablas o despliegue.
• Datos reales de clientes, PIN, claves, correos privados o credenciales.
• Funcionalidades no verificadas en entorno, manual heredado o revision funcional.

​

Arquitectura

La documentacion se organiza en dos niveles:

1. Empezar: vision general, primeros pasos y criterio de mantenimiento de la guia.
2. Guia de usuario: modulos funcionales agrupados por trabajo diario, facturacion, comunicacion y gestion.

Cada pagina de modulo debe ayudar a completar tareas reales. El orden recomendado dentro de cada modulo es:

1. Para que sirve el modulo.
2. Antes de empezar: permisos, configuracion y datos necesarios.
3. Flujos principales paso a paso.
4. Acciones frecuentes y resultados esperados.
5. Errores habituales o situaciones bloqueantes.
6. Siguiente paso recomendado.

​

Plantilla de guia

Cada guia nueva o ampliada debe seguir esta plantilla minima: Cuando una guia necesite imagenes, la captura debe mostrar la pantalla real y estar libre de datos sensibles. Si una imagen se usa para explicar una accion concreta, el texto debe indicar el resultado esperado, no solo describir la captura.

​

Prioridad editorial

La primera fase de crecimiento debe priorizar los recorridos que desbloquean el uso diario:

1. Primer acceso, navegacion general y cambio de contrasena.
2. Configuracion base del centro, usuarios, permisos y datos maestros.
3. Alta, busqueda y mantenimiento de pacientes.
4. Creacion y gestion de citas.
5. Historia clinica y documentos principales.
6. Facturacion basica: presupuesto, factura, cobro y rectificacion.
7. Comunicaciones frecuentes: recordatorios, campanas y portal paciente.
8. Inventario, listados y administracion avanzada.

La documentacion de funciones nuevas debe incorporarse al modulo correspondiente antes de considerar cerrado el cambio funcional cuando afecte al uso del producto.

​

Calidad y verificacion

Una pagina se considera lista cuando cumple estas condiciones:

• El flujo esta explicado desde el punto de vista del usuario final.
• Los nombres de pantallas, botones y campos coinciden con la aplicacion.
• No contiene detalles tecnicos que no ayuden al usuario.
• No incluye datos reales ni secretos.
• Tiene pasos, resultado esperado y bloqueos frecuentes.
• Esta enlazada desde la navegacion si forma parte de la guia publica.

Si una funcionalidad esta parcialmente confirmada, debe documentarse como limitada o pendiente de verificacion. No se deben completar huecos por inferencia.

​

Sincronizacion con QA

Los cambios documentales relevantes deben cruzarse con las pruebas funcionales. Cuando una guia explica un flujo que tambien se prueba, la prueba debe apuntar a la guia y la guia debe facilitar el criterio funcional. En particular, el catalogo de pruebas funcionales debe cubrir los recorridos base de version:

• Alta publica de un centro nuevo.
• Acceso de usuario.
• Alta o busqueda de paciente.
• Creacion de cita.
• Nota o evolucion clinica.
• Factura y cobro.

Si una guia describe un flujo critico y no existe prueba funcional equivalente, debe quedar registrado como deuda de cobertura.

​

Mantenimiento

Cada cambio de producto debe revisar si afecta a:

• Una pantalla ya documentada.
• Un flujo paso a paso.
• Un permiso o configuracion previa.
• Un mensaje de error o estado vacio.
• Una prueba funcional existente.

Cuando afecte, la actualizacion documental debe incluir la pagina modificada, la referencia al cambio y la evidencia minima usada para validar el comportamiento.