标签： 团队

一直以来大家都关注于生产力（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...