Esto requiere un enfoque metodológico híbrido a menudo denominado Agile contractual o Water-Scrum-Fall. El Analista de Negocios debe establecer una Matriz de Trazabilidad de Requisitos que mapee los entregables de Waterfall de alto nivel a Épicas, manteniendo la línea base contractual. Implementar una fase de Prueba de Concepto dentro del hito de diseño para satisfacer las necesidades de validación de los interesados sin violar las restricciones de precio fijo. Crear un Comité de Control de Cambios con umbrales de variación estrictos y documentar supuestos como exclusiones contractuales explícitas.
En una empresa de fabricación, nos enfrentamos exactamente a este conflicto durante un despliegue de Salesforce CPQ para maquinaria configurable compleja. El contrato de precio fijo de $2M requería la aprobación de Documentos de Diseño Técnico el segundo mes, pero el equipo de operaciones de ventas insistió en que no podían validar las reglas de precios sin interactuar con un sistema en vivo. El proveedor amenazó con invocar cláusulas de penalización cada vez que solicitábamos ajustes de alcance después de descubrir que el código Apex no podía manejar la complejidad de precios matriciales originalmente estimados.
Solución 1: Waterfall puro con Diseño Grande por Adelantado
Consideramos completar una documentación exhaustiva antes de cualquier desarrollo, creando mapas de procesos detallados de Visio y diagramas UML para cada escenario de precios. Este enfoque satisfaría los hitos contractuales y minimiza los riesgos de penalización al congelar el alcance temprano. Sin embargo, las desventajas fueron severas: los interesados no podían visualizar el flujo de UI, lo que llevó a 40 horas de retrabajo por cada regla de precios descubierta durante la UAT, y el negocio se negó a aprobar diseños teóricos que no podían probar.
Solución 2: Agile puro con Renegociación de Contrato
Alternativamente, podríamos haber cambiado a sprints de Scrum y haber intentado renegociar la declaración de trabajo a tiempo y materiales. Esto permitiría la creación de prototipos iterativos con Lightning Web Components y retroalimentación genuina de los interesados. Las desventajas incluían la imposibilidad legal—el equipo de aprovisionamiento no tenía autoridad para alterar el contrato firmado—y la negativa del CFO a aceptar una exposición presupuestaria indefinida dada la presión de los plazos de fin de trimestre.
Solución 3: Modelo Híbrido con Hito de Prototipo de Diseño
Elegimos bifurcar el Documento de Diseño Técnico en "Diseño Estático" (modelo de datos, arquitectura de integración) y "Prototipo Dinámico" (maquetas clicables de Figma con datos de sandbox de Salesforce). Introdujimos un Sprint Cero de cuatro semanas dentro de la fase de diseño, entregando configuraciones CPQ funcionales para tres familias de productos representativas. Esto satisfizo la obligación contractual al entregar una especificación de diseño detallada que incluía prototipos funcionales, mientras mantenía el límite de precio fijo al tratar el prototipo como un artefacto de diseño en lugar de software funcional.
El resultado fue exitoso: los interesados validaron la lógica de precios temprano, reduciendo los defectos de UAT en un 70%. Entregamos dentro de la ventana de variación del 10% documentando todas las características no prototipadas como exclusiones de la Fase 2 en el apéndice del TDD. El enfoque híbrido se convirtió en nuestra plantilla estándar para futuros compromisos de Agile a precio fijo.
¿Cómo previenes la expansión del alcance cuando los interesados demandan "solo una pequeña característica más" durante las revisiones del prototipo sin activar penalizaciones contractuales?
Los candidatos a menudo sugieren simplemente decir que no o invocar inmediatamente órdenes de cambio. El enfoque correcto implica establecer un Protocolo de Triage de Alcance antes de cualquier sesión de demostración. Categorizar todas las solicitudes en Defecto (funcionalidad existente no funcionando), Clarificación (interpretación ambigua de requisitos) o Mejora (nueva capacidad). Solo las mejoras activan el proceso de control de cambios. Documentar todo en Confluence con registros de decisiones atribuidos a cláusulas contractuales específicas.
Para la protección del buffer del 10%, mantener un Fondo de Riesgos de puntos de historia (típicamente el 15% de la capacidad del sprint) específicamente para trabajos de Clarificación. Este fondo absorbe la incertidumbre dentro del presupuesto en lugar de tratar cada descubrimiento como un cambio de alcance. Rastrear estas reservas en Jira utilizando etiquetas o un epic de buffer separado para mantener visibilidad mientras se protege el umbral de variación contractual.
¿Cuál es la técnica específica para mapear las secciones BRD de Waterfall a Épicas Agile sin perder la trazabilidad contractual?
Muchos candidatos sugieren simplemente adjuntar el BRD a los tickets de Jira. Esto no cumple con los requisitos de auditoría. En su lugar, usar una Matriz de Trazabilidad Bidireccional con descomposición jerárquica. Mapear Requisitos de Negocios a Épicas, Requisitos Funcionales a Características, y Especificaciones Técnicas a Historias de Usuario. Asignar a cada requisito BRD un identificador único (por ejemplo, BRD-3.2.1) que persista en todas las versiones de Jira.
Cuando el contrato exige una Especificación de Diseño, exportar las descripciones de Épicas, criterios de aceptación y enlaces de Figma a un documento formal. Utilizar DocuSign para firmas para mantener el control de versiones. Esto crea un artefacto legal que referencia artículos de trabajo Agile mientras cumple con los estándares de documentación de Waterfall y proporciona a los auditores la pista de papel requerida.
¿Cómo manejas el descubrimiento técnico de que Salesforce CPQ no puede soportar el complejo modelo de precios asumido en el contrato, cuando el proveedor afirma que es configuración estándar?
Los candidatos a menudo entran en pánico y sugieren cambiar de plataforma o aceptar la derrota. El enfoque profesional implica la Documentación de Spike Técnico y Análisis de Restricciones. Documentar inmediatamente los límites específicos del gobernador Apex o las restricciones del plugin CPQ Quote Calculator que impiden la solución. Crear un Registro de Decisiones comparando tres opciones: desarrollo de componentes Lightning personalizados (alto costo, alto riesgo), solución alternativa de proceso (impacto en el negocio), o solución de terceros de AppExchange (costo de licencia).
Presentar esto al Comité de Control de Cambios con una Evaluación de Impacto Empresarial mostrando los ingresos en riesgo si la restricción no se aborda. Si la restricción proviene de un supuesto contractual (por ejemplo, el sistema debe soportar precios por niveles ilimitados), argumentar que esto constituye una violación de Suposición de Cardinalidad. Esta reclasificación potencialmente mueve el ítem de cambio de alcance a clarificación contractual, evitando así penalizaciones mientras se entrega una solución técnica viable.