时间都去哪了？
“不是在开会就是在去开会的路上”这是很多职业经理人工作的真实缩写。然而事实往往是忙碌了一天，拖着疲惫的身躯回到家，回头想想这一天虽然处理了不少事，但没有一样是真正完成的，所有的工作都是在进展中，而且越来越趋于复杂，依赖因素也越来越多。对于实现安排的完成日期也越来越没有信心。
为什么会这样？我们的团队是不是哪里出了问题，导致效能这么低？在项目初期就给团队树立了明确的目标，但团队都把时间用到哪里去了？
带着这个问题，我们将一起探索团队效能的问题症结在哪，该如何提高团队效能。
很多人会把效率和绩效作为一个概念来评价团队，其实它们是两个完全不同的概念。
首先高效不是绩效，也不应该是绩效的考核指标。效率是用来评价一个人或团队的工作效率，即完成每个任务的时间成本是多少。这是不会因为加班加点而提高的。
绩效如果排除其他考核因素，仅从工作任务完成情况来看，绩效是通过统计员工完成任务的总量和预期目标比较所得到的结果。管理者往往会忽略团队成员到底花了多少时间完成那些任务，甚至鼓励员工付出额外劳动来按期按质地实现任务，因为绩效完全是结果导向的（这样的管理者也往往是效能提高的最大障碍）。因此我们可以得出如下两个效率和绩效的公式：
效率 = 计划完成的工作总量 / 实际时间成本
绩效 = 周期内实际完成的工作总量 / 周期内计划完成的工作总量
如果仔细比较，我们可以发现如果是在一个周期内，效率×绩效=周期内实际完成的工作总量/实际时间成本，而这个值我们称之为工作预估偏差。
到这里，估计大家能想到我们其中一部分时间去哪了。那就是工作预估偏差值（计划工作总量－实际时间成本），如果这个值为负值，说明我们在加班；如果为正值，说明我们团队效率不错，还有多余时间。
看上去是这样的道理，但上面这个公式不一定总是正确的。原因是当团队面临很多技术难题或者其他因素时，会增加任务缓冲值，从而让估算偏差看上去总是正值。所以很多人会质疑这个值的可依据性。在敏捷开发模式里提出了一个很好的概念：故事点。
高效实践一：故事点
故事点估算是敏捷项目任务的估算方法的一种，它是一种相对值，而且不是连续数也不和实际工作时间有直接关联（具体可查看故事点介绍）。在敏捷开发模式中，特别是多团队协作的情况下，项目经理可以把某个简单任务设置为参照物，估算点为1。每个迭代周期之初，安排各团队对所要开发的任务和参照物对比进行故事点估算。
通常情况下各个团队的故事点分配总数是接近的，因为它是相对值，对于任务估算中的缓冲时间被同步放大或者缩小。因此项目经理通过故事点的管理比工时管理更为可靠，而且宏观。
有了故事点，我们可以把团队的绩效用故事点来衡量。抛开这个不确定因素，我们的效率值或者估算偏差值就变得十分可靠。而让估算偏差变为正值是我们建立高效团队的目标。
如何改进估算偏差？
看过《一分钟经理人》这本书的人，一定记得管理大师布兰佳关于“一分钟目标”这个说法：只花一分钟的时间，就往往决定了这一天80%的工作内容，这是一个多么神奇的计划。于是很多人也去尝试做一分钟的目标，然而并没有描述的那么奏效，随之就放弃了。事实上，很多人忽略了这是一个持续性的计划，其实80%也是个人计划中需要去达成的一个目标。这种计划方法对于一个团队，即使是大型团队，花很少的时间来做一个当天目标设置其实同样十分有效。而关键在于计划的持续性和长期、中期、短期计划的关联。
这本书给我们另一个很好的概念：多短计划。
高效实践二：多短计划（站会）
在我带过的团队里，都会采用多短计划，每天早上或晚上进行15分钟的短会。目的是让每个团队成员了解我们一天要进行的任务有哪些，有什么样的问题需要相互协作解决，并确认是否存在计划偏差。
事实上，团队管理者更多关注的是任务的依赖性和计划偏差；团队成员关注的是当天任务计划和存在问题。当团队较多或每个团队中人数较多时，对于团队的每日状态管理就是难点了。如果每个团队有7个人，每个人平均有5个任务在进行（包括需求分析中、开发中、测试中、交付待确认等），任务之间存在相互依赖关系。那么对于管理者来说要掌握35个任务的进展状态和他们的问题在哪里，同时还要关注任务之间的优先级关系。如果每个任务需要10分钟，那么管理者可能花费将近350分钟（将近6小时）的时间来查看或处理所有的任务项。这是多么恐怖的现状！
对于每个团队成员来说，除了自己关心的任务之外，还要关心对于别人的依赖任务和依赖别人的任务。如果每个人各有一项依赖和被依赖项，每天也至少花费20分钟来处理。那对于团队来说也存在至少140分钟的沟通讨论。
是否管理者和团队的这些时间是必不可少的呢？答案当然是否定的。在团队中，我们可以用看板很好地管理这些任务，几乎可以在站会中一起解决这些事情。
高效实践三：看板
看板来源于日本，是丰田精益生产中的一个工具。其原理是只有当下游的任务发出原材料请求时，上游工序才开始生产该原材料。如此形成了拉动式的制造工序，并努力实现零库存。引入软件开发工程后，生产过程中的材料就被转化为工作任务项。每个任务要经历准备→开发中→开发完成→测试→测试完成→部署这几个阶段。每个人员或者每个任务会形成一条自己的“泳道”（任务需要通过的路径）。通过看板我们可以解决以下一些问题。
所有团队成员的任务状态清晰明了。
哪个阶段积攒任务过多，说明是瓶颈所在。
集体更新的机制减少团队1对1沟通次数。
可以收集过程数据，进行团队效率改善。
看板所带来的好处远不止这些。但在看板使用过程中也要十分注意一个关键词——WIP（Working inProgress）。它代表的是团队在某个活动下同时进行的工作项的数量。从科学的角度，每个任务的完成周期（Cycle Time）越短，其从事这项工作的工作效率越高。而对于管理者注重的人员使用率（Utilization）来说，当一个任务较大时（Cycle较高），其Utilization也会降低。而无限细化任务会大大提高分析时间和沟通成本，因此作为统计值，每个人同时有2个任务时，其工作效率是最高的，如图1所示。
影响效率的因素
有了一些实践方法，并不一定能马上提高团队的效率，因为影响因素是多方面的，需要综合长期的情况来看待效率问题。研发团队中，效率的主要障碍来自以下几个方面：
为快速交付积累的技术债；
团队人员T形技术能力；
不稳定的开发节奏；
管理者的微观管理；
低效的沟通成本，包括手工流程执行；
代码质量。
此外还可能来自组织自身的因素，如部门壁垒、区域分布和文化差异等。对于任何影响效率的因素都值得重视。很多团队就因为被其中一两个因素羁绊住，而导致整体效率的下降。这种时候不能期待依赖于其他问题的改善来提升整体效率，这和木桶原理一样。如果能够正确快速地识别原因，那么剩下的就是如何解决问题了。
建立高效团队的目标是发现消极因素，针对性地提出改进措施。管理者需要不断地思考这些因素给团队带来的影响，以及和交付目标之间的平衡。对于发现的问题，刺激我们的是发现问题的原因。这需要借助系统思考（System Thinking）的一些技巧，即把事务的逻辑关系和来龙去脉进行分析，打破影响因素的环路。例如图2的技术债问题，可以在任何环节中引出分支，即可消除滚雪球效应。
图2 借助系统思考分析逻辑关系
通常，我们可以为此可以重点监控一些下面的过程数据，以便于对阻碍因素的改进：
UAT缺陷率；
缺陷周期长度；
版本开发和维护投入比；
各类会议所占开发时间比；
周期内知识共享和代码走查次数；
自动化测试比例。
收集数据的目的不是为了根据现状去设定目标，否则就是本末倒置了。其真正目的是可以用来做改善方向的依据。例如发现缺陷周期超过一周，说明一个缺陷从代码签入开始一周以后才能被检测到，这是多么糟糕的事情。管理者应该思考如何加强对新签入代码的功能的检测，如何在还没有被集成到系统代码之前，让这样的缺陷可以被修复。这样才能减少不必要的沟通和二次发布的浪费。
管理者应该善于发现团队浪费，但同时也要允许浪费。宁可让团队完成任务后打游戏来培养团队协作能力，也不允许对于一个已经发现过的错误，再出现第二次。对此，一定要有个精神洁癖和偏执狂般的执着，才能给团队带来持续不断的效率改进。
郑立
相关文章
