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

一直以来大家都关注于生产力(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...
阅读更多
项目管理不适合软件开发

项目管理不适合软件开发

首先我想澄清的是:项目管理本身没什么问题,但是把项目管理用在产品管理上这就是问题了,可惜90%的软件开发都是软件产品开发。在我接触到的公司或案例中,项目管理在软件产品开发中带来的伤害要远多于好处。 项目管理 维基百科上项目管理以及项目的定义: Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time. A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or staffing) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. https://en.wikipedia.org/wiki/Project_management 这里面有几个关键:明确的开始,明确的结束,明确的目标,临时的。据我所知,这些在大多数的软件产品开发中都很少见。多大概率你在工作中碰到的需求、产品、功能说在一个时间点结束就真的在这个时间点结束了?总会有各种形式的修改,修Bug,增加,删减等。软件开发中也几乎没有什么临时的,很多时候我们碰到一些“临时”的功能或任务实际存在的时间可都不短,有的甚至比我在公司待的时间都长。 项目管理的思维包含着可预测性。大家可能都知道项目管理的铁三角:范围、时间、成本。 需求的范围,各种时间节点,需要的成本(主要是人力成本),这些是评估一个项目管理是否成功的重要因素。一个项目在预期的时间内按照一定的成本完成了全部的功能,从项目管理的角度来看确实很棒。但是这个项目就真的成功了吗?某大型企业有过一次回顾讨论,他们有个项目按时按量交付了,还没有bug!但是大家都不觉得这个项目成功了,为什么?没有人买也没有人用,当然没bug了。 项目管理的思维方式可能会带来的问题: 长时间的计划 项目管理需要控制成本,因此需要一开始分析或“翻译”需求,明确范围,估算工作,制定预算,我见过不少项目在计划上的时间都多于开发交付的时间。 大量并行项目 计划的时间长,往往意味着同时进行的项目多。我还见过有的公司里一个需求就是一个项目,同时有几十个项目并行很常见。大量并行的项目会使这些项目的计划,追踪等更加的复杂。你可以想想许多公司根据项目抽调人员,还有很多角色是共享的,比如UI/UX,测试,运维等等,再加上项目和项目之间还会有些依赖,要做所谓的“排期”就已经十分的头大了,再稍微有些延期或其它变化就一团乱了。 争夺人员与资源 前面也说道按项目抽调人员是比较常见的现象,因为每个项目为了每个项目的成功都会尽可能的争夺对该项目最有帮助的人员或资源。因此产生的斗争和内耗也会很多,这是典型的局部优化。往往公司里能力越强的人同时做的项目越多,这个人会自己决定手头上事情的优先级。而且也会导致这类人的工作效率的下降,因为需要频繁的切换工作上下文。 关注在需求范围而非目的 项目结束时,大家更关注需求是否做完,也就导致项目过程中关注于计划的执行情况,这些需求本身有没有完成。大家会更少关注于这些需求背后的目的是否达成,是否有在产生价值。我们需要更多的关注产生的影响(Outcome),而不是我们的工作产出本身(Output)。这就要我们不断的验证假设,收集反馈,调整方向。 实现不必要的功能 项目就像一个容器,我们会对里面的“所有东西”进行计划,分析,设计,实现,测试,发布。但是从产品或业务的角度来看,这些都是成本,但是不是都产生价值呢?而且这些不必要功能的存在也会带来维护成本。我们是不是应该对项目的需求范围进行质疑,而不是一味的遵循呢? 降低质量 项目管理更加看重时间和成本,所以当截止日期逼近的时候,大多数开发人员会迫于可种压力在时间和质量之间作出选择,这是质量往往是被妥协的。有时他们选择不重构,不做单元测试,甚至不自测,甚至使用各种秘密武器:复制黏贴,从网上抄一段代码等等。技术负债就这样积累起来了,代码库变的难以维护,后续功能调整越来越难,成本越来越高。对于测试也是一样,测试的压力更大,测试强度也会减弱许多,比如不做回归测试或更小范围的回归测试,测试路径覆盖更少等。很多时候这种质量问题的结果并不会立刻显现。 产品负责人与项目负责人 这里产品负责人并不仅仅指Scrum中的Product Owner,项目负责人有可能是Project Manager或Program Manager。通常这两种角色有着天然的冲突,产品负责人关注价值,项目负责人关注计划的执行。项目负责人占上峰时,产品负责人失去对产品的控制力,只是负责管理需求列表;产品负责人占优势时,项目负责人只有职责却缺少实际控制力。我见过有的公司产品负责人还同时管项目,通常产品负责人大多数时间变成各种事情的协调员,甚至前后端的技术协调。 所以,你得弄清楚你真的是做临时项目吗?如果不是,那么你应该用产品思维来管理。产品通常是长期存在,关注于为客户带来价值,你会持续的对其进行修改、改进、扩展。当然你需要持续的迭代,尽快的从客户或最终用户那里收集反馈来调整后续的工作。即使你是做软件外包项目,如果你和客户是长期合作关系,依然你可以用产品的方式来做,因为你的开发过程会更加的顺畅,而客户可以获得更多的价值。 PS,有些公司搞所谓的“敏捷转型”也立个项,用项目管理的方式来做。我也是不赞同的,因为这样很容易变成只是在有限的时间内把一些实践给搬到组织内,未必产生实质性的效果,也不利于持续学习与持续改善。我们应该像开发产品一样,不断的试验调整来进行持续的改善我们的研发过程。...
阅读更多
常见研发团队结构碰到的问题

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

