Back to KPI

See also Human_Resource

以 jira 上分配的关键任务的完成情况作为研发绩效考核的核心指标

为什么以 jira 上分配的关键任务的完成情况作为研发绩效考核的核心指标?

1. KISS 原则

简单易懂。

为啥不定三个指标?因为一个比三个少(微笑)

更加突出了重点:要在关键任务上下足功夫,尽最大努力去确保按时交付关键任务。

2. 怎么评价哪个任务是关键任务?

研发的任务很多,研究新技术、开发新功能、支持客户等等,按周统计会有很多事情要做。哪个是关键任务呢?我们会鼓励小伙伴们最先去解决能提升公司价值和竞争力的问题。比如 sprint 冲刺中的任务、能够提升现有开发效率的工具、能帮助到其他小伙伴了解现有系统的技术 wiki 和业务知识 wiki 等等。

谁来评价?当你带着这个思考开始你工作的时候,有没有一种身剑合一的感觉呢?当你被安排了多个任务的时候,你可以去评估哪个任务更关键,从而和 leader 以此为基础协商任务优先级和计划自己投入的程度。当你对关键任务的认定有疑问时,也可以和你的leader,业务部门,周围的小伙伴商量,对任务的判断达成共识。

3. 客观性

JIRA上的任务安排对所有任务干系人可浏览和发表评价的,任务的过程(Jira comments)和结果(code repo/wiki)都有客观存在的记录。

即使某个判断、结论当时做错了,今后还可以回过头来看,而不是脑海中一个模糊不清的记忆。

4. 为什么考核和怎么考核按时交付?

99%以上的人都低估了软件研发的进度。

一个功能,自己估计一周搞定,而现实往往是两周都没法搞定。因为整体思路、设计很清楚,设计文档可以看上去很漂亮,但落实到每一个细节、每一处逻辑的判断,都需要思考、编码、测试,还需要与其他成员协调沟通。

在我们的职业生涯里,没有听说过哪个软件研发项目是提前完成的。这是软件行业普遍存在的问题,因此进度的保证才是核心问题。

在到期日交付基本完工的任务是底线;彻底完成是良好;彻底完成且有单元测试及性能测试报告是优秀。

5. 定义清晰的交付物是考核的基础

对关键任务的评价要基于一个重要前提,就是对任何一个任务,产出或提交物需要定义清楚。对软件研发而言,提交物应该明确包括代码(tag@repo)、API和测试用例。

除此之外,还希望小伙伴们继续完善产品设计 wiki,用来对内或对外介绍自己开发的模块的功能和特点,把自己产品或技术的亮点、技术实现的细节等清晰地表达出来。

6. 怎样保障关键任务的质量?

我们不以代码质量作为考核依据是因为很难有一份客观且得到全部小伙伴认可的质量标准。

我们更希望借助于CI/CD(持续集成、持续部署)等现代化的工具来保证。如果递交的代码无法合并、无法通过自动化测试,无法达到规定的代码覆盖率,那一项任务自然是不能记为完成的。

我们不纠结一个模块内部的具体实现,是不是符合编码风格,而更看重测试结果、看重性能报告。希望以结果来驱动优化、驱动质量的提升。

7. 迭代与持续改进

迭代是敏捷软件开发普遍采用的策略,其中的精髓就是快速交付和持续改进。

每个迭代有进步就可以。我们不期望一下子有质的飞跃,更希望看到的是“天天进步”。

除了功能的迭代外,代码的质量更是如此,随着时间的推移,测试的覆盖率只能上升,不能下降;系统性能只能上升,不能下降。

我们信奉这一点:只要持续地努力,就一定能做出顶级的产品!

8. Reference


CategoryProcess

MainWiki: JIRA_Key_Tasks_as_KPI (last edited 2020-05-25 04:05:23 by twotwo)