敏捷合同常见的五个错误（以及如何纠正）
合同是对两个组织在压力下行为方式的一种预测。当交付方法是敏捷的，而合同却假定一个固定且完全明确的交付物时，二者便朝相反方向拉扯。团队被要求在每个 Sprint 中检视并适应；合同却写得仿佛第一天就已知道全部答案。2021 年春天，混合团队、不断变化的优先级以及尚未平复的供应中断并存，对那些一年前就锁定范围、如今无法不经争执便加以更改的买方来说，这种错配变得代价高昂。
好消息是这些失败是可预见的。大多数敏捷合同的麻烦都可追溯到同样的几个错误，而每一个都有已知的解决办法，既能保护买方，又不会扼杀团队。
反复出现的错误
对固定范围按固定价格定价。 如果范围和价格都被冻结，剩下唯一可变的就是质量——而当截止日期临近时，正是质量在悄悄受损。敏捷假定范围围绕稳定的节奏浮动；冻结范围会在第一个 Sprint 之前就让方法失效。
将验收挂钩到一份需求文档上。 当验收与一份在任何人接触产品之前写就的两百页规格说明绑定时，团队获得的每一点认识都会变成需要争论的变更请求。最终交付的是文档，而不是可运行的产品。
把产品负责人角色当作可有可无。 买方常常签了合同，再指派一位无法做决定的兼职相关方。《Scrum 指南》明确指出，产品负责人负责对产品待办列表排序；买方一侧若没有获得授权的负责人，团队只能靠猜，而猜测代价高昂。
禁止变更，而不是为变更定价。 若变更控制流程要求任何调整都得经过一个委员会和三周的文书工作，这就等于告诉团队：适应是不受欢迎的。然而经验性方法的全部意义，正在于频繁而低成本的航向修正。
衡量投入而非价值。 按记录工时或「已完成」的故事点付费的合同，奖励的是活动本身。买方最终为动作买单，而不是为真正降低其风险的、可运行且有价值的增量买单。
让 Scrum 得以呼吸的合同写法
这一切都不需要奇特的法律结构。几种被充分理解的模式即可重新对齐激励，使合同与交付方法追求同一目标。
固定预算与节奏，让范围浮动。约定一个产能（在确定数量的 Sprint 内保持稳定的团队），由排好优先级的待办列表决定构建什么。买方掌控所交付的价值，而非一份冻结的功能清单。
将验收定义为满足「完成的定义」的、可运行且可发布的增量——而非对前期规格的符合。
在合同中指明获得授权的产品负责人，并就其可用性与决策响应时间设定服务水平期望。
纳入提前终止条款，或「白拿钱、免费换」条款，使买方在交付足够价值后可以停止，或免费替换同等规模的功能。
设置 Sprint 评审检查点，任一方都可依据可运行产品所揭示的情况来调整合作。
根本的转变，是从购买一件东西，转为购买一种能生产东西的能力，并每隔几周加以检视和引导。这比写明一个固定交付物更难，却远更贴近工作的真实运行方式——而且对买方保护更好，因为他们付费换取的是看得见的、已被证明的进展，而非附录里的承诺。
如果你正在谈判这样的合同，请克制住把敏捷措辞硬贴到瀑布式模板上的冲动。从节奏和获得授权的角色出发，让商务条款顺应团队真正的工作方式。
当采购措辞与交付方法相互掣肘时，XNM 的项目群与项目交付咨询 可以帮助你设计既保护买方、又让团队顺利交付的协议。