ACP(Agile Certified Practitioner)是美国项目管理协会（Project Management Institute）的敏捷证书，在大陆也流行，与其他认证不一样的地方是ACP并不针对某一种敏捷方法，它更注重的是敏捷背后的核心思路如何应用于项目管理中。
ACP没有官方培训课，只有框架与最佳实践，并提供参考书单。
我有幸在香港讲过6次，每次3天ACP课程，这让我更明白敏捷的重点并非大家都听过的技巧（如看板，每天站会等），而是背后的思路。这篇先讲两个故事来说明。

• == == ==

培训一开始，我把3 天的范围、敏捷的主要概念讲完后，立即在白板左右两面写上一些数据，并问学员：“大家猜一下，下面两家都是美国西岸的公司分别是什么公司？”

他们立即猜到左面是 YAHOO!， 右面是Google。
2000 年，谷歌还是小公司，雅虎是已经是大规模的上市公司，但现在大部分人只认识谷歌，原因是雅虎已经在2017 年被收购 （虽然品牌还在），但反过来，谷歌公司从本来 2000 年的一家小公司，变成目前全球IT 界举足轻重的超级大公司。
他们两家公司有什么区分呢？为什么是这样的结果呢？

Eric SCHMIDT先生，在2002 年加入了谷歌当CEO，他本来是NOVELL 的CEO。第一天进办公室的时候，他就发现这里的风格跟其他东岸的公司完全不一样：例如他的办公室不大。过了一两天以后，竟然有个工程师走过来说：“我们那边太挤了，我看你那边还是挺宽松，我可否搬到你这边来？”
“为什么一个工程师还可以进CEO 的办公室占位置？”

Eric 虽然心里觉得很奇怪,但新来公司，不熟悉谷歌的文化，他便回答：好的，欢迎，没问题。

Eric 开始了解到谷歌公司的文化不同于一般公司：阶层关系不强。

谷歌是由两位斯坦福的研究生，Larry PAGE 与 Sergey所创立，可能大家都知道，它是以搜索引擎起家的，虽然小但技术很厉害。所以开始被当时的巨无霸，微软当做收购目标——微软擅长用各种手段打击竞争对手，以垄断市场。
董事会的Mike 就发邮件提醒Eric要准备应对微软的策略（微软会对有威胁的新公司极力打击）。
Eric 进了公司后不久，创始人Larry Page 也聘用了另外一位很资深的管理者Jonathan，所以Jonathan 和Eric 就承担起了这个任务，要做应对微软的计划书，他们都是职场老手，商业经验丰富，他们就用传统方式做了一份详细的业务计划书，计划在未来两年时间如何部署、准备。计划书很详细，有很多数字支撑。

Jonathan 很有经验，觉得这个计划挺完备，就拿给创始人Larry 看，Eric 也在场。
Larry 看了几分钟后就问Jonathan：以前试过你们的团队超越了你的计划吗？
Larry 看Jonathan 和Eric 好像不太理解，继续说：你见过哪个团队的表现能超越既定目标？你的团队研发过比计划中更出色的产品吗？
Jonathan 和 Eric 都无法回答。
Larry 说：如果是这样，计划还有什么意义？
最后Larry 说一定还有比计划更有效的方式，于是让他们去和工程师谈谈。后来，Jonathan 和Eric发现Google 公司的工程师都是既有技术能力，也很有商业头脑的创意精英 (Smart Creative)，不需要用硬性的计划来推动。计划反而会妨碍他们的创意。
这个故事让学员们知道，要让“敏捷”有效就必须具备一些基本条件：团队本身能力很强，有动力。所以敏捷不是一根万应万灵的魔术棒，不是照着去做便会成功。

