管理｜KPI，互联网企业管理的神器

一、我7、8、9月份的KPI结果分析

7月份

7月份KPI

7月份的主要问题总结和后面的改进方案如下：

问题1：APP页面呈现的效果与UI设计稿差距很大。

解决：在做过程验收时，UI设计就参与进去。

问题2：产品经理在做产品验收时出现很多无数据的空页面，导致验收无法进行。

解决：把填充验收测试数据做到整个产品研发计划中。

问题3：过程管理极差。

解决：在最开始的过程中，我其实每周都会定期询问具体的产品研发的进程，当然是对照禅道中在项目开始时制定的研发计划，每次也会得到研发“本周进程已完成的回答”，然而在做月度验收时发展研发遗漏了很多功能点，设置遗漏了一些主流程页面。改进的方案是在做研发计划时要求产品经理出一份“测试用例”，我在做阶段性验收时一个一个对照测试用例去验收，把验收工作具体化。而不只是得到对方的口头完成。

8月份

8月份KPI

8月份的主要问题总结和后面的改进方案如下：

问题1：完成度不达标，主流程Bug管控极差，质量有待提高。

解决：这一次的主要问题是Bug太多，我们后面的解决方案是把所有的bug分配到每一天，我们当时的安排是每天完成15-20个禅道上的bug，最主要的原则是当天的bug一定要在当天处理了，在整个8月的后半个月，我们整个研发部和产品部主要负责人就没有在晚上11点之前下过班。虽然那段时间大家都很辛苦，但并不痛苦，主要原因就是量化bug，及时鼓励和肯定。头天晚上十二点回家，第二天早上9点来公司上班时依旧精神饱满。

问题2：部分开发对产品的理解不达标。

解决：当时出现这个问题的主要原因是因为时间太赶，具体的研发对产品的部分规则不了解的情况下还是舍不得花时间做评审会议，都争取更多的时间进行写代码的工作，事实证明对产品的需求理解一点也马虎不得，要舍得花时间。

问题3：临上线出现无法收藏的问题。

解决：所有的功能都需要提前做到并发测试，特别是核心功能。

问题4：风控不到位。

解决：出现这个原因是因为前端工程师的临时离职，而我没有一个很好的风险意识去提前安排以保障项目的进度不受到影响。从这里得到一句话“管理就是把不确定的东西给确定”。

问题5：交付！！！没有交付的思考对公司来说没有任何意义。

9月份

9月份KPI

9月份的主要问题总结和后面的改进方案如下：

问题1：缺统筹规划。

解决：这块主要的问题是我在梳理所有上个月所有遗留的工作，对不予处理的很多bug没有一个最终的解决方案。后面的解决方案是我梳理了所有的未完成的功能和未解决的bug，包括“延期处理”的不重要的页面优化，包括因为产品调整而“废弃”的功能点。整理成一个列表，再拉起大家一个开会确定，给所有任务一个终结的解决方案：关闭或确定要处理的时间点。如下图。

不要留待定的任务

问题2：产品研发配合不足，需求传达工作要提高。

解决：经过这次扣分，我拉起产品和研发开了一个会议，确定了一个产品研发的沟通规则：产品负责人要确保自己的需求研发都理解清楚啦，一旦沟通之后还有理解不清楚的一定要拉起我做一个需求确定会议。并且如果沟通时出现问题时，请找我一起进行二次沟通，而不是应该沟通不快停止沟通。当然，在这之后我也会特意留心产品和研发沟通的各种场景，一旦发现有不对劲的时候我也会给予及时的处理。

问题3：缺后续计划。

解决：对于所有的技术难点调研型工作，一定要有一个有任务终结的计划，而不只是完成一个单一的技术难点调研，单一的技术难点调研是没有意义的。

问题4：上线通知缺失。

解决：原因是官网上线时没有给公司的每个人发送项目上线邮件。

好，以上就是我们在7、8、9月份的我的KPI情况。

我们的规则是每月的28号确定下个月的KPI，同时给本月的KPI进行打分，并且要一对一进行KPI结果的面谈。这样的模式走下来，我觉得对我的收获的很大的。

这个KPI的尺子，一来可以衡量每一个同事的业绩指标，二来可以让大家很清楚每一个月的重点是什么。

二、KPI的解释

KPI的用途：

1）根据组织的发展规划/目标计划来确定部门/个人的业绩指标

2）监测与业绩目标有关的运作过程

3）及时发现潜在的问题，发现需要改进的领域，并反馈给相应部门/个人

4）KPI输出是绩效评价的基础和依据

KPI的效果：

1）把个人和部门的目标与公司整体的目标联系起来

2）对于管理者而言，阶段性地对部门/个人的KPI输出进行评价和控制，可引导正确的目标发展

3）集中测量公司所需要的行为

4）定量和定性地对直接创造利润和间接创造利润的贡献作出评估