James Shore在2025年剑桥敏捷会议上探讨了软件开发部门的责任界定问题，强调需要主动定义自身责任，避免由业务伙伴代为决定，并分享了量化责任和初期实践的经验。

詹姆斯·肖尔：责任归属问题

主要内容概述

本文是詹姆斯·肖尔（James Shore）在2025年10月2日英国剑桥敏捷大会上的主题演讲《责任归属问题》的文字稿。演讲探讨了软件开发部门如何定义自身的责任，以避免业务伙伴以不恰当的方式代为定义。

核心问题

软件开发常被业务部门误解为“写代码”或“完成作业”，导致业务伙伴倾向于用“交付特定功能的时间”来衡量开发团队的责任。这种误解源于： 1. 影视作品的误导：将编程神化为瞬间完成的“黑客”行为。 2. 学校项目的局限：小型作业无需长期维护或大规模协作。 3. AI工具的假象：生成式AI工具虽能快速生成原型，但无法应对实际开发的复杂性。

软件开发的本质

肖尔引用肯特·贝克（Kent Beck）的“极限编程价值观”，强调软件开发的核心是： - 沟通与协作：跨角色、跨团队的协调。 - 反馈循环：验证是否构建了正确的东西以及是否正确构建。 - 简洁性：易于理解和修改的代码决定开发效率。 - 勇气与尊重：敢于做正确的事，并尊重相关各方。

业务部门的误解

业务部门常假设： - 只需准确定义需求即可得到正确结果。 - 存在唯一正确的解决方案和明确的实现路径。 - 进度延迟是因为开发人员不够努力。 - 施压能加快进度。

而实际上，软件开发是探索性过程，结果往往在过程中逐步明晰。

解决方案：产品赌注（Product Bets）

肖尔提出用“产品赌注”重新定义责任归属： 1. 定义价值：每个赌注聚焦于一个业务结果（如“通过家庭友好型大象活动开拓新市场”），而非具体功能。 2. 领导层参与：由高管（如首席产品官）担任赞助人，共同估算赌注的现值（Present Value）和最大赌注金额（Maximum Wager）。 3. 接受不确定性：通过“构建-测量-学习”循环快速验证假设，失败时及时止损。 4. 量化责任：团队承诺交付一定量的“估算价值”（如每年1000万美元），而非具体功能和时间。

实施挑战与经验

肖尔分享了在OpenSesame推行产品赌注的两年实践： - 初期阻力：领导层不愿承担估算价值的责任。 - 建立信任：通过改进预测准确性（如“群体智慧估算法”）和可视化非增值工作（如维护、故障处理时间）逐步赢得认可。 - 持续推动：反复倡导并与财务团队合作完善模型，最终在CEO支持下落地。

总结

软件开发需要主动定义自身的责任框架，避免被业务部门用不恰当的标准衡量。通过“产品赌注”，团队可以聚焦于创造业务价值，而非陷入功能与时间的拉锯战。肖尔强调：“我们可能是一个‘异国’，但仍需用业务伙伴的语言沟通。”

以下是评论内容的总结，涵盖主要观点和论据：

1. 责任与问责制

   • 支持观点：责任应是双向的，而非单方面强加（评论1）。
     引用："accountability as a 2-way pipe rather than a sink!"
   • 质疑观点：实际中很难界定失败责任，常因团队决策或外部因素模糊责任（评论3）。
     引用："anything can be dressed up as success, attributing negatives to external factors"

2. 产品开发与决策

   • 正面案例：通过“产品赌注”（product bets）提升战略讨论，但尚未验证结果（评论2）。
     引用："elevated our conversation around product strategy"
   • 批评观点：软件行业缺乏商业化的资源分配逻辑，过度依赖试错（评论5）。
     引用："A hack at it until it works methodology"

3. 管理层与技术团队矛盾

   • 案例：技术团队完成需求但公司未增长，责任被转嫁（评论10）。
     引用："CTO said: we delivered everything... but the company didn’t grow"
   • 观点：非技术CEO或CFO主导的公司可能因缺乏软件理解而失败（评论10）。

4. 流程与结果评估

   • 建议：应平衡过程目标（如努力）与结果目标（如业绩）（评论14）。
     引用："judged on how well you play your hands, not solely whether you win"
   • 实践：通过Scrum明确开发团队责任范围，拒绝承担模糊的长期愿景责任（评论13）。
     引用："We guard the process... predictable schedule"

5. 其他观点

   • 对产品经理角色的批评：缺乏实际决策能力，成为“冒牌角色”（评论12）。
   • 技术细节肯定：文章配图的替代文本（alt text）设计获赞（评论8）。

争议焦点：
- 责任界定是否可行（评论3 vs 评论1）
- 技术团队是否应承担业务失败责任（评论10 vs 评论13）
- 产品开发方法论的有效性（评论2 vs 评论5）

中立总结：
评论普遍关注责任归属的实践困境，支持明确问责但质疑执行难度；同时反映技术与管理层的目标冲突，部分人主张通过流程（如Scrum）划清责任边界。对行业现状的批评集中于决策缺乏商业逻辑或技术理解。