团队管理：新业务团队如何结合绩效来度量开发目标

时间过得真快，好像去年的年度总结和计划：去年4个1，今年5个1才 刚制定完，而现在又开始下年的规划了，如果真的可以生活在梦中梦...，那可以做的事情那就多了：）之前有人给我blog留言问过绩效的事情，本篇主要与 大家分享一下如何在新业务项目组中结合绩效来度量目标的一些思考，我们先从对绩效、产品开发的认识开始，最后会列出绩效细则。本篇更多从量化角度去看，不考虑绩效分数的激励制度。

敏捷个人和敏捷团队

　　就像我在个人管理 － 使用Scrum来敏捷自己所说的，在我们要求团队以人为本进行管理时，我们不能单方面要求团队把员工当人看，更重要的是员工要把自己当敏捷个人来看，做到在最基本的主动、自律的完成工作基础之上再去发挥你的卓越。我也一直都是这么要求自己的，并且也在把这些想法积极地与身边的人和关注我blog的朋友进行分享（敏捷个人－认识自我，管理自我.pdf、30天敏捷结果、30天敏捷生活），希望能够影响大家思考做更好的自己。

　　敏捷个人是 个人发展的一个较好的方法，但是对于团队来说，敏捷个人只是基石，要想发挥1+1>2的作用，必须把敏捷个人放大到敏捷团队中。敏捷个人初看可能都 是个人驱动的，更关注自身的修养，但是每个人都不不开社会、离不开1团队，所以要想更好的发挥敏捷个人的作用还需要结合团队目标，去成为敏捷团队中的一 员。敏捷团队的形成相对来说不会简单，它是基于敏捷个人基础之上，由团队驱动的，是集体的力量，即使人人都是敏捷个人，但是方向不一致、工作不协调，最终 团队也是注定失败的，所以团队必须给大家指明方向，制定价值观和规范，确定目标，而年底的规划就是这样的一次行动，这也是我对规划和管理的一种认识。

 

我现在所在项目组为新业务项目组，下面我将结合工作的一些思考来分享一下目标和开发相关的绩效。

新业务产品开发是一种创造性工作

　　一个新业务产品的成熟一般都要经历三研、孵化、推广阶段，各个阶段的重点也不一样。这些具体阶段划分可能每个公司都不一样，但是对于新业务的认识应该是有一个共识，那就是复杂性。

　　在流程 － 从IT方法论来谈Scrum中 我讲到一个复杂性评估的图，它由两个方面决定，一个是不确定性，另一个是一致性。新产品的业务、技术、市场都是不确定的；而团队对待问题、决策的也会有分 歧；这两点势必造成了新业务产品的复杂性。面对这种复杂性，决定了我们要做的是一种创造性工作，而创造性工作又有以下一些特点：

1. 新产品研发是一种创造性的活动，它是一个不断假设-验证的试错过程，其结果具有很大的不确定性
2. 难度大、风险高、周期长
3. 研发成果往往很有价值，但又较难以量化

Scrum方法

　　由于软件开发中的这么多复杂性导致不断变化，所以才出现了现在的敏捷方法，例如Scrum等。虽然很多不确定性造成我们一开始很难计划，但是我们可以采用小步快走的敏捷式方法走。（敏捷方法之Scrum.pdf）

　　在Scrum方法中，我们必须承认新产品软件开发的复杂性，而去实施经验性方式解决这种复杂性。实施经验性过程控制方法时，有3大支柱：可见性、检查及适应。其中可见性是指对过程控制者来说，过程中对最后结果有影响的方面必须清晰可见，而且必须真实可信，这就必须有个清晰的度量，这也是本篇的重点。

绩效和目标

绩效一直都是公司的重点之一，但我觉得存在以下问题：

1. 绩效难，如何做？
   绩效难做，特别是变数太多的任务。由于执行者难做，而上面又催着要，造成了上面把绩效当做规划、管理来看，而具体操作层认为绩效是一种填写表格的硬性任务而已。
2. 我制定目标该高要求还是正好？
   在读书笔记：心智的力量说过我们在制定目标应该不要害怕把目标设定得很高，抛掉"不可能"的想法，努力引导自己一步步获取成功。不要因为害怕失败就设定一个较低的目标，把目标设得高一点，即使超出了你的能力，再改变也不晚。但是现在绩效一般都和工资挂钩，少一分就够你1%的绩效工资。而现在目标都是自己定的，如果多扣几次钱，则势必会让目标本身就没有卓越感。
3. 自评分数准不准？
   度量制定不清楚，导致分数难打。绩效分数都是先自评，打低了显得没有水平还扣钱；打高了领导可能还不好意思去扣分，毕竟是努力过了

 

还没有细想其中所有问题，针对这些问题，我觉得要换一种正面的态度去认识绩效。我认为：

• 把绩效作为敏捷个人自我改进的一个环节，是阶段性的工作成效评估
• 绩效是促进目标的实现，而不是工资发放标准，可以考虑95分以上不扣钱等
• 绩效是制定目标的一种方法，绩效指标是目标量化的一种有力度量方式

两类绩效

　　创造性是假设验证的过程，如果我们过于关注结果（不允许失败），那么一定会扼杀创造性。对技术团队的考核不能够单纯的关注结果，还要关注过程和 结论。这就需要在产能和创造性上作出权衡，为了更好的解决产能和创造性的这个问题，我们通常将工作分解成两类，一类人侧重研究创新，另外一类人侧重项目产 出。我们在做绩效方案时可以针对这两类人分别来做，如果你身居两职，则综合考虑这两类人的绩效即可。

