需求文档编写常遇到的问题?怎么破?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

“文章本天成,妙手偶得之。”写需求文档不需要“妙手”,但需要思路清晰、叙述清楚。写的人要能把需求写透,看的人才能看懂,一篇好的需求文档能答疑解惑,一篇坏的需求文档会让人误入歧途。

xuqiuwendang

有一天,一个朋友打电话给我。

朋友:“上回听说你们公司是做产权的,我这有诉讼相关的项目,你们能做吗?”

老吴:“公司现在不打算接项目了,以做产品为主。”

朋友:“你在公司负责什么啊?”

老吴:“我是产品经理,负责公司的产品。”

朋友:“哦,做需求的啊,知道了。

老吴:“……”

每个公司对产品经理的定位都不同,有的产品经理负责产品的需求,有的产品经理负责产品的设计,有的产品经理负责整个产品线。不论给产品经理的定位是什么,需求对产品经理来说都是必做的功课,那么,写需求文档就成了我们的家常便饭。对于不同的大厨来说同样做一道家常菜,有的做的色、香、味俱全,吃起来入口绵长、滑嫩可口;有的做的熟悉亲切、感人落泪如妈妈的味道;有的做的外焦里嫩、清香扑鼻;但也有的做的惨不忍睹、不忍直视。做产品也是一样,不同的人对产品有着不同的理解,就算理解一样,写出来的产品文档也会不同。

那么,产品经理在整个需求阶段要写哪些文档呢?

商业需求文档BRD、市场需求文档MRD、产品需求文档PRD、技术需求文档(需求规格说明书)。

  • 商业需求文档BRD。它是一种商业的需求描述,里面要体现产品的市场分析、规划、投入、盈利预测等信息,是为了让决策层便于分析、决策是否开发此产品的依据,商业需求文档更像是商业计划书,它是需求阶段最早需求提供的文档,文档一般不长,也可以是PPT的方式展示。
  • 市场需求文档MRD。市场需求文档是站在市场、用户的角度,多描述用户、购买者、客户的需求,它是承上启下的文档,对技术需求文档的编写起到一定的指导作用。文档中多会加入原型的形式将产品具体化,便于文档的解释说明。
  • 产品需求文档PRD。产品需求文档多是站在业务的角度,让所有的项目干系人都能够了解、理解产品而编写的,此文档的阅读者为产品的管理层、需求人员、设计人员、技术人员、测试人员、市场人员、运营人员。

需求规格说明书,此文档是站在技术角度而编写,文档中不仅要描述产品的业务需求,还要描述产品的技术指标和技术参数,是架构设计、技术开发的指导性文档。为了便于说明需求,文档中会加入流程图、序列图、原型图等设计模型,更好的让技术人员理解、指导技术人员开发。

根据公司情况不同,PRD、MRD、BRD文档不一定都需要编写,这要看各公司的具体情况。我认为让非技术人员理解产品一定要有产品需求文档,指导技术开发一定要有需求规格说明书。产品经理要写这么多文档,需要贯彻产品的整个需求阶段,那么产品经理一定要是一名好的方案编写高手。

我们了解了各类文档,也知道了他们的价值和作用,那么,文档的编写需要注意哪些方面呢?

正确性

我们经过调研、分析得到需求后,整理成文档,以便于信息的保存与传播。需求在脑子里的时可能是清晰的,但写出来后就不一定清晰了。原因是,你脑子里想的可能是A,写出来后可能是A1,但你还以为写的是A。错误的原因有很多可能是你的文笔不好、也可能是疏忽、还可能是你没有把需求写透,还有一种可能就是你当初就没有正确的理解需求。

e1

全面性

我们在获取需求时尽量全面的了解问题,得到真实、准确、完整的需求,只有获取的信息全面写出来的需求才可能全面。另外,就算获取需求全面了,有时写需求时也难免有所疏漏。所有,在编写需求时要考虑全面,建议从大到小、从粗到细进行梳理,从平台、子系统、模块、功能点一条一条线进行梳理,当所有的流程都遍历完成后需求文档也就整理完成了。

e2

可验证性

