2.3 需求分析 - 需求优先级排序（下）

​优先级排序（上）我们聊了怎样把需求进行排序，但是这是评审前我们自己对于需求的一个预处理，得到第一次排序后，咱们需要组织一个开发前的评审会，当然有的团队仅仅是拉上开发聊一聊，目的是评估开发难度，得出最后的需求优先级与排期。

正片开始。

1. 开发难度评估

评审会议上，最重要的问题就是确认好开发成本，这里我们常用的方法是将需求按难度（difficult）等级从高到低排序，可以记D1、D2、D3，D1代表成本最低，D2中等，D3代表成本最高，注意，这里和需求的P1、2、3是相反的。

举个例子吧，这里有7个需求：1、2、...、7

需求优先级评定：
P1：1、3、4
P2：2、5
P3：6、7

开发成本评定：
D1：2、3、4
D2：1、6、7
D3：5

当两个顺序排完之后，咱们怎么处理呢？这里咱们可以将两者进行组合，类似矩阵：

需求优先级-开发成本矩阵

矩阵的目的呢，只是为了让需求分级更直观，习惯了之后其实也可以直接估算P1中需求的D123，然后P2、P3同理。对了，矩阵的优先级如下：

需求优先级-开发成本矩阵（优先级顺序）

优先级1>2>3>......>8>9

由此则得出进入开发的需求优先级，接下来的就是严格执行以及追排期，一定要拿到时间节点！！并且之后本次迭代不再加入新需求。

并且在追排期的时候，也是检验产品经理前期功力深厚与否的时候了。

可能出现三类问题：

• 需求多，开发没按时做完；

• 需求变动，反复调整；

• 新需求加入，未能按原计划完成。

大伙儿可以思考思考自己以前是否出现过这些问题。其实解决这些问题也并不难：

• 需求多，产品就要扛起要资源的大旗，或者是起初就考虑资源问题进行需求的适当调整或者压缩；如果两者都不是，则考虑是开发的责任了。

• 需求变动导致反复调整，一般都是由于需求没有思考透彻，方案不完整导致，这是产品基本功不到位了，需要好好反思，也不排除开发水平问题。如果是产品经理自身的问题，就需要考虑是否思考透彻了各个流程图，是否流程已经最优，或是信息结构图是否构思完整。一定优先思考业务逻辑，切忌思考不透彻就动手画原型！！！

• 新需求的把控一定要掌控好，产品策划/经理应该要有版本把控意识，就像是军令状，良好的版本意识有助于在团队中建立威信。有新需求考虑加入需求池进行评估，并且明确回复需求方版本规划相关事宜，说明缘由。有时候需求进入需求池冷静一下，会更能发现价值。

2. 一些经验希望对你有帮助

a、方案可行性最好是提前和开发进行讨论，但是一定要说明需求背景和目的，让其与咱们有一样的价值观，这是团队协作，不多说。一般情况下，开发能够从他们的视角给予他的想法，这种视角看的问题是很实际的，很细节的，并且很容易一针见血的。

b、有没有更好的方案。一般来说，流程和逻辑是有最优的，到了最后的实际设计是可以产出多套方案和UI、UX讨论的。这里还有个个人觉得特别有奇效的方法，同样的价值观下，先拿方案跟开发一起看，看是否有更多可行方案。这些方案未必完整周全，但是他们提供的思路可行性一般是很高的。

c、和开发沟通了解，方案会影响到哪些系统和哪些环节。有些公司产品线多，很有可能波及其他产品，如果对方不清楚，很大概率后面会撕逼，然后铁定延期，所以要和开发了解后早点做好沟通工作。

d、方案成本。需要多少时间 、资源成本，开发一般会给自己富余的时间，如果技术出身的产品可以适当自己评估，从个人经验说，我们最好是选择开发给的时间上加1-2天，一来是给自己团队留下缓冲时间，避免意外问题，二是许诺要做到自己有把握，同时对团队来说，开发也会更喜欢你。

想要更多干货分享就快来关注我的个人公众号吧！！
花名：馒头
个人公众号：我是馒头
座右铭：博学之，审问之，慎思之，明辨之，笃行之