一般软件研发团队组成方式无非几种:按职能划分的职能团队,按系统结构划分的组件团队,以客户为中心的特性团队。这些团队结构各有各的问题和挑战。 职能团队 业务分析团队,设计团队,架构师团队,开发团队,测试团队,按照职能来划分。完成价值交付的过程会出现明显的阶段和交接传递。理想状况是一个需求流畅的从一个团队流畅的流动到下一个团队,直到价值交付到客户手中。 往返传递 现实情况是通常下一个职能团队为上一个团队提供反馈,需求可能会回到上一个职能团队进行调整,需求会在职能团队间来回传递。比如,开发团队完成开发后交给测试团队,测试团队发现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 或者微信 ...
阅读更多
一个快速有效提升团队效率和质量的方法

一个快速有效提升团队效率和质量的方法

在为客户提供教练服务过程中,我尝试过各种方法,发现其中有个方法提升团队的效率和质量最快速有效。简单概括就是实例化需求,但其实只用做一部分就可以有不错的效果。 为什么说这个方法快速有效?说快速是因为只需改变需求讨论会议或者Scrum中Product Backlog Refinement(PBR)的方式,通常就会在当前迭代看出效果来。有效是因为通常改善了团队的工作效率,减少了迭代内的bug,从而减少了开发和测试间的来来回回,提升了工作质量。过往的客户有做过Bug的根源分析,发现有一半是因为需求沟通的问题导致的。 具体做法是: 在开始开发前举行需求讨论会议。也就是Scrum中的PBR,通常在迭代的中间发生,用于讨论并澄清后续迭代的需求。 会议需要三个角色,产品经理或者Product Owner(PO),开发人员和测试人员。Scrum中就是PO和开发团队(包括了开发和测试等) 会议中产品经理简短介绍一下要讨论的需求,开发和测试用测试用例的方式描述需求,即验收条件。以5个需求和8人团队为例: PO花10分钟左右简单介绍5个需求 团队分成3个2~3人的小组,每个小组选一个需求进行讨论,写出需求的验收条件。20分钟一个时间段。此时,PO应随时帮助团队澄清疑问。 再10分钟每个小组分享一下各自的验收条件,其他人给出反馈 再做一轮20+10分钟的讨论,可以根据反馈来调整验收条件。如没有调整,可以拿下一个需求讨论。 如果需要,可以再做一轮。但通常2个星期的迭代,2个小时足够完成整个会议。 用具体的例子来描述验收条件来减少产生误解的空间。比如,买3本书包邮的例子 买一本《实例化需求》和一本《用户故事与敏捷方法》,快递费是12元 买一本《实例化需求》,一本《用户故事与敏捷方法》和一本《单元测试的艺术》,快递费是0元 用业务的语言描述。验收条件应当是业务人员都能看懂的,因此描述的语言应该是业务语言,不应包含技术或操作细节。这样更容易沟通,同时避免过多的讨论实现细节,关注于“需求是什么”而不是“如何实现” 通常来说帮助团队实现1到3比较容易,团队多练习几次就能习惯4和5的表达方式。至于是否一定要用“假如……当……那么……”的格式,如果只是帮助大家澄清需求,那重要的是大家理解这样的结构化表述,对需求规则理解的表述包含了“条件-行为-结果”。当然,我更倾向于使用这样的格式来帮助大家习惯结构化的表述,同时也能方便以后自动化。 经过这样的需求讨论会议后,团队将带着这些验收条件来进行开发,开发一开始写代码的时候就知道测试将怎么测,测试不用来来回回重复测之前已经讨论的情况,可以花更多的时间来发现之前没法预测到的问题。 如果想要有更进一步的效果,那就需要将验收条件自动化,并且不会为了自动化改变原本验收条件的描述,最终形成活文档。当然这需要的投入就比仅改变讨论方式要多很多了,也比较难完全掌握。用实例化需求来实现从外向内的开发——从PBR到Acceptance Test Driven Development(ATDD),再到Unit TDD。这将极大改善产品开发。这些将在以后的文章中讲解,或者来参加我们的培训。:D...
阅读更多