PARID因素主要是在制定计划的时候，对于项目中的需求需要考虑的相关因素。他们分别是优先级（Prority），假设（Asssumption），风险（Risk），问题（Issue）和依赖（Dependency）。

优先级（Prority）

需求的优先级是在项目中用来参考资源倾斜和什么时候开始实现的重要参考点，没有之一。在制定计划和实现需求的时候，这个是一个很重要的参考因素。按照PMPBOK书中的步骤来讲，做计划第一步是将需求排列优先级，然后再进行后续操作。在Scrum的敏捷规划中，product backlog list中有个重要的属性就是优先级别。

假设（Asssumption）

需求有很多种使用场景，在刚开始实现的时候，没有产品经理敢保证已经考虑到了所有的适用场景。很多需求在刚提出的时候，只是考虑到了当前的适用场景。产品经理在设计的时候，需要假设很多种不同的适用场景条件，尽量全的考虑所有的适用场景。大厂的产品经理为什么会比小厂的吃香，那是因为同样的产品，大厂因为用户的场景丰富，产品经理会充分考虑到对应的产品的假设适用场景，以规避产品在使用中的各种异常不友好的场景。

风险（Risk）

任何一个产品在提出一个新的需求的时候，就有可能产生一些新的隐藏风险。

我们先来看下风险的定义：

    风险就是生产目的与劳动成果之间的不确定性。大致有两层含义，一种定义是强调风险表现为收益不确定性；另一种定义则强调风险表现为成本或代价的不确定性。

新的需求，产生了新的组合场景，每个产品都是由一系列的需求组合而成。理论上来讲，需求的增加，将导致信息的熵增。而穷尽所有的场景，就要使用笛卡尔积的方式来处理，大家知道每个系统的需求都是一个象棋的棋盘格子放不下的。所以很多时候，在设计的时候都是抓大放小（时间、成本考虑）。剩下的那些不确定性就需要大家根据团队和业内经验来判别了，能识别出来的就放到风险等级册中。团队成员根据相关的风险来判别当前需求是否需要立即实现，是否需要实现。如果谁告诉你加这个需求没有一点风险，那你就要准备好铺盖了。

问题（Issue）

老司机可能会告诉你，所有的产品经理都是纸老虎。很多产品经理在考虑问题的时候，只是站在当前业务场景来思考，没有跳出当前的格局思维，或者没有考虑到技术的可实现性。很简单的一个例子：平安科技的产品提的那个根据手机壳颜色动态改变手机产品的背景色的需求。

一个好的开发，应该是在做需求评审的时候，要学会提出正确的问题。《学会提问》这本书讲的就比较好。我们需要从不同的产品使用场景和技术的可实现性等多方面进行提问，很有可能产品经理经验丰富。已经考虑到了相关的问题，但是谁有知道呢？早的预防，总比晚的亡羊补牢要好。

Dependency依赖

需求没有光棍！没有一个需求是独立存在的。如果一定有，那一定是有问题的。如果大家开发中使用过比较正规的瀑布式方式开发的话，会在详细设计里面看到每个任务有一输入项和输出项（有的名字可能不是这样，但是意思差不多）。一个需求要么被依赖，要么依赖其它需求。

 

在制定开发计划的时候，对于需求的分析，建议按照上面的PARID五要素的方式进行分析。相信这样，你的需求不会给你的计划造成很大的麻烦。