【视频】由接力赛跑学习组织管理

一直以来大家都关注于生产力(productivity),但由于过往对于效率的基本认识,导致组织或管理的效率上的努力适得其反。被视为经典的效率三位一体(trinity)指的是:清晰(Clarity),度量(Measurement)和问责(Accountability),恰恰是它们使人们的努力白费。 我们可以通过接力赛跑来看待以及证明这个观点。世界杯女子接力赛决赛一共有8支队伍。最快的是美国队,美国拥有全世界最快的女运动员,是夺冠热门。如何拿她们和其他队伍比较,比如法国队。 按照她们在100米短跑当中的最佳成绩,把美国选手个人的成绩相加起来,最后她们会在达终点线时比法国队领先3.2米。今年,美国队状态很好。根据她们今年的最好成绩,她们在到达终点时应该要领先法国队6.4米,这是根据数据推算的。美国队第四棒Torri Edwards今年在100米赛跑中获得了金牌。美国队第二棒Chryste Gaines是地球上跑得最快的女性。显然,美国队赢得了人才争夺战。不过在其背后,普通的队伍也在奋力追赶。 视频里发生了什么?最快的队伍没有赢,慢的那一队反而赢了。 为什么呢? 因为合作。你可能听过这句话:“多亏了合作,整体大于部分之和。”这不是诗歌,这不是哲学,这是数学。握着接力棒的人跑得慢了点,但她们交接棒更快。合作的奇迹能让人们努力的能量和智慧加倍。这是人们努力的精髓:我们如何合作,个人的成果如何为团队做贡献。通过合作,我们可以事半功倍。 那么,当圣神三位一体(清晰、衡量、问责)出现时,会对合作产生什么影响? 清晰 管理报告充满了对缺乏清晰度的抱怨。 合规性审核、咨询诊断。我们需要更高的清晰度,我们要明确角色和流程。就好比说队伍里的选手说,“我们明确下吧:我从哪里跑到哪里?我要跑95米,还是96、97米...?”这很重要,我们要分清楚。如果你说97米的话,那么跑完97米,人们就会把交接棒丢掉,可不管到时候有没有人接。 想想软件开发过程中,我们也经常听到类似的,“我是做开发的,测试我不管”,“这是后端处理的,等他们做好了再说”,“现在是运维的事情了”。我们对软件开发过程中的各种行为进行了分类,并指定一个角色。整个开发过程要有清晰的阶段,角色的职责边界也要十分清晰。那么,不清晰可以有什么选择?比较常见的情况是我们按照职能,开发流程,系统组件来划分角色职责,比如开发可不可以做些测试,和测试人员一起协作共同为质量负责,前端开发和后端开发互相协作共同为交付功能负责。模糊掉组件间、职能间的边界,把他们都放入一个团队共同为交付特性负责,形成特性团队。 问责 我们总是试图把责任规定给某个人。谁对这个过程负责?我们需要一个人对这个过程负责。所以在接力赛中,既然交接棒如此之重要,那么我们需要非常明确负责交接棒的人是谁。在两个选手中间,我们现在要规定一个新的专门的运动员,这个运动员要非常明确地专注于接过上一个选手的交接棒,然后再交接给下一个选手。而且我们至少需要两个这样的选手。那么,这样还会赢得比赛吗? 这个我就不知道了,但是可以肯定的是,我们有一个明确的分工,对责任有了非常明确的划分界线。我们会知道由谁来承担过错。但我们不会赢得比赛。如果你仔细想想,会发现我们时把更多精力集中在失败的时候确定谁来负责的问题上,而不是去创造有利于成功的条件。把所有的人类智慧都投入到组织设计(城市结构、处理系统)当中真正的目的是什么?目的是在失败的时候把责任归咎于某人。我们创造了会失败的组织,但是以一种合规的方式来创造的,在这种组织中,有明确的人来为失败负责。在失败这点上,人们做的相当有效率。 软件开发过程中,好像还真会出现负责交接棒的人,比如技术Leader或者项目经理,帮助协调组件间的调用,协调不同人或者团队间的工作安排等。至于问责,呵呵,大家都懂的,老板需要个出了事能骂的人。这确实是更多的考虑失败的情况,那怎么创造成功的条件呢?其实很多时候真正有效协调的人,恰恰是具体做事的人。但如果这样协调没有发生,那是不是因为大家不知道有东西需要协调?我们可以提供足够的信息让大家了解互相之间的工作安排,比如做联合的计划会议或者需求讨论。或者建立机制让大家及早的发现工作间的冲突,比如使用持续集成。 度量 东西度量好了,事情也就完成了。你看,要传递交接棒,你要在对的时间、用对的手、以正确的速度来传递。但要这么做的话,你要把能量分配到你的手臂里。你手臂中的能量不在你的腿里。你必须牺牲掉可被衡量的速度。你将要交接的时候要及早喊出声,发出信号说明你快到了,以便让下一位选手有所预备。而且你要喊得够大声。但是这时血液、能量会集中在你的喉咙里,而不是你的腿里。 因为你知道,这时候有8个人同时在喊。 所以你要辨别得出你队友的声音。 你可不能说,“是你吗?”这就晚了! 大家注意第三棒选手。你看她把力量、能量和注意力 都分配在哪里。并没有都在腿部,虽然这样对她的速度很有利,可也分配在了喉咙、 手臂、眼睛、大脑里。那么这对哪个选手的腿产生了影响呢?答案是下一个选手的腿。但当下一名选手跑得特别快的时候,这是因为她自己特别使劲跑了呢,还是因为前面一名选手的交接棒传得好呢?这个地球上没有标准来给我们一个答案。如果我们根据可以测量的表现来对人们进行奖励的话,人们就会把自己的能量、注意力和血液集中在能够被测量的部位:腿部。而这样一来交接棒会滑落然后传递速度会减慢。 合作不是一股超级力量,而是对力量的分配。这意味着冒险,因为你要牺牲可被客观测量的个人表现所能给予你的终极保障。这对别人的表现有着重要影响,而这些人正是和我们相比较的人。所以要合作就要当傻子。但是人们可不是傻子,所以他们不合作。 度量是个老生常谈的问题了。我们设置度量指标的时候,需要想一想到底我们要这个指标达成什么目的?我们对这个指标有什么预期?(达到某个值,或是出现某种趋势等)如果这个指标达成预期了,我们会采取哪些行动?如果这个指标没有达到预期,我们又可以采取哪些行动?为什么这些行动现在没有发生? 我们常见的许多度量让我们过于关注于某些局部,未必促成最终结果的改善。如果使用度量,度量是否加强合作,还是让大家各自为战?有的组织十分依赖KPI,给开发人员设置的KPI要求他们产生的Bug要少,给测试人员设置的KPI要求他们发现的Bug要多,你觉得这些开发人员和测试人员合作的可能性有多大? 你知道吗,在比较简单的世界里, 清晰度、问责制、度量都是可行的。 但商业已经变得更加复杂了。如今要吸引并留住客户,打造世界级的优势并创造价值,是一件要求严苛的事。而商业越是复杂,我们就越是会以清晰度、问责和衡量的名义来让结构、过程和体制更加繁杂。 要知道,这种对清晰度和问责的推崇会引发一种反生产力的复杂化,导致出现更多的分界线、中间部门、协调者,他们不仅能动员人力和物资,但也会增添障碍。组织越是复杂,就越难理解究竟发生了什么。所以我们需要做总结、代理、报告、关键绩效指标、度量标准。所以人们都把精力放在了可以被测量的东西上,然后牺牲合作。当表现退步了,我们会增加更多的结构、过程、体系。人们会把时间都用来开会、写报告,写了又改、改了又写。根据我们的分析数据显示,这些机构的团队会把40%到80%的时间用来浪费时间,他们越做越辛苦,越做越耗时,而增值活动却越来越少。这才是泯灭生产力的罪魁祸首,这才是让人们工作痛苦的原因。 我们的组织在浪费人类智慧。它们和人类的努力背道而驰。当人们不合作的时候,不要怪他们的思想、他们的心理、他们的性格。请看一下他们的工作环境吧。合作与否真的事关他们的个人利益吗?如果他们合作了,他们的个人表现会不会被削弱? 既然如此他们为什么还会合作呢?当我们责怪的是一个人的性格,而不是责怪清晰度、问责制和度量方法时,我们在无效之上又加上了不公正。 我们要创造的组织,应该让人们觉得合作有益于个人。把界线划分、中间部门等这些复杂的协调结构取消掉。不要强求清晰度,选择模糊。模糊没有明确分界线。取消大部分的评估表现的量化指标。速度指的是“什么”,可我们要看的是合作,即“如何”。你如何传递交接棒? 你直接抛吗,还是有效地传递过去?我是不是把我的能量都集中在了可量化的方面:我的腿,我的速度,还是放在了如何传递交接棒上? 你们,作为领导和管理者,是否让人们觉得合作有益于个人?我们组织、公司、社团的未来取决于你们对这些问题的答案。 Yves这个演讲谈到组织的简化,减少中间部门、协调者,这和LeSS的想法不谋而合。软件产品开发过程中,因为人员的增多,我们往往增加更多的角色,设置更复杂的流程,设置更多的职能部门,结果不增加价值的工作也增多了,合作也减少了。与其他大规模敏捷开发框架不同的是,LeSS选择descale,简化过程,减少不必要的协调角色和中间部门,提供相应机制,创造有利于合作的环境促成团队内及团队间的协作,比如特性团队,多团队的联合会议,对一个产品使用唯一的产品待办事项列表等。如果对LeSS感兴趣,可以参加上海8月由LeSS创始人Bas Vodde亲自授课的Certified LeSS Practitioner课程 https://yihuode.io/activities/656...
阅读更多
常见研发团队结构碰到的问题

