SaaS multi-tenant para el ciclo de vida del desarrollo de software

Planifica el trabajo. Gobierna cada despliegue.

Épicas, sprints y tableros por un lado. Por el otro, un flujo de gobierno del cambio que lleva cada versión de desarrollo a producción con autorización del comité, evidencia de instalación y una traza de auditoría completa.

  • Aislamiento de inquilinos en tres capas
  • Bitácora de auditoría de solo anexado
  • Español e inglés

11

Fases de despliegue gobernadas

11

Tipos de work item

3

Capas de aislamiento de inquilinos

2

Idiomas de la interfaz

Capacidades

Todo lo que el ciclo de entrega necesita, en un solo lugar

La planificación, la ejecución y el gobierno comparten un mismo modelo de datos, de modo que una tarea, el sprint al que pertenece y la versión que la despliega nunca son tres herramientas desconectadas contando tres historias distintas.

Work items configurables

Épica, Característica, PBI y Tarea, además de Bug, Incidencia, Impedimento y Soporte. Los estados, las transiciones y los campos obligatorios se definen por inquilino, no los fijamos nosotros.

Tableros y backlog

Arrastra una tarjeta y el flujo decide si el movimiento es válido. Las transiciones no permitidas se rechazan con un motivo, en lugar de aceptarse en silencio.

Sprints y capacidad

Planifica según la disponibilidad real: calendarios de equipo, capacidad por persona y burndown calculado a partir del historial, no de un campo actualizado a mano.

Informes que responden por qué

Cuellos de botella del flujo, flujo acumulado y cumplimiento de fechas calculados desde el historial real de transiciones: el informe dice qué pasó y dónde, no solo cuántos.

Business Case e inversión

Conecta la entrega con el negocio: área responsable, centro de costos, monto de inversión y los despliegues que lo consumieron, en un mismo registro.

Roles con límites reales

Permisos atómicos, denegados por defecto. El jefe de proyecto gobierna el trabajo; el administrador del inquilino gobierna el sistema, y ninguno puede otorgarse la autoridad del otro.

Control dinámico

El proceso se adapta a tu organización

Los flujos, los estados y las reglas de campos viven en la configuración, no en nuestro código. Dos inquilinos de la misma plataforma pueden operar procesos realmente distintos, y cambiarlos sin esperar a una nueva versión.

  • Máquinas de estado por inquilino Agrega un estado, redirige una transición, exige un comentario en las que importan. Cada transición conserva un motivo con nombre derivado del par que conecta.
  • Políticas de campos por estado Decide qué campos son obligatorios, editables o bloqueados en cada estado, para que la calidad del dato se exija en el momento del cambio.
  • Roles y planes configurables Los roles funcionales son plantillas editables, y cada plan decide a qué módulos puede llegar un espacio de trabajo.

Cualquier sector

No está hecha para una industria: está hecha para tomar la forma de la tuya

Toda organización que despliega cambios necesita lo mismo: una forma de dar seguimiento a lo que ocurre, un único lugar donde vive la información y evidencia de quién aprobó qué. Lo que cambia entre industrias es el proceso, y aquí el proceso es configuración, no nuestro código.

Banca y finanzas Ventanas de cambio, segregación de funciones y una traza auditable.
Salud Versiones controladas y evidencia conservada para revisión.
Gobierno y sector público Autorización formal y trazabilidad desde la solicitud hasta la versión.
Retail y comercio electrónico Versiones frecuentes sin perder el control del calendario.
Manufactura Sistemas de planta donde una parada no planificada sale cara.
Telecomunicaciones Muchos equipos y proveedores convergiendo en una misma versión.
Logística y transporte Operaciones que no pueden detenerse mientras entra un cambio.
Educación y servicios Ciclos estacionales con ventanas de planificación claras.

Un solo lugar para la información

Cuando la solicitud, el trabajo, la aprobación y la evidencia viven en herramientas distintas, conciliarlas se vuelve el trabajo de alguien. Aquí son el mismo registro, así que no hay nada que conciliar.

Un método, no una costumbre

