
9.1 问题描述
假如你是软件团队(技术团队)的管理者,正在通过使用KPI对团队整体和团队成员的绩效进行评估,但是你却被下列问题所困扰。
——KPI太关注结果,而忽略了过程
虽然KPI定义了清晰和定量的衡量指标,但是其更多关注的是某个既定目标或者既有流程的输出,而对达成此目标的过程却不能很好地进行监控和衡量。
例如,对于软件研发团队而言,“泄露至客户处的软件故障数目”是一个衡量所生产的软件的质量KPI(结果)。但是,若仅仅关注此结果而忽略了过程,例如在代码开发期间的需求澄清,代码审查等过程性活动,实际上达成结果的风险也增大了。
——KPI的反馈周期太长,存在滞后效应
KPI是通过对组织某个过程或者活动的关键参数进行设置、取样、计算、分析,从而衡量过程或者活动的绩效指标的目标化管理实践,由于涉及对结果的取样、计算和分析等一系列复杂的活动,在实际操作中KPI的反馈周期往往较长,从而存在反馈的滞后效应。例如,对于销售人员,一个重要的KPI是“销售任务完成率”(实际完成销售收入/目标销售收入),并按照月(或者季度)为频度对此KPI进行更新。然而,当发现此KPI偏离预期的时候,往往已经到了次月,甚至更晚(因为涉及数据收集)。这样的问题在于,虽然KPI能够提供绩效反馈,但是当本月的绩效反馈需要到下个月甚至更晚才能够获得时,最好的纠偏时机已经错过了,特别是面对瞬息万变的市场情况。可以想象一下,如果一个销售人员在2月份时才能获取1月份的“销售任务完成率”KPI数据,并发现数据远远低于预期。即便立即在2月采取行动,最快也只能在3月的KPI中才能获得采取的行动是否有效的反馈,而此时,市场情况已经又有了很多变化。
——KPI止于KPI,没有形成一个持续提升的闭环
KPI绝对不是终点,而只是达成目标过程中一个重要的工具。然而,在实践中,往往出于过分对KPI的关注(因为与绩效挂钩),使得达到KPI成为了目标;而偏离了最初的目标。这样“本末倒置”的怪现象,使得KPI最终止于KPI,而没有形成一个促进团队和个人目标达成的闭环。例如,当“泄露至客户处的软件故障数目”这个KPI出现偏差时,软件团队往往会采取一些非常有“创意”的措施使得KPI恢复正常,包括:降低软件发布频度或者延长发布时间,从而进行更多冗余的测试;或者通过和客户现场支持团队“协商”,将若干客户问题合并在一个故障中进行报告,等等。这些举措的确能够使得这个KPI达到一个“漂亮”的结果,但是却离“提升软件质量,更快更好地服务客户”的初衷越来越远。