有很多人喜欢对开发团队进行量化管理,其实对研发团队进行细致的量化管理,既不现实,也无必要。 量化管理只能适用于竞争激烈而合作少的场合,比如劳动密集型的手工制造。
研发团队靠的是成员之间互相配合,更多是合作关系,并非竞争关系;量化管理强行抹煞了合作关系,刻意强化竞争关系。须知整体并非部分之和,研发团队是不可拆分的——你能把一个人的不同器官拆开,讨论手的贡献大还是脚的贡献大吗?真的讨论出一个结果来,又有什么意义?手和脚如果能分家了,这还是一个人吗?同样,如果程序员、策划真的能够单独考核,他们为啥还要呆在团队里面,为啥不去独自创造价值?那,团队还是团队吗?
为了提高效率,出发点可以理解,但是更应该着眼于如何帮助成员合作,帮助成员沟通(大部分人并不擅长沟通),鼓励成员沟通。就我所见到的绝大部分情况,成员不做事或者进展缓慢并不是因为压力不够,也不是因为没有激励,也不是因为想偷懒;而是因为缺少沟通,工作上确实遇到障碍了。只要帮他们扫清障碍,他们就会很开心的继续前进。
如果你是一个HR, 那么量化管理是一个免不了的任务,就随随便便走走形式吧,不要当真。如果你是团队负责人,就把精力更多花在沟通上,比花在考核上效果要好得多。
另外,量化指标是可以的,但是不要用来做考核。量化指标是用来衡量整个项目状况的,好比体检时候的指标,看到指标异常就可以引起警惕,去看看到底有没有问题了。
任何量化的标准的准确度其实还不如主观评价的准确度。如果一个 team leader review 所有的 code change,参与关键问题的讨论、解决和验证,自己也负担少量开发工作。他对 team 成员的评估应该是准确的,或者说至少不输给任何量化指标。
量化指标的缺点很明显:
需要成员做很多 paper/bookkeeping work —— 填写各种表格和多余的 bug metadata。
鼓励管理人员脱离实际的产品开发。
容易造假。
经过上面三条,重视量化标准的 team 会形成很不健康的氛围。成员之间互相猜忌贬低,管理者闭目塞听。
对开发团队如何有效进行绩效管理?小编认为对于研发人员的管理中的还是定量和定性结合的方面进行。
首先对于研发人员的绩效不适合完全定量化的管理,研发工作是脑力劳动,受影响的因素太多,单一的指标往往很难衡量。包括我们说的开发的代码生产率,缺陷密度;测试的测试生产率,缺陷泄露率等,可以有很多指标,但是一旦完全严格量化考核,聪明得开发人员都会找到各种方法来规避指标体系本身的漏洞。而且很多单一指标本身又存在问题,别如代码生产率,大量的复制重复代码本身就违反我们的复用原则,生产率太高反而是坏事情。
其次又不能完全不量化,因为只有量化才容易进一步认识我们每个人各自的工作效率。才谈得上不断的持续改进。否则可能陷入老觉得差不多了,没什么好提高的思维中。如果要量化,其实任何一个岗位都包括两个方面的量化以体现高效,一个是生产率,一个是质量。如果对开发则是代码生产率和缺陷密度,对于测试则是测试执行效率和现场故障密度等。需要根据不同的岗位指定不同的指标,并且反复验证指标是合理的。切记指标不要太多,2-3个关键指标足够。
最后,我一直把工作态度和责任心列入绩效范畴,绩效包括了工作能力(生产率,质量),工作态度和思维能力三方面的内容。工作态度和责任心,思维能力这些可能更加难以量化,但是对于研发人员考核却很重要。开发团队强调的是自我主动,自我管理,完全强过程下得规范和约束往往并不能发挥团队最大效率。
最后如同大公司对各个部门绩效考核一样,各个部门绩效考核都优的情况下往往公司整体绩效并该不是最优。因此一定要避免这种情况,要讲团队,项目总体目标绩效落实到个人,才可能使团队中每个人为达到项目整体目标绩效而努力。