Un flujo que el software hace cumplir da a todos los equipos los mismos pasos. Deja de depender de quién esté de turno y sobrevive a la persona que recordaba cómo se hacía.

Respuestas cuando se piden

Qué se desplegó, cuándo, quién lo autorizó y qué pasó después: reconstruible desde el propio registro, venga la pregunta de una auditoría, de un cliente o del directorio.

Los sectores anteriores son ejemplos, no plantillas empaquetadas: lo que se adapta es el flujo, los estados, las reglas de campos y los roles, configurados por espacio de trabajo.

Gobierno de cambios

Cada versión atraviesa las mismas compuertas

No es un campo de estado que alguien recuerda actualizar: es una máquina de estados. Cada fase tiene un rol responsable y un requisito de salida, y las transiciones que importan exigen un motivo escrito antes de permitirse.

  1. 1 Nuevo
  2. 2 Desarrollo
  3. 3 Code Review
  4. 4 Pruebas
  5. 5 Enviado a Comité
  6. 6 Autorizado por Comité
  7. 7 Instalado Pre
  8. 8 Enviado a Comité Prod
  9. 9 Autorizado por Comité Prod
  10. 10 Instalado Prod
  11. 11 Completado

Un comité, no una casilla

Producción la autoriza un aprobador con nombre que ostenta el rol, dos veces: una para Pre y otra para Prod. Se registran la decisión, el aprobador y el momento.

Evidencia, no promesas

La evidencia de instalación se adjunta a la fase que le corresponde, para que un auditor pueda reconstruir qué se desplegó, cuándo y quién lo aprobó.

Los rollbacks abren su propio bug

Un rollback en producción exige un motivo obligatorio y genera un bug de severidad 1 vinculado al despliegue. La falla queda registrada, nunca se reintenta en silencio.

Dónde encaja

Un gestor de incidencias planifica el trabajo. Un pipeline despliega el código. Ninguno gobierna el cambio.

La mayoría de los equipos terminan con ambos, más una hoja de cálculo y un hilo de correo sosteniendo las aprobaciones. DevGov mantiene la aprobación, la evidencia y el ítem de trabajo en un mismo registro.

Desliza la tabla hacia los lados para ver todas las columnas.

Capacidades nativas por categoría de herramienta
Capacidad Gestor de incidencias Pipeline CI/CD DevGov
Backlog, tableros y sprints Nativo Fuera de su propósito Nativo
Compilación y despliegue automatizados Fuera de su propósito Nativo Nativo
Autorización del comité de cambios por rol Normalmente se añade Normalmente se añade Nativo
Evidencia de instalación en Pre y Producción en el registro Normalmente se añade Normalmente se añade Nativo
El rollback genera automáticamente un bug de severidad 1 vinculado Fuera de su propósito Fuera de su propósito Nativo
Configuración de flujos y políticas de campos por inquilino Normalmente se añade Fuera de su propósito Nativo
Bitácora de auditoría de solo anexado sobre trabajo y versiones Normalmente se añade Normalmente se añade Nativo

Esto compara lo que hace cada categoría de herramienta de forma nativa. Muchos productos de las dos primeras columnas pueden cubrir las filas restantes mediante complementos, integraciones o desarrollo a medida; la diferencia está en si llega ya integrado y gobernado, o si tienes que construirlo y mantenerlo tú.

Aislado por subdominio

Cada espacio de trabajo responde en su propio subdominio, y toda consulta se acota a su inquilino en la capa de repositorio, no por recordar agregar un filtro.

Auditoría de solo anexado

Se registran los cambios de estado, las transiciones de fase, los cambios de permisos y los accesos denegados. La aplicación nunca actualiza ni elimina un registro de auditoría.

Endurecido por defecto

Permisos denegados por defecto, verificación de propiedad en cada endpoint, límite de peticiones en rutas sensibles y una política de contenido que prohíbe el script en línea.

Se instala en tu teléfono

El espacio de trabajo se puede instalar como aplicación en Android, iOS y escritorio, con soporte sin conexión y su propio canal de actualizaciones.

Acerca de y legal

