这需要一种混合方法论，通常称为合同敏捷或水-敏捷-瀑布。业务分析师必须建立一个需求可追溯性矩阵，将高层次的瀑布交付物映射到史诗，同时维护合同基线。在设计里程碑阶段实施概念验证，以满足利益相关者的验证需求，同时不违反固定价格的限制。创建一个变更控制委员会，设定严格的偏差阈值，并将假设记录为明确的合同排除条款。
在一家制造公司，我们在为复杂可配置机械推出Salesforce CPQ时，正面临这种冲突。200万美元的固定价格合同要求在第二个月签署技术设计文件，但销售运营团队坚称，他们在与实时系统互动之前无法验证定价规则。当我们发现Apex代码无法处理最初估算的矩阵定价复杂性时，供应商威胁在每次请求范围调整时引发罚款条款。
解决方案1：纯瀑布法与提前大设计
我们考虑在任何开发之前完成详尽的文档，创建每个定价情景的详细Visio流程图和UML图。这种方法将满足合同里程碑，并通过尽早冻结范围来减少罚款风险。然而，缺点很严重：利益相关者无法可视化UI流程，导致每个在UAT中发现的定价规则需要40小时的返工，而业务拒绝批准他们无法测试的理论设计。
解决方案2：纯敏捷与合同重新谈判
或者，我们可以转向Scrum迭代并尝试重新谈判工作说明书为按时间和材料计费。这将允许使用Lightning Web Components进行迭代原型设计和真正的利益相关者反馈。缺点包括法律上的不可能性——采购团队没有权力修改签署的合同——以及CFO拒绝接受在季度末截止压力下的无上限预算风险。
解决方案3：带有设计原型里程碑的混合模型
我们选择将技术设计文档分为“静态设计”（数据模型，集成架构）和“动态原型”（带有Salesforce沙箱数据的可单击Figma模型）。我们在设计阶段嵌入了四周的Sprint Zero，为三个代表性产品系列提供工作的CPQ配置。这满足了通过交付包含功能原型的详细设计规范而带来的合同义务，同时通过将原型视为设计文物而不是工作软件来保持固定价格的限制。
结果成功：利益相关者提前验证了定价逻辑，将UAT缺陷减少了70%。我们在10%的偏差范围内交付，记录所有未原型化功能作为TDD附录中的第2阶段排除。混合方法成为我们未来固定价格敏捷项目的标准模板。
当利益相关者在原型审查中要求“再来一个小功能”时，您如何防止范围蔓延而不触发合同罚款？
候选人通常建议简单地拒绝或立即实施变更订单。正确的做法是，在任何演示会议之前建立范围筛选协议。将所有请求分类为缺陷（现有功能未正常工作）、澄清（模糊要求解释）或增强（新功能）。只有增强请求触发变更控制流程。使用Confluence记录所有决策日志，并归因于特定合同条款。
为了10%的缓冲保护，保持风险储备的故事点（通常为冲刺容量的15%），专门用于澄清工作。此储备在预算内吸收不确定性，而不是将每次发现视为范围变化。使用标签或单独的缓冲史诗在Jira中跟踪这些储备，以保持透明度，并保护合同偏差阈值。
将瀑布BRD部分映射到敏捷史诗而不失去合同可追溯性的具体技术是什么？
许多候选人建议简单地将BRD附加到Jira票据。这未能满足审计要求。相反，请使用双向可追溯性矩阵进行分层分解。将业务需求映射到史诗，功能需求映射到特性，技术规格映射到用户故事。为每个BRD需求分配一个唯一标识符（例如，BRD-3.2.1），在所有Jira版本中保持不变。
当合同要求设计规范时，导出史诗描述，接受标准和Figma链接到正式文档中。使用DocuSign签名以保持版本控制。这创建了一个法律文物，引用敏捷工作项目，同时满足瀑布文档标准，并为审计员提供所需的纸质记录。
当供应商声称它是标准配置时，如何处理技术发现，即Salesforce CPQ无法支持合同中假定的复杂定价模型？
候选人通常会惊慌失措，建议更换平台或接受失败。专业的做法涉及技术尖峰文档和约束分析。立即记录特定的Apex限额或CPQ Quote Calculator插件限制，阻止解决方案。创建一个决策记录，比较三种选项：自定义Lightning组件开发（高成本，高风险）、过程变通（业务影响）或第三方AppExchange解决方案（许可成本）。
向变更控制委员会呈现此项，并提供商业影响评估，显示如果未解决约束可能面临的风险。如果约束源于合同假设（例如，系统应支持无限层定价），则争辩这构成基数假设违规。这种重新分类可能会将该项目从范围变更转为合同澄清，从而避免罚款，同时提供可行的技术解决方案。