评价原则
- 做的东西越重要，评价越高。
- 做的东西越紧急，评价越高。
- 做的东西越好，评价越高。
- 做的东西越多，评价越高。
评分构成
评价分成工作结果和工作态度两部分。
工作结果
| 评分 | 说明 |
|---|---|
| A+ | 完成创新性工作，提高团队工作效率。（很难获得） |
| A | 完成重要性工作。 |
| B+ | 工作成果/产出超出预期目标。 |
| B | 能按要求完成职责范围内的工作内容。 |
| C | 工作成果/产出有待改善。 |
| D | 工作中出现严重失误。（考虑淘汰） |
评分B，同时满足以下要求：
- 能独立负责功能。
- 功能按时转测。
- 转测质量策划基本满意。
- 转测后bug修复情况测试基本满意。
- 未出现低级bug，未出现严重bug。
评分降级考虑：
- 因个人原因导致功能延期转测，评分至少降一级。
- 非个人原因，但是多次出现功能延期转测，会被认为是个人原因，评分至少降一级。
- 出现低级bug和严重bug，评分至少降一级。
独立负责：
最多告诉一个设计的方向，就可以自己实现，自己处理问题。
按时转测：
转测时间超过第二天凌晨2:30，或者转测时间延期，均属于不能按时转测。转测前1-2天才发现时间不够，需要修改转测时间，会被认为转测时间延期。
不能按时转测的功能需要备注原因。
策划基本满意：
没有吐槽。
测试基本满意：
没有吐槽。
低级bug举例：
- 不校验前端参数。
- 用==判断字符串是否相等。
严重bug举例：
- 资源被刷。
- 游戏进不去。
- 内存溢出。
- cpu 100%。
评分B+，满足一个或多个要求：
- 能够完成超出岗位要求的功能。
- 能够解决紧急性问题。
- 代码的质量高。
- 其他部门主管评价高。
超出岗位要求的功能：
初级人员能做中级人员的工作，中级人员能做高级人员的工作，高级人员能做主程的工作。
紧急性问题举例：
- 策划在转测当天增加临时优化，改动到功能的核心逻辑，依然能够按时交付功能。
- 同事临时有事请假，或者忙不过来，能够帮忙分担他的工作。
高质量代码举例：
- 代码通用性强，易扩展。
- 单元测试完善，发奖有对应的单元测试，玩家行为有对应的单元测试。
- 代码可读性强，注释详尽，变量、方法名、类名命名清晰，换行和缩进恰当。
评分A，满足一个或多个要求：
- 能够解决重要性问题。
重要性问题举例：
- 从整个游戏来看，游戏框架、跨服、战斗、大型系统、基础模块等都是游戏中重要的功能。
- 从单个版本来看，比如养鲲版本，发版发到凌晨7点，养鲲系统还有问题未解决，大家都认为版本发不出来了，负责养鲲系统的同事继续调试了一段时间，最终把问题解决，保证了版本的正常更新。
- 提升效率的工具，比如Jenkins发车工具，自动提取日志注释的工具。
评分A+，满足一个或多个要求：
- 大幅提高团队的工作效率。
评分D，满足一个或多个要求：
暂无。
工作态度
| 评分 | 说明 |
|---|---|
| B+ | 态度积极，责任心强。 |
| B | 表现符合要求。 |
| C | 态度有待改善，责任心弱。 |
| D | 态度差。（考虑淘汰） |
评分B+，满足一个或多个要求：
- 主动发现和解决项目中的问题。
- 花时间帮别人解决问题。
- 工作中不懂的东西会利用业余时间学习和研究。
评分C，满足一个或多个要求：
- 工作拖延。
- 工作推诿。
- 功能群消息经常不回复。
- 交代的任务忘记执行，或者执行了不反馈。
- 无脑复制粘贴代码。
工作拖延举例：
- 接到功能后，先玩两天手机再做功能。
- 转测时遗留一些工作细节，比如红点。
- 转测后几天依然还有细节未完善。
工作推诿举例：
- 能让别人做的事情都让别人做。
评分D，满足一个或多个要求：
- 正式谈话中表现出不诚信。
- 和同事吵架或打架。
- 不尊重上级和其他部门主管。
- 交代的任务故意不执行。
评价方式
每个人的版本评分介于工作结果的评分和工作态度的评分之间，取哪一个评分由服务端负责人决定。比如工作结果评分为B，工作态度评分为C，最终的评分可以是B，也可以是C。
每个人的评分都要对应具体的点来证明。
