产品需求文档(PRD)的撰写

产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。该文档是产品项目由“概念化”阶段进入“图纸化”阶段的最主要的一个文档,其作用就是“对MRD中的内容进行指标化和技术化”,这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。

在PRD中,基点依然是MRD中的内容,只是把重心放在了“产品需求”上,而产品需求本身是在MRD中有所体现的,区别在于,PRD要把MRD中“产品需求”的内容独立出来,并加以详细的说明。在撰写PRD时,要注重对MRD内容进行继承和发展,把MRD中的内容技术化,向研发部门说明产品的功能和性能指标。

该文档侧重的是对产品功能和性能(即“产品需求”)的说明,相对于MRD中同样的内容,要更加详细,并进行量化。一些国外公司允许把MRD和PRD合并成一个文档,通常叫做“Marketing & Product Requirements Document”。

【小提示】关于PRD的错误认识。

1)PRD无原始数据支持,只是按个人经验、部门要求或者领导指示进行撰写。

2)在PRD中,只重视“产品功能”的描述,而缺乏对产品其他指标项的说明。

3)照搬别人的PRD模板,来源于何处,不知道,将去向何处,也不知道,无头无尾,是一个被割裂的文档。

那么,如何完成一份优秀的产品需求文档呢,下面的一些标准可以供参考:

(1)让“有用性”更加准确

分析人员应将从用户那里获得的所有信息进行整理,以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析,用户就能得到一份“需求分析报告”,此份报告使分析人员和用户之间针对要分析的产品内容达成协议。报告应以一种用户认为易于翻阅和理解的方式组织编写。用户要评审此报告,以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于分析人员分析出真正需要的产品。

(2)让“有用性”可验证和可实现

对用户方而言,各项需求应当都是可验证的。如果需求是不可验证的,那么用户就无法验收产品。例如,某个平台的一项需求是“承受100万用户访问”,这个需求如何验证呢?当平台验收时,如果双方都认可“采用压力测试,模拟100万用户访问”等效于实际测试,那么这项需求就是“可验证”的。

同时,分析人员应尽力从这些解决方法中了解真正的业务需求,同时还应找出已有系统与当前业务不符之处,以确保产品不会无效或低效;在彻底弄清业务领域内的事情后,分析人员就能提出相当好的改进方法,有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

(3)明确“有用性”的优先级,同时注重完备性

从理论上讲,所有需求都应当被实现。但是在现实中,项目存在进度、费用、人力资源等限制。在项目刚开始的时候,开发方和客户比较乐观,什么都要做,可是做着做着,常常会面临进度延误、费用超支、人员不足等问题,这时就乱套了。不过可以采用取舍的办法:先做优先级高的需求,后做(甚至放弃)优先级低的需求,这样可以将风险降到最低。所以要尽量剔除画蛇添足的那些需求。需求的优先级其实就是需求轻重缓急的分级表述,例如划分为“高、中、低”三级。一般地,由用户和开发方共同确定需求的优先级。为了避免主次颠倒,应当在产品需求文档中将那些锦上添花的需求设置为较低的优先级。特别要注意的是,避免忽视了其他一些不起眼的但却是必需的功能。不完备的产品需求文档将导致产生功能不完整的软件,用户在使用该软件时可能无法完成预期的任务。

绝大多数项目没有足够的时间或资源实现功能性的每个细节。因此,决定哪些特性是必要的,哪些是重要的,是需求分析的主要部分,这只能由用户负责设定需求优先级,因为分析者不可能按照用户的观点决定需求优先级;分析人员将为您确定优先级提供每个需求的花费和风险的信息。在时间和资源限制下,所需特性能否完成或完成多少应尊重分析人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对现实,业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折中。

(4)与用户充分沟通

如果用户与分析人员之间不能相互理解,那么关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求分析过程的用户有权要求分析人员尊重他们并珍惜他们为项目成功所付出的时间,同样,用户也应对分析人员为项目成功这一共同目标所做出的努力表示尊重。由于处理细节问题不但烦人而且耗时,因此很容易留下模糊不清的需求。但是在分析过程中,必须解决这种模糊性和不准确性,而用户恰恰是为解决这些问题做出决定的最佳人选,否则,就只好靠分析人员去正确猜测了。

用户可以要求分析人员在实现功能需求的同时注意产品的易用性,因为这些易用特性或质量属性能使用户更准确、高效地完成任务。例如:用户有时要求产品要“界面友好”或“健壮”或“高效率”,但对于分析人员来讲,这些要求太主观了并无实用价值。正确的做法是,分析人员通过询问和调查了解用户所要的“友好、健壮、高效所包含的具体特性,具体分析哪些特性对哪些特性有负面影响,在性能代价和所提出解决方案的预期利益之间做出权衡,以确保做出合理的取舍。

在需求分析中暂时加上“待定”标志,用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方。有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。用户要尽量将每项需求的内容都阐述清楚,以便分析人员能准确地将它们写进“产品需求报告”中去。如果用户一时不能准确表达,通常就要求用原型技术,通过原型分析,用户可以同分析人员一起反复修改,不断完善需求定义。

此外,利用各种渠道,引导用户清楚地说明并完善需求。用户很忙,但无论如何用户有必要抽出时间参与“头脑高峰会议”的讨论,接受采访或其他获取需求的活动。对于相对集中的用户,可以建立实时交流群或圈子,方便用户针对产品提出建议。

(5)充分考虑“有用性”设计的灵活性

需求通常有一定灵活性,已有的某个产品组件与用户描述的需求可能很相符,在这种情况下,分析人员应提供一些修改需求的选择,以便降低新系统的分析成本和节省时间,而不必严格按原有的需求说明分析。所以,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合所需的特性时,需求的灵活性就显得极为重要了。

另外,要求对变更的代价提供真实可信的评估。用户有权利要求分析人员通过分析给出一个真实可信的评估,包括影响、成本和得失等。分析人员不能由于不想实施变更而随意夸大评估成本,误导用户。

(6)完善“有用性”评审

不断的需求变更会给在预定计划内完成的产品质量带来严重的不利影响。变更是不可避免的,但在分析周期中,变更越晚出现,其影响越大。变更不仅会导致代价极高的返工,而且工期将被延误,特别是在大体结构已完成后又需要增加新特性时更是如此。所以,一旦用户发现需要变更需求时,要立即通知分析人员。

尊重分析人员的需求可行性及成本评估。所有的产品功能都有其成本。用户所希望的某些产品特性可能在技术上行不通,或者实现它要付出极高的代价,而某些需求试图达到在操作环境中不可能达到的性能,或试图得到一些根本得不到的数据。分析人员会对此做出负面的评价,用户应该尊重他们的意见。

评审需求文档和原型。用户评审需求文档,是给分析人员带来反馈信息的一个机会。如果用户认为编写的“需求分析报告”不够准确,就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品分析一个原型。这样用户就能提供更有价值的反馈信息给分析人员,使他们更好地理解需求。原型并非一个实际应用产品,但分析人员能将其转化、扩充成功能齐全的系统

猜您喜欢

要发表评论,您必须先登录