敏捷开发
我：所以在讲敏捷开发课程时，我都会从2000年的谷歌案例开始讲，虽然当时谷歌公司还在起步阶段，但已具备前面提到的关键要素，加上公司招聘新人要求非常高，所以当年的谷歌人都是很有能力的A级球员。
顾问：我接触客户，尤其是做产品的，越来越多用敏捷或者迭代的方式快速交付，我做咨询本来想从一些标准的模型或者方法去辅导他们，因为我觉得他们很多时候都没有用好迭代或敏捷来改善开发工作，没有获得本应的效果。
我：你参考过哪些模型、方法？
顾问：SCRUM、极限编程（XP）和SAFe。
我：你有没有发现你刚才说的几个方式都有一个共同点，就是都偏技术。例如SCRUM主要偏重项目管理，因为创始人之一Ken Schwaber是飞行员，因先做好项目管理让团队更容易取得效果，SCRUM主要关注项目管理，他常用如何把飞机安全起飞下降控制好来比喻如何管理项目。
极限编程XP是Kent Beck提出来的，他本身是一位很优秀的Smalltalk程序员，很熟悉面向对象开发，所以他的极限编程偏向于开发技术方面。XP源自他1996年开始的C3项目咨询经验。美国佳是拿（Chrysler）汽车公司从1994年开始开发新系统，内部简称C3项目，替代基于Cobol编写的旧的付薪水系统，目标到1999年能处理公司8.7万员工的薪水发放。1994年开始用Smalltalk开发，但一直进展缓慢，1996年Kent Beck作为顾问加入，引进了多种软件开发实践，开发速度立马提升，并估计能在12个月后发布第一版，最后只是延迟了几个月，1997年上线时能支持大约一万员工的薪水发放，它基于这个成功项目总结成XP，并在其他项目中使用。
所以你参考的敏捷模型和实践，都是偏于技术方面的，但我们前面讨论过，技术只是影响改进的其中一个元素，如果没有考虑人的因素、动力、奖罚等，还是难以取得效果的。
顾问：赞同。
我：如果我们问有经验的研发主管"要做好软件开发项目，最大的困难是什么？"，以我的经验，超过八成研发主管都会说是需求。但如果我们仔细看你刚才说的那些模型或实践，只是强调要跟客户代表或者产品经理一起面对面沟通，按产品经理的思路开发出有价值的产品。但如果产品经理本身就不清楚产品的重点价值，就难以做出优秀的产品。所以，当我给客户培训需求时，会强调不仅仅是听客户说要做什么功能，更应该把自己定位成业务分析师，从业务的角度最终希望产生什么价值，从业务的角度出发来制定产品应该开发哪些重要功能。也可以用上面提过的方式，指导客户做工作坊，让所有利益相关人一起参与设计。现在大部分的项目都会利用原型图，与客户确认沟通。但很多团队还没有把那些原型图配合场景（场景就是什么人完成什么任务），以方便客户或用户更容易理解。上面说到很多产品团队，他们开发了新版本产品后，只有简单做了内部验收，也没有立马发给客户使用，导致缺陷在客户使用时才暴露。
SAFe把前面SCRUM、XP都加进来，在上面添加了价值流、精益等思想，作为一个框架，希望帮企业利用敏捷从团队扩大到企业使用。但这些偏技术的模型、最佳实践或框架能打动管理者吗？很难。不少高层是不懂软件开发的，他们心想："这些偏技术的，我听不懂。"比如SAFe框架列举出很多敏捷开发的规定或最佳实践，理论上可以指导小团队发展到企业。SAFe 4.0版本把能接触到的团队的最佳实践都放在里面，portfolio、programme等各个层次，非常全面。但是看完以后，我想到一个问题：企业家怎么使用它呢？
除了利用这些技术框架、最佳实践以外，加上简单管理学的组织架构，加强内部竞争，分割成独立的单元，自主盈亏等，对管理层才更有说服力。如果只讲技术不讲管理，企业内部员工还是没有动力，也做不出什么改进。
所以若要帮助团队更好地用上敏捷开发，还是应先考虑前面讨论过的3点：
- 不仅需要考虑产品质量，还要全面考虑整个系统，包括人
- 除了关注外部客户，也要考虑内部
- 全面考虑需求，不仅仅是产品功能
总结
各位读者，让我们一起利用下列简化图，回顾上面对话覆盖的范围，取得更全的视角：
图B1-6
0 避免裁员（人员能力与动力）
1 需要加入内部竞争（报酬）
2 利用管理工具监控项目的成本与进度偏差（工具）
3 把单元分成利润中心或成本中心（组织结构）
4 亚马逊创始人提倡小团队，减少沟通（部门间的协调、上下级的集成），以便公司能快速发展（组织结构）
5 公司架构都可以分成输入、输出和市场三类单元（结构），并归属到利润中心或成本中心
6 这种多维架构让企业可以快速调配部门的资源分配，适应市场变化（结构）
7 每个层级的部门都可以组成改进小组（人员能力与动力）
7.1 逐步形成每位员工都可以提出改进意见的循环环境
7.2 举办2天工作坊加快各事业部开展改进小组试点
8 配合内部Wiki平台，帮助团队持续学习（团队学习）
9 过程改进的常见问题
9.1 未充分考虑与人相关的因素（报酬、组织结构、动力）
9.2 未充分考虑内部客户（产品、服务）
9.3 误解客户需求（产品、服务）
9.4 最后讨论3个常用敏捷开发实践，它们主要覆盖产品、服务
从这个简化图看到，虽然产品、服务很重要，但不是全部，其他的地方出现问题都会产生影响。如果我们使用系统思维把范围扩大，才能更全面看到问题所在和之间的相互影响：
图B1-7
大部分软件开发的模型、最佳实践等，如SCRUM、XP都是偏技术方面的，只覆盖图中的"产品、服务"部分，虽然很重要，但如果周围的系统不配合，也难以取得改进效果。
如果咨询顾问只关注软件开发技术问题，很可能只能在短期内做出效果，难以持久。但如果能扩大范围更全面分析企业的问题，才有机会引起高层的关注，团队和企业的改进才有机会延续。
从另一个角度来看，系统思维能扩大咨询顾问的视野，帮助他更全面地预估能帮助公司持续改进的机会有多大。
后记
从2014年开始做敏捷开发ACP培训，我便引用埃里克·施密特（Eric Schmidt）当年出版的 How Google Works（《谷歌是如何运营的》）里的故事。
当我写完这篇初稿，便想起那些谷歌故事，再次翻开书的目录，发现从第一章到第六章几乎都可以落到图B1-7中，而且大部分是围绕"产品、服务"。
例如第一章讲文化层面：
- 7的法则，不要自扫门前雪，"2个比萨"原则，重组是关键等，都与组织结构相关。
- 别听"河马"的话，驱逐恶棍，保护明星，跟我来，以领袖人物为中心，不能作恶等，都与人相关
整个第三章"人才"，从招聘、宁缺毋滥、报酬等都是关于人的。
第四章"决策"和第六章"创新的故事"，除了落在"产品、服务"以外，也覆盖到目的，工具和人的地方列举了部分故事，如下图：
图B1-8
2001年，埃里克·施密特开始就任谷歌首席执行官。他从1983年开始在太阳公司工作，到1997年当Novell公司的首席执行官，18年里的大部分时间都是管理者，所以他很清楚应该关注哪些重点。
谷歌从2000年时的一家几百人的新创公司，凭着巨大创新能力，已经成为当今互联网世界级超大公司。所以公司若要提高创新能力，也必须注意这些地方。
虽然Kent Beck大师1996---1997年使用XP实践帮助开发团队在一年多时间内完成了第一版发布，但随着他完成了接近2年的咨询工作，离开了项目，后面系统的扩大便停滞不前，最终在2000年时C3项目正式被取消。