KOUD-00 DOCUMENTO INTERNO · PMO
Procesos de
Gestión de Proyectos
Cómo KOUD combina la rigidez documental que exige la certificación con la dinámica ágil que exige la entrega de software. Un modelo híbrido: Scrum + Waterfall, en convivencia.
■Rígido / obligatorio
◌Dinámico / flexible
KOUD-01 EL MODELO
Un solo proyecto, dos naturalezas
KOUD prepara sus proyectos para certificación. Eso implica burocracia real: documentos y procesos de cumplimiento obligatorio. Pero el desarrollo de software necesita adaptarse al día a día. Por eso convive lo rígido con lo dinámico dentro del mismo ciclo de vida.
RÍGIDO
Lo que no se negocia
- ERS firmado antes de iniciar desarrollo
- Jerarquía Epic → Feature → PBI → Task
- Control de cambios en plantilla oficial — siempre pasa por Comercial
- Acta de aceptación y garantía formal
DINÁMICO
Lo que se adapta
- Sprint planning, dailies, reviews, retros
- Priorización continua del backlog
- Ajustes de alcance dentro del presupuesto
- Duración y ritmo según Premium o FastSoft
KOUD-02 CLASIFICACIÓN
Tres tipos de proyecto
Todo proyecto en KOUD entra en una de estas tres categorías. Este documento profundiza en Desarrollo a la Medida, donde vive el modelo híbrido completo.
01
Desarrollo a la Medida
Construcción de software desde cero o evolución de un producto propio del cliente. Incluye las modalidades Premium y FastSoft.
02
Staffing
Asignación de talento técnico para integrarse a los equipos o procesos del cliente.
03
Soporte
Atención continua a sistemas ya entregados, incluyendo garantía y mantenimiento posterior.
KOUD-03 DESARROLLO A LA MEDIDA
Premium vs. FastSoft
Ambas modalidades se miden con los mismos indicadores y siguen el mismo proceso. La diferencia está en duración, precisión de estimación y ritmo de ejecución.
| Desarrollo Premium | FastSoft |
|---|
| Duración | Mayor a 8 semanas | Menor a 8 semanas |
| Estimación | En horas, alcance amplio | En semanas u horas — más puntual |
| Medición | Mismo modelo de indicadores para ambas modalidades |
| Periodo de estabilidad | Máximo 2 semanas | Máximo 1 semana |
| Garantía estándar | 1 año | 30 días |
KOUD-04 CICLO DE VIDA
El recorrido completo
Desde que llega el lead hasta que el proyecto entra en garantía, el proyecto pasa por ocho momentos. Las siguientes láminas detallan cada uno.
◌ ciclo abierto
Si el cliente contrata una nueva fase de desarrollo a la medida, el ciclo se reinicia desde el proceso de desarrollo.
KOUD-05 FASE 01 · COMERCIAL
De lead a cliente aprobado
01Recepción
Comercial recibe el lead.
02Calificación
Se califica al lead.
03Expectativa
Se analiza la expectativa del cliente.
04Propuesta
Alcance en horas, validado con Operaciones.
05Prototipo
Se genera y se presenta al cliente.
06Aprobación
El cliente aprueba la propuesta.
KOUD-06 FASE 02 · ALTA DE PROYECTO
Arranca el proyecto
Con el visto bueno del cliente, el proyecto se pone en marcha formalmente.
01Notificación
Se avisa a todos los involucrados del inicio del proyecto.
02Anticipo
Se gestiona el cobro del anticipo con el cliente.
03Asignación de líderes
Dir. de Operaciones asigna a los responsables del proyecto.
04Pago confirmado
El cliente paga el anticipo — se dispara el Briefing.
KOUD-07 FASE 03 · BRIEFING
El pase de conocimiento
El consultor comercial llena un formato de briefing, que se valida y se comparte en una sesión conjunta. El objetivo: que el equipo de desarrollo sepa exactamente qué se le vendió al cliente — y qué no.
PARTICIPANTES
Sesión de briefing
- Consultor comercial
- Dir. de Operaciones
- Customer Success
- Analista (si aplica)
- PMO
SE COMPARTE
Insumos obligatorios
- Qué sí y qué no se le vendió al cliente
- Prototipo presentado en la venta
- Estimación aprobada
- Archivos compartidos por el cliente
KOUD-08 FASE 04 · KICK-OFF
El pase de responsabilidad al PM
El PM ya revisó la información del briefing, generó un Gantt preliminar y agenda el kick-off — la primera reunión formal con el cliente.
PARTICIPANTES
Reunión de kick-off
- Consultor comercial
- Dir. de Operaciones
- Customer Success
- PM
- Cliente
SE DEFINE
Acuerdos del kick-off
- Validación del alcance comprado
- Pase de responsabilidad al PM
- Forma de trabajo con el cliente
- Fechas de entrega acordadas
- Identificación de riesgos iniciales
KOUD-09 FASE 05 · PRE-DESARROLLO
Dos pistas en paralelo
Mientras el analista construye el documento que habilita el desarrollo, infraestructura prepara el terreno técnico. Ninguna fase de desarrollo inicia sin ambas completas.
Análisis · ERS
■obligatorio
Analista revisa la estimación aprobada.
Analiza el prototipo y compara faltantes.
Documenta requerimientos en el ERS (documento obligatorio).
Sesiones con comercial y sesiones con el cliente (calendario enviado) para dudas puntuales.
El cliente valida y firma el ERS — la firma siempre es obligatoria.
Regla dura: sin análisis terminado, el desarrollo no inicia.
Configuración de ambiente
◌en paralelo
El PM solicita la generación del ambiente a Infraestructura.
Proyecto en Azure DevOps.
Ambientes Dev y QA (si aplica).
DOCUMENTOS DEL PM
■obligatorio
Cuatro documentos antes de arrancar
En paralelo al ERS, el PM genera cuatro documentos y los envía al cliente con copia a PMO.
- Declaratoria de trabajo
- Plan de comunicación
- Plan de riesgos (si aplica)
- Roles y responsabilidades
La Declaratoria de trabajo requiere firma del cliente — al igual que el ERS, sin firma no hay inicio de desarrollo.
KOUD-10 FASE 06 · DESARROLLO
Scrum por dentro, Waterfall por fuera
El equipo vive las ceremonias ágiles completas, pero cada Product Backlog Item respira dentro del presupuesto aprobado del proyecto. Ahí está el híbrido.
CEREMONIAS SCRUM
El ritmo
- Sprints — máximo 2 semanas
- Sprint planning
- Dailies
- Sprint review
- Retrospective
CONTROL WATERFALL
El límite
- Todo PBI debe estar estimado con base en la propuesta técnica de alcance
- Todo PBI se describe como valor entregado al cliente, no como tarea técnica
- Las actividades técnicas se registran como Task, no como PBI
KOUD-11 AZURE DEVOPS
La jerarquía no es negociable
Toda tarjeta creada debe estar ligada a un padre. Sin excepción.
01Epic
El gran bloque de valor.
02Feature
Agrupador funcional.
03PBI
Valor de negocio para el cliente.
04Task
Actividad técnica concreta.
SPRINT PLANNING
- Fechas configuradas, máximo 2 semanas por sprint
- No agregar más tarjetas al sprint activo, salvo que sea necesario
- Tarjetas no terminadas se mueven al siguiente sprint
MANUAL DE OPERACIÓN
- Commits diarios cuando se está desarrollando
- Flujo de movimiento de PBIs respetado por todo el equipo
FLUJO DE LA TARJETA
De la creación al cierre
01Creación
El PM genera la tarjeta.
02Approved
El PM la aprueba para trabajarse en el sprint.
03Committed / Dependency
El Dev la pasa aquí al terminar su parte.
04QA revisa
Decide Bug (regresa) o Done.
El QA es el único autorizado para mover a Done las tarjetas de desarrollo. Las tarjetas de administración y análisis las cierra el PM.
ADMINISTRACIÓN Y ANÁLISIS
También llevan la jerarquía completa Epic → Feature → PBI. En Administración, cada sprint genera una nueva tarjeta PBI. En Análisis, la tarjeta PBI se genera por tema de análisis, no por sprint.
KOUD-12 QA · HORAS · ENTREGAS
Lo que se registra durante el sprint
QA
Calidad
- Generación de matriz de pruebas
- Comunicación de resultados
- Validación de flujos
REGISTRO DE HORAS
Tiempo
- Registro diario — no debe dejarse al final de la semana
- 48 horas para registrar tiempo faltante en tarjetas cerradas
- Registro de tiempos administrativos, obligatorio
ENTREGAS
Trazabilidad
- Registro de liberación de entregas
- Registro de minutas y acuerdos
KOUD-13 CONTROL DE CAMBIOS
Cuando el alcance se mueve
Todo cambio pasa por un mismo embudo formal — desde la estimación hasta el archivo en SharePoint.
01Estimación
En plantilla oficial.
02Clasificación
Valor agregado o cotizable.
03Comercial
Siempre pasa por Comercial antes de cotizar al cliente.
04Cotización
Se envía al cliente con el presupuesto.
05Aprobación
Notificación a Operaciones, Administración y PMO.
06Archivo
Almacenamiento en SharePoint.
KOUD-14 FASE 07 · CIERRE Y PASE A PRODUCCIÓN
Estabilidad e implementación
ESTABILIDAD
Periodo de pruebas del cliente
- Máximo 2 semanas en Desarrollo Premium
- Máximo 1 semana en FastSoft
- Se envía checklist de validación al cliente
- Solicitudes de ajuste solo en formato de plantilla — si no llega en formato, no se considera
- Si afecta alcance, reglas o es función nueva → va a Control de Cambios
IMPLEMENTACIÓN
Puesta en marcha
- Implementación en servidor de producción — opcional
- En caso contrario: entrega de código, base de datos e indicaciones técnicas
KOUD-15 FASE 08 · CIERRE Y GARANTÍA
De la entrega al soporte
CIERRE OPERATIVO
Pruebas generales en producción.
CIERRE ADMINISTRATIVO
Envío del acta de aceptación, que marca el inicio y fin de la garantía.
GARANTÍA
Estándar: 1 año en Premium · 30 días en FastSoft. La duración exacta depende de lo negociado.
■ soporte en smartsuite
Al iniciar la garantía, el proyecto se activa en SmartSuite como Soporte: alta del cliente con su modalidad, registro de solicitudes por tipo (requerimientos con pago, solicitudes de llamada), y solicitud a PMO de un dashboard para el cliente.
KOUD-16 CIERRE DEL CICLO
El ciclo vuelve a empezar
Si el proyecto entra en otra fase de desarrollo a la medida, el ciclo de desarrollo se reinicia. La rigidez documental que exige la certificación y la dinámica ágil que exige el software no compiten entre sí — conviven en cada vuelta del ciclo.
■Rígido: certificación, trazabilidad, firma
◌Dinámico: sprints, ritmo, adaptación
