/ Organization

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

一直以来大家都关注于生产力(productivity),但由于过往对于效率的基本认识,导致组织或管理的效率上的努力适得其反。被视为经典的效率三位一体(trinity)指的是:清晰(Clarity),衡量(Measurement)和问责(Accountability),恰恰是它们使人们的努力白费。

我们可以通过接力赛跑来看待以及证明这个观点。世界杯女子接力赛决赛一共有8支队伍。最快的是美国队,美国拥有全世界最快的女运动员,是夺冠热门。如何拿她们和其他队伍比较,比如法国队。

relay-team-compare

按照她们在100米短跑当中的最佳成绩,把美国选手个人的成绩相加起来,最后她们会在达终点线时比法国队领先3.2米。今年,美国队状态很好。根据她们今年的最好成绩,她们在到达终点时应该要领先法国队6.4米,这是根据数据推算的。美国队第四棒Torri Edwards今年在100米赛跑中获得了金牌。美国队第二棒Chryste Gaines是地球上跑得最快的女性。显然,美国队赢得了人才争夺战。不过在其背后,普通的队伍也在奋力追赶。

视频里发生了什么?最快的队伍没有赢,慢的那一队反而赢了。

为什么呢? 因为合作。你可能听过这句话:“多亏了合作,整体大于部分之和。”这不是诗歌,这不是哲学,这是数学。握着接力棒的人跑得慢了点,但她们交接棒更快。合作的奇迹能让人们努力的能量和智慧加倍。这是人们努力的精髓:我们如何合作,个人的成果如何为团队做贡献。通过合作,我们可以事半功倍。

那么,当圣神三位一体(清晰、衡量、问责)出现时,会对合作产生什么影响?

清晰

管理报告充满了对缺乏清晰度的抱怨。 合规性审核、咨询诊断。我们需要更高的清晰度,我们要明确角色和流程。就好比说队伍里的选手说,“我们明确下吧:我从哪里跑到哪里?我要跑95米,还是96、97米...?”这很重要,我们要分清楚。如果你说97米的话,那么跑完97米,人们就会把交接棒丢掉,可不管到时候有没有人接。

想想软件开发过程中,我们也经常听到类似的,“我是做开发的,测试我不管”,“这是后端处理的,等他们做好了再说”,“现在是运维的事情了”。我们对软件开发过程中的各种行为进行了分类,并指定一个角色。整个开发过程要有清晰的阶段,角色的职责边界也要十分清晰。那么,不清晰可以有什么选择?比较常见的情况是我们按照职能,开发流程,系统组件来划分角色职责,比如开发可不可以做些测试,和测试人员一起协作共同为质量负责,前端开发和后端开发互相协作共同为交付功能负责。模糊掉组件间、职能间的边界,把他们都放入一个团队共同为交付特性负责,形成特性团队。

问责

我们总是试图把责任规定给某个人。谁对这个过程负责?我们需要一个人对这个过程负责。所以在接力赛中,既然交接棒如此之重要,那么我们需要非常明确负责交接棒的人是谁。在两个选手中间,我们现在要规定一个新的专门的运动员,这个运动员要非常明确地专注于接过上一个选手的交接棒,然后再交接给下一个选手。而且我们至少需要两个这样的选手。那么,这样还会赢得比赛吗? 这个我就不知道了,但是可以肯定的是,我们有一个明确的分工,对责任有了非常明确的划分界线。我们会知道由谁来承担过错。但我们不会赢得比赛。如果你仔细想想,会发现我们时把更多精力集中在失败的时候确定谁来负责的问题上,而不是去创造有利于成功的条件。把所有的人类智慧都投入到组织设计(城市结构、处理系统)当中真正的目的是什么?目的是在失败的时候把责任归咎于某人。我们创造了会失败的组织,但是以一种合规的方式来创造的,在这种组织中,有明确的人来为失败负责。在失败这点上,人们做的相当有效率。

软件开发过程中,好像还真会出现负责交接棒的人,比如技术Leader或者项目经理,帮助协调组件间的调用,协调不同人或者团队间的工作安排等。至于问责,呵呵,大家都懂的,老板需要个出了事能骂的人。这确实是更多的考虑失败的情况,那怎么创造成功的条件呢?其实很多时候真正有效协调的人,恰恰是具体做事的人。但如果这样协调没有发生,那是不是因为大家不知道有东西需要协调?我们可以提供足够的信息让大家了解互相之间的工作安排,比如做联合的计划会议或者需求讨论。或者建立机制让大家及早的发现工作间的冲突,比如使用持续集成。

衡量

东西衡量好了,事情也就完成了。你看,要传递交接棒,你要在对的时间、用对的手、以正确的速度来传递。但要这么做的话,你要把能量分配到你的手臂里。你手臂中的能量不在你的腿里。你必须牺牲掉可被衡量的速度。你将要交接的时候要及早喊出声,发出信号说明你快到了,以便让下一位选手有所预备。而且你要喊得够大声。但是这时血液、能量会集中在你的喉咙里,而不是你的腿里。 因为你知道,这时候有8个人同时在喊。 所以你要辨别得出你队友的声音。 你可不能说,“是你吗?”这就晚了!