需求文档中所描述的需求应该是可验证的,如商业文档的商业数据的出处。对于技术文档来说,功能要有输入项、输出项、事前描述、约束条件,当一切条件都满足后,输入什么样的数据应该输出什么样的结果。对于市场需求文档,要体现用户的逻辑思维,为什么用户会用这样的功能,依据是什么?是经过推理、还是心理暗示?文档中的信息应该是可推敲、可验证的,只有保证数据及信息来源的正确性,才能更好的把握产品。另外,只有需求文档各接口、属性、参数具备可验证性,测试人员才好根据需求文档编写测试用例。

无二义性

中文有多音、多义字,英文也有一个单词代表多种含义的情况,因为文档主要是文字描述,在文档中难免有二义性的情况。在文档的描述中一定要保证含义清晰,表达准确。还有一种情况,就是有时产品经理自己对产品需求理解模糊,思考不深刻,在写文档时就不可能保证文档的准确性。

必要性

不同的需求文档是站在不同的角度上思考问题的,当我们从多重角度分析问题时,会对产品有更深刻的理解,哪些需求是必要的,哪些需求是次要的,哪些需求是可要可不要的。当一个产品中充斥着非必要性需求,就是喧宾夺主,有时要该“砍”则“砍”,壮士断臂。

优先级

在产品中加入优先级,有助于让相关人理解产品中各功能的重要度,在必要时(如开发时间紧张时)也可以考虑优先完成哪些功能。另外,在产品文档中加入优先级,也便于产品的版本升级。但优先级,我认为不用分得太细,只需要加上“高”、“中”、“低”就好了。

以上问题都是在做产品文档时需要注意的问题,做为产品经理,我们在获取、分析需求时,一定要对需求准确把握,不可以有理解模糊、分析不透彻的情况。否则,在编写文档时就会出现更多的问题,当你再折回去重新分析需求时会浪费更多的时间和精力。需求文档的编写是一个很吃功力的事情,难的不是写,而是想,只有想透了写其它是件很容易的事。就跟写文章一样,在写前在大脑中会想好题纲,写时思路就会非常清晰。建议产品经理,在写文档前一定要把需求想清楚,也可以借助一些模型工具,如VISIO、AXURE等,通过模型会有利于帮助我们整理思路、梳理需求。

需求文档的编写是一件很费时、费力的事情,大多数公司都会认真编写需求文档吗?需求文档的下场一般会是什么样的呢?

  • 一、在很多公司,产品的前期和开发阶段,文档都会非常重视,当产品一旦进入开发后期或完成后,文档就会束之高阁,经过多轮的产品迭代后,文档与产品间就会完全脱节,这就是需求失败的信号。
  • 二、许多企业为了赶项目工期,前期只是有简单的设计就进入开发阶段,而且对外声称自己是“敏捷开发”,敏捷成为不用写文档的借口。实际,在开发阶段,需求文档是非常重要的,它将有效的指导开发工作,让技术人员按照统一的标准实施,它将有利于让技术人员统一思想,开发时也不用频繁的进行沟通,前期需求阶段多思考后开发阶段就可以节省大量的时间。敏捷只适用于小团队作战,在大项目中,开发文档将保证所有的技术人员按照有序的、准确的方向前行。
  • 三、很多公司为了应付客户或领导,在产品开发完成后补文档,这时编写的文档基本上没有什么价值了,真正要做好产品,需求文档的编写是成功的必要条件。

需求文档在产品团队中要如何使用和管理呢?

需求文档应该是共享的,所有项目参与人都可见,一方面有利于干系人理解产品,还有利于其它人提出不同的意见和见解,帮助产品优化。在项目中尽量用一些版本管理工具来管理文档,如CVS、VSS。这些版本管理工具可以设置权限,哪些人可以看哪些文档,哪些人可以修改哪些文档,在版本管理工具中都可以实现。另外文档要可维护,随着需求的变更需求文档也会跟着变化,要保证需求文档与产品功能一致。另外,为了保证产品文档的风格一致,尽量让专人负责文档的维护工作。

 

本文由 @产品人老吴(微信公众号:ChanPinLaoWu) 原创发布于人人都是产品经理。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 1

登录后参与评论
  1. good! :roll:

    回复
加载中