软件部门绩效考核办法
公司新来了一位阿里的人力资源的大牛，为公司带来了阿里的考核文化。其实对于我来说，刚开始挺反感这样的考核机制的，但是仔细的分析起来，要想做好一个部门的负责人，或者是项目经理，或者说要管理好团队，最后也是对普通开发人员来说，如何激励自己不断的提高自己的技术水平，确实也是需要这样的一套机制的。我姑且把这套暂定的制度贴到这里，如果有想成为部分负责人的同学，可以相互借鉴。其实我倒是不知道一个大的公司，到底是如何考核员工的。难不成都是这样的吗？
一、绩效考核系数、绩效工资
| 绩效分 | 绩效系数 |
|---|---|
| ＞=100 | 1.3 |
| 95~99 | 1.15 |
| 85~94 | 1 |
| 80~84 | 0.9 |
| 75~79 | 0.8 |
| 70~74 | 0.7 |
| 60~69 | 0.5 |
| 40~59 | 0.35 |
| ＜=39 | 0 |
绩效系数乘以每个员工的总绩效工资即为每月得到的绩效工资。
从2020年5月起，信息部所有员工的绩效工资为总薪的35%，如某员工的总薪为10000元，其绩效总薪为3500元。
二、绩效考核办法
1、本部门每月每位员工的初始绩效分为85分，根据绩效结果进行累计的加减分，月末得到的分数即为绩效考核分，绩效考核分对应的绩效系数即为员工绩效工资系数值
2、本部门绩效考核由部门负责人每日进行统计，人力资源部负责监督。每月末部门负责人将统计结果交人力资源部审核后交总经理审批。在过程中，总经理可直接对每日的绩效结果做监督。
三、积分指标（见下表）
基层员工
| 信息部员工行为/结果 | 积分 |
|---|---|
| 没完成当日工作下班/次 | -4 |
| 在每日检查工作节点时当日工作没按计划要求完成（较轻）/次 | -1 |
| 在每日检查工作节点时当日工作没按计划要求完成（一般）/次 | -2 |
| 在每日检查工作节点时当日工作没按计划要求完成（较重）/次 | -3 |
| 在每日检查工作节点时当日工作几乎没做/次 | -4 |
| 在每日检查工作节点时超额完成工作/次 | +2 |
| 在每日检查工作节点时超额完成超过1日的工作/次 | +4 |
| 在每日检查工作节点时完成工作并帮助其他员工完成工作/次 | +2 |
| 未在时间节点上交技术文档/次 | -3 |
| 在时间节点上交技术文档但未达到质量要求/次 | -1 |
| 在时间节点上交技术文档且该文档成为部门内文档的标准模板之一/次 | +3 |
| 在工作过程中发现开发过程中的产品、逻辑、技术、工作计划等问题，未及时上报，导致项目延期/次 | -3 |
| 在工作过程中发现产品、逻辑、技术等关键问题并及时上报，导致项目及时改善/次 | +2 |
| 项目进入部门内部测试阶段，发现的初级BUG在3个以上的 | -5 |
| 项目进入公司测试阶段，发现初级BUG在2个以上的 | -10 |
| 项目进入用户使用阶段，发现初级BUG在1个以上的 | -20 |
| 从内部测试到用户使用6个月，无出现一次初级BUG | +5 |
| 项目进入部门内部测试阶段，发现的非初级BUG在8个以上的 | -2 |
| 项目进入公司测试阶段，发现非初级BUG在6个以上的 | -5 |
| 项目进入用户使用阶段，发现初级BUG在1个以上的 | -10 |
| 从内部测试到用户使用6个月，无出现一次BUG | +10 |
部门负责人
| 信息部部门负责人行为/结果 | 积分 |
|---|---|
| 没有对部门员工进行每日的工作质量检查/天 | -5 |
| 对部门员工每日工作进行检查，但有漏检的/天 | -3 |
| 不按本制度每日对员工进行评分，或有明显的舞弊/天 | -4 |
| 无有效证据给员工加减分/天 | -2 |
| 相关考核文件、报表丢失的/次 | -10 |
| 给出员工加减分，并给员工做出有效工作指导建议的/天 | +1 |
| 部门无工作计划或工作计划粗制滥造/月 | -20 |
| 无法按部门工作计划布局员工工作计划/月 | -10 |
| 能让员工按部门计划调整自己工作计划，且工作计划有效执行的/月 | +5 |
| 员工对部门工作计划知晓，并对自己和相关工作岗位工作清晰的/月 | +3 |
| 部门文档管理杂乱无章，或缺失重要文档的 月 | -8 |
| 部门文档管理清晰的 月 | +4 |
| 月部门工作计划完成率＞=100%的 月 | +20 |
| 月部门工作计划完成率为95%的 月 | +10 |
| 月部门工作计划完成率为90%的 月 | +5 |
| 月部门工作计划完成率为75%以下的 月 | -15 |
| 月部门工作计划完成率为60%以下的 月 | -20 |
| 月部门工作计划完成率为50%以下的 月 | -30 |
| 月部门工作计划完成率为40%以下的 月 | -50 |
四、其它绩效管理办法
1、绩效系数为1.3可提前转正。
2、在试用期内有2次绩效系数为0.7或一次在0.5即为不合格，淘汰。
3、已转正员工连续两次绩效系数在0.7或0.5,或一年内有3次0.7或0.5，或只要发生1次0.35或0的绩效系数，即被淘汰，且没有劳动补偿。
4、连续3个月的绩效系数在1.15或1.3；或1年内累计5次绩效系数在1.15或1.3，且最多只有一次的0.8的绩效系数，没有0.7及以下的绩效系数，在公司未执行职等职级晋升的前提下，其员工总薪上涨15% 。
注：此绩效管理办法单独作用于信息部，且是在绩效体系未完善前的特殊制度，如对本制度有改进将另行讲解说明
五、附录
初级BUG的定义：
1.根据项目损害程度划分
分为本人工作延迟、3人内工作延迟、团队整体工作延迟、数据性错误、使用性错误、感知性错误、结构性错误、逻辑性错误、财务性错误。其中，结构性是指整个软件的结构发生了错误，这一般是产品经理和技术负责人的责任；财务性错误指用户使用后因为代码问题用户和我们之前的营收出现了问题，对我们或用户造成了损失；感知基本上是视觉性的错误，如果软件带听觉再加上听觉。
2.根据项目功能结构划分
统一性、容错性、互动性、用户体验、兼容性、分辨率、易用性、错别字、安全性、界面UI、资源释放、性能体验
(1) 统一性
不要在软件中使用中英文混合的提示，比如对于用户的操作提示，不要一会用“error”一会用“错误”；一会用“succeed”另一会用“成功”总之要统一。
(2) 容错性
- 对于保存提交的数据输入信息，在输入长度方面要么就限制用户的输入，要么就在客户端给出用户的醒目的提示、判断。不要出现系统崩溃，保存缓慢系统等无法响应等现象。
- 长度校验；
- 数字、字母、日期、附件的大小等等的校验；
- 范围的校验；
(3) 互动性
在要求用户大量输入信息后，点击“保存”或者“提交”按钮，仅仅是因为用户的某个地方输入或者选中不正确，点击“确定”后发现所有输入的内容全部都被清空了；
对于所有的删除信息在删除之前都要给出是否删除确认的提示或者放弃的提示。扩展下：不仅仅是删除，包括危险操作之前、或者改变数据状态等；
如填写资料有错误的时候，应该能够提示错误的位置，让用户知道到底是哪些地方输入的不正确；
软件在需要用户输入信息的时候，特别是填写个人信息的资料的时候，必填项后面，一律要用*等醒目的提示。让用户知道这个地方是必填写的；
下拉框不选值的时候，应该有个默认值，并且要多检查程序中多处下拉框，因为很多情况下下拉框取不到值；
新增/修改信息保存提交后，系统应该给出“保存/提交/修改成功”提示信息，并自动更新显示。
重复提交，用户提交数据页面，用户有可能连续多次点击提交按钮，造成数据的重复提交
(4) 用户体验
页面上的提示信息要让用户明白，比如不要对用户使用“记录”、“字段”等一些很专业的术语；
程序人员经常在程序中加入调试信息，后来又忘记删除这些调试信息，这些调试信息给用户造成误解，认为该调试信息是系统严重的Bug，程序提交测试之前，程序员必须要删除该类型的调试信息。
对于编辑功能，点击“编辑”后，所有的值都要默认保持编辑前的初始值。比如某员工的籍贯是“上海市”，点击“编辑”按钮后，在籍贯这个地方默认的仍然是“上海市”。其他字段信息也是如此。
(5) 兼容性
操作系统版本:包括Andoird版本，iOS版本
网络类型:比如Wifi、3G、4G下的功能情况
(6) 分辨率
客户端的页面在市场上主流显示器的分辨率显示下页面显示要正常，包括滚动条也要正常
(7) 易用性
对于要求用户大量录入信息的页面，要支持Tab键的输入，Tab键的走向要一般要遵循从做左到右，从上到下的的原则。
(8) 错别字
(9) 安全性
- SQL注入
- 绕过登录
- XSS
- 长时间不操作重新登录
- HTML代入注入错误;
(10) 界面UI
- 界面布局缺陷：比如“删除”按钮和“保存”按钮挨得很近（这样很容易造成用户的误操作）。（注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。另外，注意按钮的大小是合理一致。
- 界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员，很容易误按，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。
(11) 资源释放
对于数据库有连接打开的地方，使用完毕要关闭。文件打开也要关闭。否则会造成系统资源内存泄漏。
(12) 性能
对于经常大数据量的查询，对于查询的关键字段是不是要考虑使用到索引等或者其它方法提高查询的效率，2-5-8原则。
日报质量考核标准
日报提交的格式应该有条理，分条列出每日工作内容，并编号。每条日报中包含三部分。第一部分为总结这条日报的内容，第二部分为工作内容的具体描述，第三部分可以描述完成的程度，或者是验证的方式。
1.功能类
功能的实现相关的日报条目，应具体写明功能的实现内容，包括但不限于按钮数量，页面数量，功能数量，最好写明功能实现的难易程度，实现的效果，以及验证方法。
2.学习类
按技术文档标准规范，提交技术文档。
3.Bug类
根据Bug类型的难易程度，分为初级Bug，中级Bug和高级Bug。根据初级Bug的定义，日报中应不少于10处，中级高级Bug应写明解决问题的思路和方法，若日报中写明了解决多处初级Bug，但是数量不够，则认为工作不饱和。
4.会议类
与同事讨论问题，或者参加会议，应编写讨论时长，提交会议纪要或者是问题讨论过程及结论，必要时应注明开始时间及结束时间，缺少相关内容为扣分项。
5.测试类
对项目或者功能进行全方位的测试，小范围的测试，应提交测试报告，测试方法，测试过程，测试的结果，问题的类型和描述等，缺少相关内容为扣分项。
6.建议类
对公司规定和团队建设提出具有建设性意见的建议，能促进团队合作、任务推进、公司发展，并得到领导或多数同事积极支持的意见和建议。
7.开发类
同一功能，前天已完成的内容，今天重新修改，应该写明修改的目的，修改的内容，与上一版本的具体差别，如果有，可以写明修改的代码量或者是时长。
其他公司的考核指标
