为什么敏捷团队提倡职责共享而不担心公地悲剧?
公地悲剧,很多人都知道的一个理论,这个词有近200年的历史了。1833年英国经济学家威廉 · 劳埃德(William Lloyd)提出了这个概念,但不是很流行。1968年,生态学家格雷特 · 哈定(Garrett Hardin),在《科学》杂志上发表了一篇叫《公地的悲剧》的论文,它才流行起来。简单点说,如果一块公共资源由大家来共同使用或者维护,最终这块资源就会因为没有人负责而被耗尽。
牧草是公有的,最后被不同家的牛全部吃掉,牧场被破坏在实施敏捷时,我们着重强调职责共享(Shared Responsibility)和自组织(Self Orgnised)团队,这会引发在转型过程中经常被客户问到的两个问题:其一、所有人都负责,最终是不是就没有人管了?其二、为什么职责共享更有价值?也许你已经有答案了,但不妨从经济学视角再分析一下这两个问题,看看背后的逻辑,也许会有新的收获。我尝试用如下六个步骤分析:
- 从公地悲剧的经济学理模型理解对职责共享的担忧
- 传统解决方案其合理性与带来的问题
- 公地一定会悲剧吗?
- 重识推动职责共享之举措
- 从科斯定律再谈职责共享的价值
- 职责共享的经济学本质
一、从公地悲剧的经济学模型理解对职责共享的担忧
第一个问题,换个问法就是开篇的问题。经济学上有三种模型来刻画公地悲剧这种现象,无一例外推导的结果是,当每个人都在追求个人利益时,公众的利益受到了很大损害,而且这种损害是难以避免的,甚至呈恶化趋势。
简单回顾一下这三个模型,以便对公地悲剧的理解更加深入。
- 公地悲剧理论本身:全员所有制,人人都能够使用资源,人人都能够占有资源,最终资源被耗尽,公众利益受损;
- 囚徒困境:A,B两个囚犯选择最大化自己利益,结果两个人都被供出来了,最后法庭判他们两个人都要入狱三个月,这个结局当然远远不及两个人都保持沉默带来的整体利益最大化;
- 集体行动的逻辑:由著名的经济学家曼瑟·奥尔森在1965年出版的名著《The Logic of Collective Action 》中提出来,其结论也是,一群人一起追求一个共同的目标,大家都应该出力,但是当中要是有谁偷懒,在整体的效果上暂时看不出什么损耗,但是整体利益会受损,最后导致没有人愿意贡献。
回到敏捷转型中,在传统团队推行代码职责共享,PM常见的担忧是,如果代码职责共享,每个人都能修改产品里面每一行代码,随时能够提交,那谁去保证代码的质量?特别是团队内部有些人的代码能力很差,每个人都将代码直接提交到代码仓库可怎么得了?!当提及任务卡自组织分配,PM的担忧是,如果一个人拿到的卡片做完了,会不会磨洋工,不着急拿新的任务卡?这样的担心不无道理,跟以上三个模型的预期一致。
二、传统解决方案其合理性与带来的问题
所以,为了避免因为职责不分明带来的公众利益损害,在传统软件项目管理中,常见有如下应对之策:
- 提前划定责任:经济学意义上叫“明确和稳定产权”,比如,在迭代计划会议中将所有本迭代要做的卡片全都分配上具体的人,无论是开发还是测试。产品代码会划定不同模块的负责人,或者由Tech Lead统一负责,有任何其他人想修改或者提交代码,必须通过负责人的评审,然后才能提交。这样,无论是任务,还是代码,每个人都有了一片或者几片责任田。
- 加强制度建设,重监管:在团队内部会针对所有事务建立制度,比如在站会的时候PM会具体询问卡片的进度以及昨天的工作内容;代码审查时,重点不在代码质量,而是检查有没有按照规则修改特定代码。传统团队会设置PM角色,其重点是监管,Tech Lead的工作重点也是从技术上保证团队成员符合规则。
这里面有什么问题吗?我想大家都会得到的一个结论,那就是团队整体响应力降低了,具体点说是有碍于提升整个产品的交付效率以及质量。谈了这么多,你会发现整个分析貌似进入了死胡同,而且有悖于我司过去推崇的工作方式。不要着急,马上峰回路转。
三、公地一定会悲剧吗?
如果我这么问,你一定知道答案是“否”。一起来看看对公地悲剧这个理论发起挑战的是谁?那就是2009年获得诺贝尔经济学奖的埃莉诺·奥斯特罗姆(Elinor Ostrom),一位女经济学家,而且是跟她老公一起致力于研究这个课题。
奥斯特罗姆夫妇花了很长时间持续地做workshop,请世界各地的人来给他们讲故事,讲那些公共资源实际上是怎么样避免公地的悲剧的。他们的成果对我们有哪些启示呢?
- 人不仅仅是追求利益最大化的动物,而且他们也会追求损失最小化:人们见到某个共享资源的价值在耗散的时候,就会想办法组织起来形成一些规则,阻止这些资源的价值进一步耗散。(可以参考著名经济学家张五常非常重要的论文《一种价格管制理论》,1974)
- 保证公平与透明有利于形成协作:当一个群体内部对于资源的使用能够保证透明而且公平的时候,也不会导致公地悲剧。比如奥斯特罗姆夫妇考察了日本的农民组织,农地是公共资源,大家都可以耕作,但是它里面有非常明确的规矩。所有的资产都是由几个家庭组成的组为单位,而不是以家庭为基本的单位。到收割的时候每家派一个人,一字排开,以相同的节奏挥舞镰刀收割,收割完了以后庄稼捆成一捆一捆的,大小都一样,最后每家人抽签决定谁拿哪一捆,这样运作得很好!
- 保持群体持续接触有利于形成合作:如以上的例子所示,农民组织这个群体,世世代代都生活在一个村庄,低头不见抬头见,持续接触,也有利于形成协作。
谈了这么多,详细分析一下以上对于推进职责共享的具体举措有何启示。
四、重识推动职责共享之举措
从以上三个角度重新审视一下如何推进职责共享,反观跟我们经常采用策略的关系。
-
群体也会追求损失最小化
如何能够更好地让大家追求损失最小化,从而促进职责共享?以代码职责共享为例,其首要目标是暴露群体的损失,比如随着时间流逝,代码质量变差带来的开发效率低下,每个人的工作负担变重,具体措施有:
- 通过代码扫描工具暴露技术债
- 统计用户故事、Bug平均修复时间
- 统计上线后的bug数
- 统计团队成员加班的时间
- 及时可视化以上各种问题恶化的趋势
随着给群体带来的损失越来越大,他们就会自发地想办法如何降低每个人因为工作时间延长,压力变大带来的损失,从而纠正个人利益最大化对群体利益的伤害。
-
保证公平与透明
先谈谈透明,毋庸多言,可视化是我司常用的利器。其出发点在于正向激励,比如用户故事墙,看板,让所有人当前的工作状态可见。从代码角度,可以可视化每个人每天提交的次数以及Fail Build的次数。这些举措都有利于大家形成良好的协作,从而避免是磨洋工。
如何保证公平?轮流承担职责,比如各种活动的Facilitator,回顾会、知识分享会、甚至是团队订餐等。关键在于,在团队内部不能有人凌驾于此规则之上。事实上,对于传统PM来说是一个挑战,如何转变心态,更好地融入团队并贡献到产品交付上去?
-
持续反复接触
这一点,对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继续深化和强调合作的价值,从系统思考的角度形成了正反馈循环,价值继续最大化。这也就是为什么在转型过程中不断提及打造生机型文化的价值,因为它强调的就是高度合作、风险共担、鼓励联结、容忍犯错。
网友评论