En la gestión de proyectos de sistemas, el mayor riesgo no es no terminar a tiempo, sino terminar algo que no cumple con el estándar esperado. El problema suele estar en Criterios de Aceptación (AC) vagos como «el sistema debe ser rápido» o «la IA debe ser precisa». Para un Project Manager técnico, esto es inaceptable.
Si no puedes medirlo, no puedes gestionarlo. Un criterio de aceptación cualitativo es una invitación abierta al conflicto con el stakeholder durante la entrega. Como ingenieros, debemos transformar deseos subjetivos en umbrales de rendimiento objetivos (SLOs).
De la Subjetividad a la Métrica de Ingeniería
Para que un criterio de aceptación sea robusto en sistemas e IA, debe seguir la estructura de umbral técnico. Aquí algunos ejemplos de transformación:
- Subjetivo: «El reporte debe cargar rápido«.Cuantificable: «El tiempo de respuesta (P95) para la generación del reporte no debe exceder los 2.5 segundos con 100 usuarios concurrentes«.
- Subjetivo: «El modelo de IA debe detectar bien los fallos«.Cuantificable: «El modelo debe mantener un Recall > 0.92 y una Precisión > 0.85 en el conjunto de test X«.
- Subjetivo: «El código debe ser de calidad«.Cuantificable: «El código debe tener cero vulnerabilidades críticas en SonarQube y una cobertura de tests unitarios > 80%«.
Integración en el Flujo de Trabajo (Definition of Done)
Implementar QACs requiere que el Project Manager trabaje estrechamente con el equipo de QA y Arquitectura:
- Baseline: Define el rendimiento actual del sistema antes de proponer mejoras.
- Acuerdo con Stakeholders: Valida que los umbrales numéricos realmente cubren la necesidad de negocio.
- Automatización: Los criterios cuantificables deben ser validados por scripts o herramientas de monitorización en el pipeline de CI/CD.
Recurso Gratis: Diccionario de Métricas para Criterios de Aceptación
He preparado una Guía Rápida en PDF que lista las métricas estándar para proyectos de Software, IA e Infraestructura. Aconseja al product owner/manager que la utilice para redactar las historias de usuario y evitar discusiones estériles en la revisión de Sprint.
Referencias Técnicas
- IEEE 29148-2018. ISO/IEC/IEEE International Standard – Systems and software engineering — Life cycle processes — Requirements engineering.
- Wiegers, K., & Beatty, J. (2013). Software Requirements. Microsoft Press.
- Beyer, B., et al. (2016). Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media.
Autor
Antonio Gutiérrez es un Jefe de Proyectos IT con una amplia trayectoria en la dirección de equipos técnicos y el desarrollo de negocios online. Especialista en optimización de procesos y gestión de proyectos con tecnología IA, destaca por su capacidad para integrar soluciones innovadoras en entornos digitales complejos. Con una fuerte vocación por la formación y la responsabilidad profesional, Antonio se dedica a transmitir su experiencia en jefatura de proyectos para ayudar a otros a evolucionar en el sector tecnológico. Actualmente, ofrece consultoría estratégica y recursos especializados para profesionales que buscan liderar con éxito la transformación digital.