Qué es la plataforma y los términos que rigen su uso

DevGov

Un SaaS multi-tenant para el ciclo de vida del desarrollo de software — ítems de trabajo desde Epic hasta Task, además de un módulo de Deployment de primer nivel que gobierna cada release mediante aprobación de comité y evidencia de instalación.

11 Fases del deployment
11 tipos de work item
14 roles integrados
3 capas de aislamiento de tenant

Nuestra misión

Dar a cada equipo una única fuente de verdad, auditable, de qué se está construyendo y qué se está desplegando — sin forzar a todos al mismo proceso rígido.

Visión

Un lugar donde "¿quién aprobó esto?" y "¿qué cambió?" siempre tienen una respuesta inmediata y confiable — para un equipo de diez personas o una organización que corre docenas de tenants en paralelo.

Alcance

Desde el primer elemento del backlog hasta la última instalación en Producción — una sola plataforma para planificar, construir, revisar y entregar, en lugar de combinar varias herramientas desconectadas entre sí.

Lo que valoramos

Aislamiento de tenant

Cada consulta, cada escritura, cada archivo — acotado a tu tenant en cada capa, no solo en la pantalla de inicio de sesión.

Trazabilidad

Cada cambio de estado, cada fase de deployment, cada edición de permisos — añadido a una bitácora de auditoría que nadie puede reescribir en silencio.

Adaptabilidad

Los estados de los ítems de trabajo, los roles y los flujos son configurables por tenant — la plataforma se adapta a tu proceso, no al revés.

Rendición de cuentas

Una decisión de comité, un permiso otorgado, un cambio de rol — siempre realizados por una persona identificable, nunca de forma anónima ni automática.

Diseñado para escalar

Listas paginadas por cursor y patrones anti-N+1 en toda la aplicación — un proyecto con diez work items y uno con diez mil se comportan igual.

Sin dependencia de tecnología propietaria

Componentes estándar y bien conocidos — MySQL, JWT, bcrypt — en lugar de una caja negra propietaria que solo el operador de la plataforma puede entender.

Qué lo hace diferente

Un flujo real de gobierno de cambios

El módulo de Deployment lleva un cambio a través de 9 fases — desarrollo, revisión, autorización del comité, evidencia de instalación en Pre y Prod — con bugs generados automáticamente ante un rollback.

La jerarquía completa de ítems de trabajo

Epic → Feature → PBI/User Story → Task, además de Bug, Issue, Impediment, PreRelease Defect y Support — un solo backlog, no cinco rastreadores desconectados entre sí.

Roles que coinciden con cómo realmente gobiernas

Administrador de Tenant gobierna el sistema; SCRUM/PM gobierna el trabajo. Los roles funcionales — PO, Tech Lead, QA, Release Manager, Aprobador de Comité — son plantillas editables, no etiquetas fijas.

Una bitácora de auditoría que no se puede editar

De solo escritura por diseño — sin UPDATE ni DELETE desde dentro de la aplicación. Lo que pasó, pasó.

Bilingüe desde el primer día

Cada pantalla — incluida esta — está disponible en español e inglés, intercambiable en cualquier momento, no traducida como último paso.

Seguridad alineada con OWASP y NIST, desde el primer día

Cada cambio se analiza contra el OWASP Top 10 antes de publicarse, y los propios controles de la plataforma — acceso, cifrado, bitácora de auditoría — se construyen siguiendo los lineamientos de NIST desde el inicio, no agregados después. Ver "Información Legal" → "3. Seguridad de los datos" para el detalle.

Construida para

Equipos de entrega Plan
Comités de cambio Aprobar
Auditoría y cumplimiento Demostrar
Negocio y dirección Decidir

Un mismo registro sirve a los cuatro: el equipo planifica sobre él, el comité autoriza sobre él, la auditoría lo relee y el negocio ve qué compró la inversión, en lugar de cuatro herramientas que hay que conciliar.

Reúne tus versiones bajo el mismo techo que tu trabajo

Inicia sesión en tu espacio de trabajo, o contacta al administrador de tu organización para que te abran uno.