比如在Google 的一些内部讨论中，做决定不只是依据提出者在公司的地位、权力而论的，如果一些由高管提出的意见存在不足之处，同样可以被工程师推翻 ，Google 叫这些横行的管理者为河马(HiPPO : Highest-Paid Person's Opinion) ， 下午做活动练习时，不少组员就提到在自己的公司确实有不少“河马”在横行。

反过来， YAHOO 上市后 便有了各样的 “大公司”病 —— 官僚化的管理，导致最终被收购。

美国费城 Weisbord 故事

X-Y理论能加深我们对敏捷开发原则的理解，每当一些敏捷ACP 班的学员质疑，敏捷开发是否确实能提升团队的生产率时，我就会用以下故事，让他们感受如何让团队自主管理的过程：20世纪60 年代, 复印机还未普及，很昂贵，所以为各类公司客户提供印刷服务就有市场， 这个故事的主人翁是某美国东岸一家印刷公司老板的儿子Weisbord。他一直都没有接受什么正式的管理培训。他有一个好朋友 Don 在国际大公司已工作了20 年， Don 推荐Weisbord说：“很多大公司已经开始推进团队自主管理，提升生产率, 你可以先读 X-Y 理论（McGregor ‘Human side of Enterprise’）一书。”

X 理论：

Y 理论：

Weisbord 本来只想看看有多厉害，但他结果一口气一周末读完全书。他发现自己公司到处都是X 理论管理：

• 工作分得很细，每员工不清楚全局

• 任务都是依赖主管分配

• 员工遇到问题、困难，交给主管处理

• 员工上下班打卡

他觉得这方式应该可以帮公司提升，但他担心单靠自己推动不了这个改革， 他便请Don过来正式加入公司。

他们分析公司业务最大问题是订单处理部门(Order Processing)， 每个订单处理工作分到五、六个任务，员工只管被分配的任务，例如:

• 筛选客户邮寄地址，邮寄印刷样本

• 输入订单

• 检查客户的信用

• 发起内部生产订单

• 用打字机打发票邮寄出去

• 收到的支票，对上那些应付账

公司平均每天要处理200 到300 个订单， 但因为工作分得很细，如果某个任务（如输入订单）有一、两人缺席， 便严重影响整个流程，效率会降低一半。

针对这问题，Weisbord 计划改革，把这部门的人分成多个4-5 人的团队， 把公司的两万个客户按地区分到各团队，每个团队有自己的客户名单，打字机等设备， 希望以此增加部门的灵活度，并提高生产率。

Weisbord 与5 位小主管(supervisor)商量，2 位很赞成，2 位中立，其他1 位觉得不会成功。Weisbord 决策启动这改革，与Don 开始重组部门。

开始团队制

开始时问题非常多：

• B 物流公司运送出错，送到另一个城市，怎么办？

• D 团队误解了生产的步骤，怎么办？

• C 团队的样板工人，刚入职3 周，对我们公司产品线不熟识，怎么办？

原因很简单：本来每个人以前都只懂自己的一小块工作，以前问题都是由小主管处理。现在自主团队没有主管，都要靠团队自己想办法，像瞎子摸象。

但问题确实太多了，没办法，Don 建议每周开会讨论。他们从未有每周开会的习惯，Weisbord 本来以为开会浪费时间，把时间用于生产更实际。问题一直都非常多，延续了一个月。

Weisbord 开始怀疑这X-Y 理论，只是大学象牙塔里的玩意，难以真正用于实际公司环境。Don 也没有更好的建议。
Weisbord 开始有撤销整个改革的想法，返回本来的组织架构， Don 还希望Weisbord 稍等一两周，看看有没有好转。但Weisbord 觉得一直这么多问题，严重影响公司运作，也难以与父亲交代，想在下次开会时向大家宣布变回本来架构。
到了第五周开会：
Weisbord，与以前开会一样，先问: 大家有什么问题？
沉默，几分钟后，某组长说：没有问题。
Weisbord: 为什么会没有？一直这么多问题（心里想，一定是你们也放弃了，连问题都不愿提了。）
另一组长回答：我们今周没有什么问题，遇到的问题都在以前的会议里面被解决了。

效果

改革的结果是从原来每天低于300 个订单提升到了400个。员工的出勤率也得到了改善，缺席率降低到接近零。

改革后的订单处理部平面图：

（团队自主改革前，小主管们为了减少各功能之间在处理订单引起的争吵，特意在中间加了一道墙；后面团队们一致建议把墙拆掉。）

Weisbord 事后回顾：所有改变，重组都需要时间磨合，过程中管理者的支持非常重要，如果管理者不能坚持，面对并解决面对的困难，便会以失败告终。

Google 与 Weisbord 故事的启发

如果员工具备知识技能，管理者便应尽力给员工平台，让团队自主发挥，才能应对变化万千的市场需要，让员工与公司都受益；管理者不仅仅是制定目标、计划，发号施令的角色，而更应该是一位导师，辅助团队成长。
下一篇会探索如何参考过去150年针对提升工人生产率，工作环境的研究与实验，让软件开发团队可以改善质量，提高效率。

References

1. Schmidt, E. & Rosenberg, J.: How Google Works, 2014.
2. McGregor, D.: The Human Side of Enterprise,1960.
3. Weisbord, M.R.: Productive workplaces revisited : dignity, meaning, and community in the 21st century, 2004.