常见研发团队结构碰到的问题

一般软件研发团队组成方式无非几种:按职能划分的职能团队,按系统结构划分的组件团队,以客户为中心的特性团队。这些团队结构各有各的问题和挑战。 职能团队 业务分析团队,设计团队,架构师团队,开发团队,测试团队,按照职能来划分。完成价值交付的过程会出现明显的阶段和交接传递。理想状况是一个需求流畅的从一个团队流畅的流动到下一个团队,直到价值交付到客户手中。 往返传递 现实情况是通常下一个职能团队为上一个团队提供反馈,需求可能会回到上一个职能团队进行调整,需求会在职能团队间来回传递。比如,开发团队完成开发后交给测试团队,测试团队发现bug又交还给开发团队修复,这个过程会反复多次。这样的反复通常无法预期,会经常影响两个团队的原计划,这又加剧了职能团队的下一个问题。 等待队列 工作性质和团队工作能力的不同,导致一些团队会有不能及时处理的任务堆积,形成队列。这些等待中的任务是半成品,不能直接产生价值,是一种浪费,还会使事情变复杂,比如需要有人来维护这个队列。队列会降低工作的流动性,从而降低价值交付的速度。 组件团队 组件团队是按照架构模块或系统组件来划分团队。比如GUI团队,API团队等。 限制设计 按照康威定律,“任何设计系统的组织……都不可避免地产生出与其组织沟通结构一致的系统设计”,团队的组成结构会限制设计。然而大多数情况下,一开始产生的设计都不是最完美的,组织的灵活性对有效的设计有着举足轻重的作用。而组件团队恰恰限制了设计的有效性。 强化瀑布,增加协调复杂度 组件团队还会加强瀑布的开发过程。通常组件团队的存在会导致工作安排按照组件来分配给各个团队,这意味着所有组件团队完成各自的工作后还需要集成并完成最后的测试,反馈被延迟了。当然我们可以用持续集成等方法来加快反馈频率,但这中间的协调工作也确实变多了,你的Team Leader或者Scrum Master是不是经常为这样的事情疲于奔命?想想如果每个团队的工作是完成相对完整的功能,协调工作是不是会减少许多?组件团队有自己的计划安排,但往往需要和其他组件团队协调(比如联调),导致计划总在被打乱? 系统问题 同时,组件团队和职能团队都会导致:团队往往只关注于完成手头上的工作而非价值;团队与团队间形成职责壁垒,各自只为各自工作负责,也不愿其他人碰自己的工作(典型的如开发人员不愿意其他人碰自己的代码),这也意味着各个团队会更倾向于局部优化,比如在团队工作内容不多的时候,团队会制造些活来干,或者基于专业性来挑选工作而非客户价值。 特性团队 特性团队是由长期合作、跨职能、以学习为导向、多技能的人员组成,能完成端到端客户特性的团队。通常团队的职责包括需求分析、交互设计、计划、设计、编程、测试等,这样团队就能全神贯注地完成端到端的客户特性。 大多数组件团队的缺陷也得以弥补了,比如计划、协调等工作被大大简化了,交接与等待的浪费也减少了,整体的生产周期也被缩短了。同时,团队的技能约束少了,计划和安排工作的灵活性就提升了,可以更多的专注于真正高优先级或更有价值的功能开发上。当然特性团队的好处虽多,但也有不少的挑战和问题: 团队及其成员需要扩展技能和相应的产品知识,以便尽可能的修改系统的任意部分 同时修改同一个代码的机率变高了,冲突的可能性也提高了,这就意味着需要频繁提交代码等一系列持续集成的实践来减小工作批量,缩短集成周期。 各个组件的设计责任被分散到了各个团队,除了持续集成外,还需要其他的实践来保持设计的合理性和持续改善,比如测试驱动开发,重构,演进式设计,组件守护者等。 有些特定的技能比较难以掌握,比如视觉艺术,或者稀有专家掌握的知识和能力(比如图像渲染中的光线追踪算法) 可能需要组织结构的调整,一般组织是以组件或者职能线的汇报关系,最终需要转变成多个团队向共同的上级经理汇报。 如果你正纠结于团队结构或者其它团队在研发过程中碰到的问题,可以考虑参加我的培训: Certified Scrum Developer认证Scrum开发者课程 —— 敏捷团队工程实践 时间:2018年4月8日~10日 地点:上海 ScrumMaster领导力课程 —— ScrumMaster进阶技巧课 时间:2018年4月16日~17日 地点:上海 或者也可以找我聊聊,可以通过zbcjackson@odd-e.com 或者微信 ...
阅读更多