Saltar al contenido principal

Ciclo de Vida de Proyectos (Greenfield)

Versión: 1.0
Estado: Borrador
Propósito: Estandarizar el proceso técnico desde la concepción hasta el inicio del desarrollo.

Este documento define los pasos obligatorios para iniciar cualquier nuevo proyecto o módulo desde cero en el ecosistema de Salud. El objetivo primordial es transicionar de una "Cultura de Urgencia" a una "Cultura de Ingeniería", priorizando la lógica y el flujo de procesos sobre el diseño visual.

1. El Flujo Secuencial de Ingeniería​

Para garantizar la coherencia técnica y minimizar el retrabajo, todo proyecto debe seguir este orden cronológico:

graph TD
  A[1. Descubrimiento y Propósito] --> B[2. Definición de Dominio]
  B --> C[3. Mapeo de Procesos y Lógica]
  C --> D[4. UX/UI - Prototipado]
  D --> E[5. Especificación Técnica y API]

2. Desglose de Fases​

Fase 1: Descubrimiento y Propósito (El "Por Qué")​

Responsables: Product Owner / Stakeholders
Entregables Documentales: vision-y-proposito.md, objetivos.md

Antes de cualquier propuesta técnica, se debe validar:

  • Definición del Problema: ¿Qué dolor del usuario o necesidad de negocio estamos resolviendo?
  • KPIs: ¿Cómo mediremos el éxito de este módulo una vez lanzado?
  • Stakeholders: ¿Quiénes son los actores internos y externos involucrados?

Fase 2: Definición de Dominio (El "Qué")​

Responsables: Arquitecto de Software / Tech Lead
Entregables Documentales: modelo-de-dominio.md, glosario.md

Establecemos los cimientos de la data y la comunicación:

  • Entidades: Identificación de objetos del mundo real (ej: Doctor, Receta, Sede, Póliza).
  • Lenguaje Ubicuo: Definir términos únicos para que Negocio y Desarrollo hablen exactamente el mismo idioma.
  • Relaciones: Cómo se conectan las entidades entre sí (1:1, 1:N, N:N).

Fase 3: Mapeo de Procesos y Lógica (El "Cómo funciona")​

Responsables: Tech Lead / Frontend & Backend Leads / UX Designer
Herramientas: Diagramas de Flujo en Miro / Mermaid.

Este paso es el corazón del proceso y debe ocurrir ANTES de cualquier diseño visual.

  • Flujos Lógicos: Dibujar el "Happy Path", estados de error, validaciones y bifurcaciones.
  • Reglas de Negocio: Definir restricciones técnicas (ej: "Un paciente no puede ver datos de otro paciente").
  • Validación de Viabilidad: Confirmar que la lógica es posible con la infraestructura actual.

Fase 4: UX/UI y Prototipado (El "Cómo se ve")​

Responsables: UX/UI Designer (Maria Fernanda)
Entregables: Figma / Prototipos de alta fidelidad.

Con la lógica blindada en la Fase 3, el equipo de diseño crea la interfaz:

  • Fidelidad: El diseño debe reflejar todos los estados lógicos definidos (carga, error, éxito).
  • Sistema de Diseño: Aplicar la identidad visual del proyecto (colores, tipografía de salud).
  • Aprobación de Stakeholders: Validación final del "look and feel" antes de codificar.

Fase 5: Especificación Técnica y API (El "Cómo se construye")​

Responsables: Equipo de Desarrollo (Backend y Frontend)
Documentación: especificaciones.md, Swagger (OpenAPI), ADRs.

Es el contrato final para la implementación:

  • Contratos de API: Definición de endpoints, métodos (GET, POST, etc.) y esquemas JSON.
  • Infraestructura: Cambios en la base de datos o nuevos servicios cloud necesarios.
  • Seguridad: Definición de roles y permisos específicos para el módulo.

3. Comparativa de Metodología de Trabajo​

EtapaCultura de Urgencia (Práctica Anterior)Cultura de Ingeniería (Práctica Actual)
InicioIdeas vagas y discusiones informales.Documentación formal de visión y alcance en Docusaurus.
PrioridadDiseño UX/UI inmediato.Flujo Lógico y procesos de negocio primero.
ConsecuenciaRediseño y reprogramación por lógica olvidada.El desarrollo fluye sobre una lógica ya validada.
DocumentaciónPost-desarrollo (o inexistente).Docs-as-Code: Documentación viva durante el ciclo.

Regla de Oro: Se prohíbe iniciar el prototipado visual en Figma (Fase 4) si el flujo lógico en Miro/Mermaid (Fase 3) no ha sido revisado, firmado y aprobado por el equipo técnico.