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

4 评论 49293 浏览 299 收藏 12 分钟

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

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

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

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

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

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

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

老吴:“……”

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

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

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

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

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

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

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

正确性

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

e1

全面性

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

e2

可验证性

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

无二义性

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

必要性

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

优先级

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

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

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

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

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

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

 

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 大佬,请问你们一般使用什么工具可以团队管理需求文档且权限管理和评论等功能等啊?

    来自湖南 回复
  2. 其中的一句话我很认同,我们公司就是敏捷开发,开始的需求文档很简陋。感觉学不到什么东西

    来自四川 回复
  3. 好文啊

    来自上海 回复
  4. good! 🙄

    来自上海 回复