公地悲剧、科斯定律与敏捷团队职责共享

为什么敏捷团队提倡职责共享而不担心公地悲剧？

公地悲剧，很多人都知道的一个理论，这个词有近200年的历史了。1833年英国经济学家威廉 · 劳埃德（William Lloyd）提出了这个概念，但不是很流行。1968年，生态学家格雷特 · 哈定（Garrett Hardin），在《科学》杂志上发表了一篇叫《公地的悲剧》的论文，它才流行起来。简单点说，如果一块公共资源由大家来共同使用或者维护，最终这块资源就会因为没有人负责而被耗尽。

牧草是公有的，最后被不同家的牛全部吃掉，牧场被破坏

在实施敏捷时，我们着重强调职责共享（Shared Responsibility）和自组织（Self Orgnised）团队，这会引发在转型过程中经常被客户问到的两个问题：其一、所有人都负责，最终是不是就没有人管了？其二、为什么职责共享更有价值？也许你已经有答案了，但不妨从经济学视角再分析一下这两个问题，看看背后的逻辑，也许会有新的收获。我尝试用如下六个步骤分析：

1. 从公地悲剧的经济学理模型理解对职责共享的担忧
2. 传统解决方案其合理性与带来的问题
3. 公地一定会悲剧吗？
4. 重识推动职责共享之举措
5. 从科斯定律再谈职责共享的价值
6. 职责共享的经济学本质

一、从公地悲剧的经济学模型理解对职责共享的担忧

第一个问题，换个问法就是开篇的问题。经济学上有三种模型来刻画公地悲剧这种现象，无一例外推导的结果是，当每个人都在追求个人利益时，公众的利益受到了很大损害，而且这种损害是难以避免的，甚至呈恶化趋势。

简单回顾一下这三个模型，以便对公地悲剧的理解更加深入。

1. 公地悲剧理论本身：全员所有制，人人都能够使用资源，人人都能够占有资源，最终资源被耗尽，公众利益受损；
2. 囚徒困境：A，B两个囚犯选择最大化自己利益，结果两个人都被供出来了，最后法庭判他们两个人都要入狱三个月，这个结局当然远远不及两个人都保持沉默带来的整体利益最大化；
3. 集体行动的逻辑：由著名的经济学家曼瑟·奥尔森在1965年出版的名著《The Logic of Collective Action 》中提出来，其结论也是，一群人一起追求一个共同的目标，大家都应该出力，但是当中要是有谁偷懒，在整体的效果上暂时看不出什么损耗，但是整体利益会受损，最后导致没有人愿意贡献。

回到敏捷转型中，在传统团队推行代码职责共享，PM常见的担忧是，如果代码职责共享，每个人都能修改产品里面每一行代码，随时能够提交，那谁去保证代码的质量？特别是团队内部有些人的代码能力很差，每个人都将代码直接提交到代码仓库可怎么得了？！当提及任务卡自组织分配，PM的担忧是，如果一个人拿到的卡片做完了，会不会磨洋工，不着急拿新的任务卡？这样的担心不无道理，跟以上三个模型的预期一致。

二、传统解决方案其合理性与带来的问题

所以，为了避免因为职责不分明带来的公众利益损害，在传统软件项目管理中，常见有如下应对之策：

1. 提前划定责任：经济学意义上叫“明确和稳定产权”，比如，在迭代计划会议中将所有本迭代要做的卡片全都分配上具体的人，无论是开发还是测试。产品代码会划定不同模块的负责人，或者由Tech Lead统一负责，有任何其他人想修改或者提交代码，必须通过负责人的评审，然后才能提交。这样，无论是任务，还是代码，每个人都有了一片或者几片责任田。
2. 加强制度建设，重监管：在团队内部会针对所有事务建立制度，比如在站会的时候PM会具体询问卡片的进度以及昨天的工作内容；代码审查时，重点不在代码质量，而是检查有没有按照规则修改特定代码。传统团队会设置PM角色，其重点是监管，Tech Lead的工作重点也是从技术上保证团队成员符合规则。

这里面有什么问题吗？我想大家都会得到的一个结论，那就是团队整体响应力降低了，具体点说是有碍于提升整个产品的交付效率以及质量。谈了这么多，你会发现整个分析貌似进入了死胡同，而且有悖于我司过去推崇的工作方式。不要着急，马上峰回路转。