• 架构团队是侧重研究大的创新，而开发团队专注于日常项目开发和实施（在规模化产品开发方法－产品线工程 .pdf中介绍了产品线开发也是由两个团队来完成）
• 对架构师团队来说，管理的是创造性成果的产出（量化困难），我们叫它创新线绩效
• 对项目团队来说，管理的是日常项目产出（相对容易量化），我们叫它项目线绩效

下面我们分别针对这两类绩效来介绍。

项目线绩效（月度）

　　对项目团队来说，管理的是日常项目产出，这个相对来说交易量化。项目线绩效由两部分组成，一部分是业绩绩效，另一部分是贡献绩效。

　　工作业绩是产品开发中的本职工作，绩效分由四个方面的因素构成：开发工作量、协调工作量、技术难度、发版风险。让大家首先要有意识去做本职工作 之外但对项目有贡献的事情，在一定范围内做得越多自然越好，这对项目团队来说是有益的。不管是工程师、架构师还是项目经理，都应该划出这样一个固定的比 例，把对团队的附加贡献作为非项目绩效，否则做和不做没什么区别，谁还愿意做下去呢。贡献绩效主要是事件考核，根据事件的等级以及执行成效去评估，如果你 擅长演讲，可以去作培训；如果你看不怪垃圾代码，你可以去组织做Code Review。不同的事件我们可以划分为A、B、C三个等级，（等级可以自己制定，例如可以按照事件重要性、或者影响人的范围），还可以专门为那些脑子比 较灵光的人设置G等级创新事件。

• 业绩绩效分 （85%）
  
  • 基础分（50%）：只要你的项目做完了，拿到测试报告了，就可以获得基础分
  • 质量分（40%）：测试质量等级有A、B、C三级，A级拿满分，B级和C级分别扣一定比例的绩效分
    • bug分值：A:B:C:D=7:5:2:1，即一个致命bug抵7个轻微bug，最后将bug分值除以实施人天，我们便可以知道每一个人天的投入产生了多少bug分
    • 重复问题提交率：bug没有有效修复，提交后仍旧有bug，以个数计
    • 致命bug及时修复率：开发人员有没有在指定的时间区间内完成阻断bug的修复，以便QC可以继续推进测试工作
  • 进度分（10%）：没有延迟就得满分，如果有延迟，根据延迟级别扣除一定比例的绩效分
• 贡献绩效（15%)
  • 事件绩效等级（50%）
  • 执行成效（50%）

创新线

　　创新线绩效主要针对的是架构师角色的人员，所以下面先介绍一下架构师是干什么的。

• 角色：架构师（参考架构师应具备的概要技能）

  • 通过对现有系统运行状况的了解，发起各种各样的重构提案，并根据资源状况选择性的实施已经成熟的提案 

  • 架构师还负责向整个团队培训架构知识，通过提升开发团队的架构能力从而降低系统变更过程中的架构风险

• 架构团队
  • 行医：项目架构提案以及实施咨询
  • 为师：培训分享，提升整个技术团队的架构能力

　　前面也说了，对架构师团队来说，管理的是创造性成果的产出，这个比较难以量化，这是就要发挥敏捷个人的高要求，我们作为架构师，需要自己和自己比，"持续成长"也就是一种"成功"，只要是在进步，那就是好事情。虽然难以量化，但为了可见性还是应该想出一些实际有用的指标来量化它，而对于提案，按数量统计是一个非常简陋却有效的办法。

• 按数量统计
  • 创新提案数：即一段时间内发起了多少个创新提案。对于产品驱动型公司，业务架构师的研究课题 可能根据项目规划就已经定下来了。而对于技术架构师来说，这个需要自己去找。对于提案，自然是越多越好，起码是每个架构师手上都有几个预研的方向，例如分 布式存储系统、将图片等文件资源从数据库中搬移出来，降低了数据库的负担
  • 通过评审的提案数
  • 提案实际应用范围：实际应用情况、架构服务的质量（项目组的客户满意度）

创新线绩效（季度）

• 任务完成情况 （80%）
  
  • 项目的执行状态（30%）
    提案阶段计3分，评审通过8分，应用完成5分；假设在某一季度中，提出了2个改进意见及解决方案，有一个项目制作了解决方案并获得评审通过，同时有2个项 目在不同项目组实施，计算如下：3×2+8×1+5×2 = 24分，积满为止。提案其实就是一种创新，这是比较难的，所以我们分配了8分的比例，将提案转化成可以去实施的方案，这是技术含量较高的部分。至于在相关 系统上进行应用就是相对常规的事情了。
  • 项目的应用价值（30%）
    • 该部分主要是有项目评审阶段产生，项目评审通常是由相关主管领导（通常3-5人）参加，主要验证方案的正确性及可行性，在验证通过后，加入了评分原则
    • 由不同评委参与打分：重要紧急１０分，重要不紧急６分，其它３分。积分方法同上，积满为止。
    • 这里的分值配比，其实就是参照经典时间管理的套路：重要和紧急两维四分法。由几个人拍脑袋决定。
  • 项目实施的质量（10%）：这个质量是指项目实施的测试质量等级，与项目线相同，A级１０分，B级６分，C级３分。架构组的项目实施质量分与项目线的相比，所占比重要小很多，这是因为对于架构组来讲，关键是创造力（提案），至于开发过程中产生一些问题（往往很少）是可以被接受的。
  • 客户满意度（10%）：通过满意度调查表产生分数。每个季度发放调研表格给相关服务项目组，然后取平均值。
• 培训与分享(10%)：每组织一次正式的课程分享积４分，每产生一个主题Topic积２分
  
• 行为和附加贡献(10%)：这个10分是给领导拍脑袋的，作一些总体控制

　　以上绩效细则主要参考互联网技术团队的绩效管理实践，具体实施时需要根据项目组具体情况调整比例和细则规定和内容。虽然不能适用于所有团队，但至少对新业务团队的绩效提供了一种可实际操作的参考。