hand-over

大家注意第三棒选手。你看她把力量、能量和注意力 都分配在哪里。并没有都在腿部,虽然这样对她的速度很有利,可也分配在了喉咙、 手臂、眼睛、大脑里。那么这对哪个选手的腿产生了影响呢?答案是下一个选手的腿。但当下一名选手跑得特别快的时候,这是因为她自己特别使劲跑了呢,还是因为前面一名选手的交接棒传得好呢?这个地球上没有标准来给我们一个答案。如果我们根据可以测量的表现来对人们进行奖励的话,人们就会把自己的能量、注意力和血液集中在能够被测量的部位:腿部。而这样一来交接棒会滑落然后传递速度会减慢。

合作不是一股超级力量,而是对力量的分配。这意味着冒险,因为你要牺牲可被客观测量的个人表现所能给予你的终极保障。这对别人的表现有着重要影响,而这些人正是和我们相比较的人。所以要合作就要当傻子。但是人们可不是傻子,所以他们不合作。

衡量是个老生常谈的问题了。我们设置衡量指标的时候,需要想一想到底我们要这个指标达成什么目的?我们对这个指标有什么预期?(达到某个值,或是出现某种趋势等)如果这个指标达成预期了,我们会采取哪些行动?如果这个指标没有达到预期,我们又可以采取哪些行动?为什么这些行动现在没有发生?
我们常见的许多衡量让我们过于关注于某些局部,未必促成最终结果的改善。如果使用衡量,衡量是否加强合作,还是让大家各自为战?有的组织十分依赖KPI,给开发人员设置的KPI要求他们产生的Bug要少,给测试人员设置的KPI要求他们发现的Bug要多,你觉得这些开发人员和测试人员合作的可能性有多大?

你知道吗,在比较简单的世界里, 清晰度、问责制、衡量都是可行的。 但商业已经变得更加复杂了。如今要吸引并留住客户,打造世界级的优势并创造价值,是一件要求严苛的事。而商业越是复杂,我们就越是会以清晰度、问责和衡量的名义来让结构、过程和体制更加繁杂。

要知道,这种对清晰度和问责的推崇会引发一种反生产力的复杂化,导致出现更多的分界线、中间部门、协调者,他们不仅能动员人力和物资,但也会增添障碍。组织越是复杂,就越难理解究竟发生了什么。所以我们需要做总结、代理、报告、关键绩效指标、衡量标准。所以人们都把精力放在了可以被测量的东西上,然后牺牲合作。当表现退步了,我们会增加更多的结构、过程、体系。人们会把时间都用来开会、写报告,写了又改、改了又写。根据我们的分析数据显示,这些机构的团队会把40%到80%的时间用来浪费时间,他们越做越辛苦,越做越耗时,而增值活动却越来越少。这才是泯灭生产力的罪魁祸首,这才是让人们工作痛苦的原因。

我们的组织在浪费人类智慧。它们和人类的努力背道而驰。当人们不合作的时候,不要怪他们的思想、他们的心理、他们的性格。请看一下他们的工作环境吧。合作与否真的事关他们的个人利益吗?如果他们合作了,他们的个人表现会不会被削弱? 既然如此他们为什么还会合作呢?当我们责怪的是一个人的性格,而不是责怪清晰度、问责制和衡量方法时,我们在无效之上又加上了不公正。

我们要创造的组织,应该让人们觉得合作有益于个人。把界线划分、中间部门等这些复杂的协调结构取消掉。不要强求清晰度,选择模糊。模糊没有明确分界线。取消大部分的评估表现的量化指标。速度指的是“什么”,可我们要看的是合作,即“如何”。你如何传递交接棒? 你直接抛吗,还是有效地传递过去?我是不是把我的能量都集中在了可量化的方面:我的腿,我的速度,还是放在了如何传递交接棒上?
你们,作为领导和管理者,是否让人们觉得合作有益于个人?我们组织、公司、社团的未来取决于你们对这些问题的答案。

Yves这个演讲谈到组织的简化,减少中间部门、协调者,这和LeSS的想法不谋而合。软件产品开发过程中,因为人员的增多,我们往往增加更多的角色,设置更复杂的流程,设置更多的职能部门,结果不增加价值的工作也增多了,合作也减少了。与其他大规模敏捷开发框架不同的是,LeSS选择descale,简化过程,减少不必要的协调角色和中间部门,提供相应机制,创造有利于合作的环境促成团队内及团队间的协作,比如特性团队,多团队的联合会议,对一个产品使用唯一的产品待办事项列表等。

Jackson Zhang

Jackson Zhang

Odd-e敏捷教练,主要涉及组织,团队,产品,技术,工程实践等,曾为多家知名企业提供教练与培训服务。译有《用户故事与敏捷方法》,《.NET单元测试的艺术》和《实例化需求说明》。擅长工程实践(如测试驱动开发,单元测试,重构,持续集成等),产品探索(Impact Mapping,Pretotyping,Lean Startup等)与团队协作。zbcjackson AT gmail.com

Read More