持续改进｜需求优先级评估模型
上篇说到订单中心团队通过迭代回顾，找到并共识了急需改进的事项-需求插队，并承诺在下个迭代改进执行。
指路前篇→《“迭代回顾”--团队持续改进的助推剂》，可在阅读完本文后在文章末尾点击【阅读原文】。
今天就让我们走进中台研发部的订单中心团队，一起来看看他们的“需求优先级”模型及应用实践。
“需求”是团队工作的源头，对需求做好优先级排序不单单是产品经理个人核心技能的体现，更是影响团队生产效率和价值的重要因素。
相信很多团队都遇到过业务期望高、开发时间短、资源有限等问题，此时团队需要权衡需求价值、人力资源、预算等约束条件，快速评估每个功能的相对重要性，做好优先级排序，才能有助于团队规划，以最少的资源创造最大的价值。
产品经理韩st、技术负责人胡jg、项目经理蒋f、李yy从订单中心的产品结构、技术框架等实际情况出发，并结合Kano模型、WSJF模型等主流需求优先级评估方法，按照“等级”、“目标”、“战略契合度”、“需求提出方/关注人”、“紧迫度”五个因素进行综合考量。
团队通过对需求的等级进行评分：
| 等级 | 得分 |
|---|---|
| 核心需求 | 5 |
| 必要需求 | 4 |
| 扩展需求 | 3 |
| 关联需求 | 2 |
| 调优需求 | 1 |
团队通过对需求的价值目标进行评分：
| 目标 | 得分 |
|---|---|
| 创造营收 | 5 |
| 降低成本 | 4 |
| 对标竞品 | 3 |
| 用户增长 | 2 |
| 改善体验 | 1 |
团队通过对需求与战略的契合度进行评分：
| 战略契合度 | 得分 |
|---|---|
| 管理层指派 | 5 |
| 重点项目 | 4 |
| 普通项目 | 3 |
| 部门OKR关联事项 | 2 |
| 日常工作中由各团队发起的需求 | 1 |
团队通过对提出方/关注人所在的职级进行评分：
| 提出方/关注人 | 得分 |
|---|---|
| 董事长/总裁办 | 5 |
| 一级部门负责人 | 4 |
| 二级部门负责人 | 3 |
| 三级部门负责人 | 2 |
| 员工 | 1 |
团队通过业务方提出的期望完成时间进行评分：
| 紧迫度 | 得分 |
|---|---|
| 业务方要求一周内完成 | 5 |
| 业务方要求二周内完成 | 4 |
| 业务方要求三周内完成 | 3 |
| 业务方要求四周内完成 | 2 |
| 业务方要求五周内完成 | 1 |
以上是影响需求优先级的5个因素评分标准，当然这五个维度也有主次之分，对应不同的权重系数，进而计算出需求优先级得分：
| 影响因素 | 系数 |
|---|---|
| 等级 | X1% |
| 目标 | X2% |
| 战略契合度 | X3% |
| 需求提出方/关注人 | X4% |
| 紧迫度 | X5% |
需求优先级得分=等级*X1%+目标*X2%+战屡契合度*X3%+需求提出方/关注人*X4%+紧迫度*X5%
（PS：大家可根据工作中的实际情况自行调整系数，只要确保X1+X2+X3+X4+X5=100）
订单中心的“需求优先级”模型，从订单中心日常工作的客观环境及干系方出发，做到了最大限度的兼容，不仅方便了产品经理、技术负责人对需求做优先级排序，同时也让团队成员对当前的工作优先级能一目了然，做到心中有数。
与此同时该模型还具备可扩展性，通过增加“工作量”及“风险”还可以帮助团队输出对应的需求排期。
•大数据测试｜中通科技大数据质量保障探索与实践（上）
•质量度量｜中通科技全面质量管理实践探索
•中间件测试｜ZCAT监控平台测试探索与实践
•扩展Kubernetes调度器（上）
欢迎各位技术大佬向本公众号积极投稿，提升经验分享、信息互通的技术交流氛围，共同解决技术难题、共同进步！（投稿咨询请联系科技与信息中心助理室 徐蕊）