三、公地一定会悲剧吗？

如果我这么问，你一定知道答案是“否”。一起来看看对公地悲剧这个理论发起挑战的是谁？那就是2009年获得诺贝尔经济学奖的埃莉诺·奥斯特罗姆（Elinor Ostrom），一位女经济学家，而且是跟她老公一起致力于研究这个课题。

奥斯特罗姆夫妇花了很长时间持续地做workshop，请世界各地的人来给他们讲故事，讲那些公共资源实际上是怎么样避免公地的悲剧的。他们的成果对我们有哪些启示呢？

1. 人不仅仅是追求利益最大化的动物，而且他们也会追求损失最小化：人们见到某个共享资源的价值在耗散的时候，就会想办法组织起来形成一些规则，阻止这些资源的价值进一步耗散。（可以参考著名经济学家张五常非常重要的论文《一种价格管制理论》，1974）
2. 保证公平与透明有利于形成协作：当一个群体内部对于资源的使用能够保证透明而且公平的时候，也不会导致公地悲剧。比如奥斯特罗姆夫妇考察了日本的农民组织，农地是公共资源，大家都可以耕作，但是它里面有非常明确的规矩。所有的资产都是由几个家庭组成的组为单位，而不是以家庭为基本的单位。到收割的时候每家派一个人，一字排开，以相同的节奏挥舞镰刀收割，收割完了以后庄稼捆成一捆一捆的，大小都一样，最后每家人抽签决定谁拿哪一捆，这样运作得很好！
3. 保持群体持续接触有利于形成合作：如以上的例子所示，农民组织这个群体，世世代代都生活在一个村庄，低头不见抬头见，持续接触，也有利于形成协作。

谈了这么多，详细分析一下以上对于推进职责共享的具体举措有何启示。

四、重识推动职责共享之举措

从以上三个角度重新审视一下如何推进职责共享，反观跟我们经常采用策略的关系。

1. 群体也会追求损失最小化
   如何能够更好地让大家追求损失最小化，从而促进职责共享？以代码职责共享为例，其首要目标是暴露群体的损失，比如随着时间流逝，代码质量变差带来的开发效率低下，每个人的工作负担变重，具体措施有：

• 通过代码扫描工具暴露技术债
• 统计用户故事、Bug平均修复时间
• 统计上线后的bug数
• 统计团队成员加班的时间
• 及时可视化以上各种问题恶化的趋势

随着给群体带来的损失越来越大，他们就会自发地想办法如何降低每个人因为工作时间延长，压力变大带来的损失，从而纠正个人利益最大化对群体利益的伤害。

2. 保证公平与透明
   先谈谈透明，毋庸多言，可视化是我司常用的利器。其出发点在于正向激励，比如用户故事墙，看板，让所有人当前的工作状态可见。从代码角度，可以可视化每个人每天提交的次数以及Fail Build的次数。这些举措都有利于大家形成良好的协作，从而避免是磨洋工。

如何保证公平？轮流承担职责，比如各种活动的Facilitator，回顾会、知识分享会、甚至是团队订餐等。关键在于，在团队内部不能有人凌驾于此规则之上。事实上，对于传统PM来说是一个挑战，如何转变心态，更好地融入团队并贡献到产品交付上去？

3. 持续反复接触
   这一点，对TW来说这不是一个大问题。但在很多大型企业，常常是一个团队内部有多家外部供应商参与，他们跟甲方的合作时间一般只有几个月，项目结束就离开。我遇到的一个极端情况是，某家企业1个内部员工会带领15到20个外部员工，而且还是来自于两家不同的供应商，这就是很大的挑战。所以，在推行敏捷转型之初选择试点团队时，请重点选择比较稳定的团队。在转型过程中也会推行以产品为中心交付的稳定团队构建。

不得不说，世界上的很多理论都是相通的。以上观点在美国科学院院士，著名的行为分析及博弈论专家罗伯特·艾克斯罗德（Robert Axelrod）1984年出版的《合作的进化》一书中进行了深入讨论。他通过计算机模拟重复囚徒困境，给出了如何在没有协作的群体里面建立协作的答案，其中一条就是“持续相遇: 不是一锤子买卖”，这里不做深究，感兴趣的读者可以阅读此书。

