先讲一个真实的故事。一家初创公司，研发团队初具规模，抵不住业务部门想法多、变化快，开发速度赶不上业务要求。开发老大于是想要通过拉长业务部门需求到达研发团队的前置时间来缓解研发部门的压力，比如规范需求说明文档、增加需求审批节点等。一系列操作搞得业务部门怨声载道，反而加深了研发团队和业务部门的矛盾。
开发老大的初衷其实是通过提高业务部门提需求的成本来提高需求质量，但站在业务人员的角度来说，处理这些无法给他们带来价值的流程无异于雪上加霜。这个故事发生在十年前，如今敏捷成熟度日益提高，再来翻看这个故事，显然业务部门和研发部门之间缺少了一个很重要的角色/环节——产品经理/需求分析，来协调或者说平衡业务和交付。
WHY / 为什么要排优先级
排优先级是产品经理最重要的日常工作之一，是交付项目正常运行的第一驱动力，原因有二：
1.开发团队的交付速率永远赶不上业务要求，因为新需求一拍脑袋就出来了，但是开发测试上线显然需要更长时间。
2.在有限的资源下，我们往往只能做选择，排优先级是为了确保将有限的资源用在正确的事情上。
WHAT / 什么是排优先级
输入：业务全景图（业务全景图是一种能显示产品或服务基于时间的演进计划的可视化图表，通常以月或季度为单位，关注长期目标。我们应尽量确保业务全景图足够简单、便于理解、与产品策略一致。我们需要将从业务部门收集到的所有需求按期望的时间线整理成一张业务全景图，并定期进行更新）。
输出：按优先级排序的待办事项列表（产品待办事项列表包含所有真正需要开发团队处理的一个个具体任务，每个任务都带有估算且按优先级排序。我们需要提前预估开发团队的生产力，并决定我们每次需要产出多长的待办列表）。
排优先级就是从输入到输出的过程。
How / 如何排优先级
想想产品经理日常工作中会遇到的问题：
1.不同的业务部门收集到的不同的需求，每个都很急，哪个都得罪不起，如何抉择？
2.业务需求太多，每天赶需求，技术债越堆越高，怎么办？
优先级的决定因素
1.业务目标
研发团队需要交付的成果应该以业务目标为导向，因而要避免直接根据业务部门的优先级对收集到的需求进行排序。推荐的做法是，将业务目标转化成具体可衡量的关键业务指标，根据关键指标来制定迭代计划。依据这个底层逻辑梳理出来的优先级，才能经得住不同业务部门的质疑。
2.用户价值和开发工作量的权衡
除了能直接提升业务指标的功能，研发部门还需要处理很多其他的事务，比如用户体验相关的改进，修bug，技术债等。这些事务的影响力不如那些能直接提升业务指标的功能，但却是不能不做的。
一个很好的实践是，根据项目的实际情况，对不同类型的事务进行清晰的定义和划分，提前确定每个迭代用于不同类型事务的研发工作量占比，比如每个迭代60%用于业务需求卡，15%用于用户体验相关的改进需求卡，10%用于bug卡，15%用于技术债。这个占比在不同阶段可以基于项目实际情况动态调整，但必须是跨部门拉通并严格遵守执行的。
常用方法：
OKR
权衡协商
Trade off 模版
价值/工作量象限分析
Value effort matrix 模版
评分排序
Sorting&Ranking 模版
When&Who / 何时&和谁进行优先级排序
定期和干系人组织会议分享和拉通，确保关键干系人参与决策过程，其他干系人对过程和结果可视、透明。
网友评论