如何确认产品需求文档PRD

这里要讲的并不是如何写出一份正确的PRD,而是如何去确认PRD里面的需求,即PRD已经有了,需要一个Review的过程。在产品人员日常的工作当中,需求变动是经常发生的事情,都可以是家常便饭了,哪个产品的需求不变动几次,都怀疑这个产品是否做错了,或者需求收集有误。不过我们的终极目标就是尽可能的在第一次需求收集、分析、设计后不再变动,或者尽量少的被变动。这就需要两个条件,一是产品人员在前期需求收集分析的过程当中要考虑的尽量全面;二是在制定PRD的时候要仔细与各方人员确认。这两点所处的过程点不一样,侧重点也就会有一些不一样。下面结合自身工作经验,描述如下确认过程。

在谈PRD之前,首先需要关心一下BRD。BRD的全称为:Business Requirement Document,根据英文直译过来就是商业需求文档的意思;PRD的全称为:Product Requirement Document,是产品需求文档的意思。BRD和MRD(Market Requirement Document,市场需求文档),PRD一起被认为是从市场到产品需要建立的文档规范。BRD指的就是基于商业目标或价值所描述的产品需求内容文档,是产品生命周期中最早的文档,再早就应该是脑中的构思了,其内容涉及市场分析,销售策略,盈利预测等,一般比较短小精炼,没有产品细节。BRD是PRD的重要参考依据,所以要制定正确的PRD,必须要有明确的BRD,这里就需要对BRD的内容先进行确认,所以我建议,在做PRD之前,所有的产品相关人员,首先要对BRD进行一轮确认和讨论。其实一个产品是否要做,领导一般只看BRD,因此这里的内容确认了之后,也是领导最终确认的内容,能有效保证后面不再有大的变动。

有了BRD之后就可以做PRD了,这个过程相信所有的产品人员都很熟悉,分析需求,设计原型,最终书写文档等等,大概的一个过程就是这个样子,八九不离十吧,可能有的地方要求的更高,也可能有的地方直接就开始写文档了。在PRD基本完成之后,要进行第一次确认。可以拿着原型,或者直接拿着文档和相关负责需求的人员确认,如产品经理,产品设计,UI设计等等,这一步只是讨论需求的,对已经知道的需求清单上的所有需求逐一确认,讨论这些点的实现方式,及当前这样的设计是否合理。我的观点是首先要内部达成一致,说句不好听的,攘外必先安内嘛,设计出来的东西内部人员都无法达到一致的话,放出去的意见会更多,所以还不如先在内部来一轮头脑风暴。这个阶段如果有需求方可以参加的话,最好让提出需求的人也参加一下,这样的话就是直接和目标用户确认需求了。

在经过一轮的内部确认或者用户确认后,基本上整个产品的需求框架就定下来了,剩下来的就是和开发+测试人员进行二次确认,主要确认技术实现角度看现在的需求设计是否合理,以及一些扩展性方面的考虑。其实这个步骤主要是和开发测试人员讲解需求,有时候他们会提一些实现上的逻辑需求,这个是需要参考他们的意见的。再者就是需要做好沟通,预备好将来变更需求的可能性。这个过程确认下来没有问题的话,PRD就可以提交开发测试那边进行排期了。

接下来测试会根据PRD给出一个test case list,即测试用例列表,这个是根据PRD的需求来进行确认设计的,等于说是对需求的一个实际验证过程,因此是由利于产品人员去发现问题的,确认的过程即是对设计的一次验证,看实际的验证会发现设计的是否合理,是否全面,是否完善,当然只能做到尽量的完善,100%的完善,相信这个是所有产品人员努力的方向。这里最好再组织一次测试用例的review,进一步检查之前的设计有无纰漏,也可看看测试用例设计是否合理,能否完全验证PRD中的需求。

基本上整个的确认过程就是:BRD review,PRD一次review,PRD二次review,测试用例review。两次PRD确认的对象是不一样的,个人感觉这样的过程还是比较好的,可根据自己的实际情况来,像我之前所在的公司就是全部只确认一次,没有BRD。这样过程如果是否全新的产品,都可以做到有需求大家一起讨论决定,个人觉得这样是比较好的,也比较规范,文档都能沉淀下来。如果是用户提出来的需求,也能确保需求的合理性和完整性。



无觅相关文章插件,快速提升流量

“如何确认产品需求文档PRD”有1条评论

commenter

2012-5-3补充测试用例review的过程,该步骤也比较重要。