切记！从零开始在一个传统团队推行职责共享，如果以上方式要见效，有一个非常重要前提 —— 允许团队犯错且从错误中自我纠正！可是，这恰恰是大多数企业难以接受的。此时，一个有经验的顾问就可以减轻管理者的压力，让团队有更多的时间和空间尝试。

基于以上分析我们回答了开篇第一个问题，职责共享为什么能够工作？但是第二个问题还没有回答，那就是职责共享带来的价值是什么？

五、从科斯定律再谈职责共享的价值

此刻，也许你心中已经有100条价值，比如可以更好地促进团队互信、提升团队学习兴趣、最大化团队产出、团队健壮性更好，诸如此类的。然而，从经济学上看这个问题，别有一番意味。

诺贝尔经济学奖得主，著名经济学家罗纳德·科斯（Ronald Coase）提出一种观点，“只要财产权是明确的，并且交易成本为零或者很小，那么，无论在开始时将财产权赋予谁，市场均衡的最终结果是实现资源配置的帕累托最优”。

image source:The University of Chicago, 科斯1991年被授予诺贝尔经济学奖

这个理论有很多衍生含义，最著名的一条就是“资源，谁用得好就归谁”，也就是说一项有价值的资源，不管从一开始它的产权谁属，最后这项资源都会流动到最善于利用它、能最大化利用其价值的人手里去。 举个例子说明一下， 中国式过马路。如果完全遵照交通灯来过马路，其实有很大的损失。因为有时候车多，有时候人多，交通灯的时间是固定的，这当中就有很大的时间浪费。中国式过马路的核心是凑一堆人，当觉得差不多了，大家一起浩浩荡荡地过马路，这时候就是人群应该获得路权的时候，道路这个公共资源得到了价值最大化。

回到职责共享，如果以代码为例。根据科斯定律，“谁用得好就归谁”，既有代码就是开发人员在开发新需求时所需的资源。如果按照传统的解决方案，开发人员A是不能随意修改由B负责的代码模块的。比如，十年前我在Motorola实习，我要提交代码前，必须要经过另外两位资深Dev审核后才能提交到代码库，因为他们是代码的owner。不仅仅是我，团队内部还有另外两个开发人员相互持有对方需要修改的代码块。最终，我想大家也猜得到，这种审核就变成了一种形式。谁要是发起审核，在IM里面说一声，另外一个人就在工具上直接通过审核了。 因为，旧的做法显然整体上资源没有得到最大化的利用的。作为开发人员，只有基于他们管理的代码添加新代码，新产品功能才能实现，才能产生价值，团队的压力才能减少。

绕了一大圈，总结一下。根据科斯定律，资源谁用得好就应该谁用，而且会带来整体价值的最大化。但是有一个前提，那就是交易成本最小。如果团队内部设置很多规则，比如必须通过至少2个Dev的Code review才能提交代码，这样的交易成本就很高。当我们提倡职责共享时，其本质上是降低资源的交易成本，实现公共资源的最优配置，从而带来整体利益最大化。从代码共享这个角度，就是让整个代码在不同的Dev之间快速添加，修改或者删除，从而更好地实现产品需求，提升软件质量与交付效率，实现整体价值最大化。

六、职责共享的经济学本质

职责共享，讨论的是代码或者任务卡是由一个人负责，还是团队全部成员共同负责。从经济学意义上来讲，其本质是一个所有制问题。在经济学上有四种典型的所有制：集体所有制、全员所有制、私有制和政府所有制。

职责共享，是从私有制转换为集体所有制。私有制的特点是便于激发个人动力，责任清晰，便于管理，而且所有者更加关注长期收益；集体所有制，会带来很多挑战，特别是成员普遍缺乏对资源长远收益的关心。但是集体所有制，规则清晰，容易操作，而且在人类历史上存在了非常久的时间。更重要的是，它在刚开始的时候，因为以上提到的举措让成员之间的协作更加紧密，边际收益递增。从软件开发来说，使得开发效率以及产品质量可以得到有效提升，合作共赢，也就是创造了合作的进化基础。而且在操作过程中，因为团队内部的资深人员，Scrum Master继续深化和强调合作的价值，从系统思考的角度形成了正反馈循环，价值继续最大化。这也就是为什么在转型过程中不断提及打造生机型文化的价值，因为它强调的就是高度合作、风险共担、鼓励联结、容忍犯错。