编写需求文档常遇到的问题有哪些？
本文作者：老吴 原文地址：戳这里
- 有一天，一个朋友打电话给我。
- 朋友：“上回听说你们公司是做产权的，我这有诉讼相关的项目，你们能做吗？”
- 老吴：“公司现在不打算接项目了，以做产品为主。”
- 朋友：“你在公司负责什么啊？”
- 老吴：“我是产品经理，负责公司的产品。”
- 朋友：“哦，做需求的啊，知道了。
- 老吴：“……”
每个公司对产品经理的定位都不同，有的产品经理负责产品的需求，有的产品经理负责产品的设计，有的产品经理负责整个产品线。不论给产品经理的定位是什么，需求对产品经理来说都是必做的功课，那么，写需求文档就成了我们的家常便饭。
对于不同的大厨来说同样做一道家常菜，有的做的色、香、味俱全，吃起来入口绵长、滑嫩可口；有的做的熟悉亲切、感人落泪如妈妈的味道；有的做的外焦里嫩、清香扑鼻；但也有的做的惨不忍睹、不忍直视。做产品也是一样，不同的人对产品有着不同的理解，就算理解一样，写出来的产品文档也会不同。
“文章本天成，妙手偶得之。”写需求文档不需要“妙手”，但需要思路清晰、叙述清楚。写的人要能把需求写透，看的人才能看懂，一篇好的需求文档能答疑解惑，一篇坏的需求文档会让人误入歧途。
产品经理在整个需求阶段要写哪些文档？
商业需求文档BRD、市场需求文档MRD、产品需求文档PRD、技术需求文档（需求规格说明书）。
商业需求文档BRD，它是一种商业的需求描述，里面要体现产品的市场分析、规划、投入、盈利预测等信息，是为了让决策层便于分析、决策是否开发此产品的依据，商业需求文档更像是商业计划书，它是需求阶段最早需求提供的文档，文档一般不长，也可以是PPT的方式展示。
市场需求文档MRD，市场需求文档是站在市场、用户的角度，多描述用户、购买者、客户的需求，它是承上启下的文档，对技术需求文档的编写起到一定的指导作用。文档中多会加入原型的形式将产品具体化，便于文档的解释说明。
产品需求文档PRD，产品需求文档多是站在业务的角度，让所有的项目干系人都能够了解、理解产品而编写的，此文档的阅读者为产品的管理层、需求人员、设计人员、技术人员、测试人员、市场人员、运营人员。
需求规格说明书，此文档是站在技术角度而编写，文档中不仅要描述产品的业务需求，还要描述产品的技术指标和技术参数，是架构设计、技术开发的指导性文档。为了便于说明需求，文档中会加入流程图、序列图、原型图等设计模型，更好的让技术人员理解、指导技术人员开发。
根据公司情况不同，PRD、MRD、BRD文档不一定都需要编写，这要看各公司的具体情况。我认为让非技术人员理解产品一定要有产品需求文档，指导技术开发一定要有需求规格说明书。产品经理要写这么多文档，需要贯彻产品的整个需求阶段，那么产品经理一定要是一名好的方案编写高手。
我们了解了各类文档，也知道了他们的价值和作用，那么，文档的编写需要注意哪些方面呢？
文档的编写需要注意哪些方面呢？
1、 正确性
我们经过调研、分析得到需求后，整理成文档，以便于信息的保存与传播。需求在脑子里的时可能是清晰的，但写出来后就不一定清晰了。原因是，你脑子里想的可能是Ａ，写出来后可能是Ａ１，但你还以为写的是Ａ。错误的原因有很多可能是你的文笔不好、也可能是疏忽、还可能是你没有把需求写透，还有一种可能就是你当初就没有正确的理解需求。
２、 全面性
我们在获取需求时尽量全面的了解问题，得到真实、准确、完整的需求，只有获取的信息全面写出来的需求才可能全面。另外，就算获取需求全面了，有时写需求时也难免有所疏漏。所有，在编写需求时要考虑全面，建议从大到小、从粗到细进行梳理，从平台、子系统、模块、功能点一条一条线进行梳理，当所有的流程都遍历完成后需求文档也就整理完成了。
3、 可验证性
需求文档中所描述的需求应该是可验证的，如商业文档的商业数据的出处。对于技术文档来说，功能要有输入项、输出项、事前描述、约束条件，当一切条件都满足后，输入什么样的数据应该输出什么样的结果。
对于市场需求文档，要体现用户的逻辑思维，为什么用户会用这样的功能，依据是什么？是经过推理、还是心理暗示？文档中的信息应该是可推敲、可验证的，只有保证数据及信息来源的正确性，才能更好的把握产品。另外，只有需求文档各接口、属性、参数具备可验证性，测试人员才好根据需求文档编写测试用例。
4、 无二义性
中文有多音、多义字，英文也有一个单词代表多种含义的情况，因为文档主要是文字描述，在文档中难免有二义性的情况。在文档的描述中一定要保证含义清晰，表达准确。还有一种情况，就是有时产品经理自己对产品需求理解模糊，思考不深刻，在写文档时就不可能保证文档的准确性。
5、 必要性
不同的需求文档是站在不同的角度上思考问题的，当我们从多重角度分析问题时，会对产品有更深刻的理解，哪些需求是必要的，哪些需求是次要的，哪些需求是可要可不要的。当一个产品中充斥着非必要性需求，就是喧宾夺主，有时要该“砍”则“砍”，壮士断臂。
6、 优先级
在产品中加入优先级，有助于让相关人理解产品中各功能的重要度，在必要时（如开发时间紧张时）也可以考虑优先完成哪些功能。另外，在产品文档中加入优先级，也便于产品的版本升级。但优先级，我认为不用分得太细，只需要加上“高”、“中”、“低”就好了。
以上问题都是在做产品文档时需要注意的问题，做为产品经理，我们在获取、分析需求时，一定要对需求准确把握，不可以有理解模糊、分析不透彻的情况。否则，在编写文档时就会出现更多的问题，当你再折回去重新分析需求时会浪费更多的时间和精力。需求文档的编写是一个很吃功力的事情，难的不是写，而是想，只有想透了写其它是件很容易的事。就跟写文章一样，在写前在大脑中会想好题纲，写时思路就会非常清晰。建议产品经理，在写文档前一定要把需求想清楚，也可以借助一些模型工具，如VISIO、AXURE等，通过模型会有利于帮助我们整理思路、梳理需求。
需求文档的编写是一件很费时、费力的事情，大多数公司都会认真编写需求文档吗？
大多数公司都会认真编写需求文档吗？
一、在很多公司，产品的前期和开发阶段，文档都会非常重视，当产品一旦进入开发后期或完成后，文档就会束之高阁，经过多轮的产品迭代后，文档与产品间就会完全脱节，这就是需求失败的信号。
二、许多企业为了赶项目工期，前期只是有简单的设计就进入开发阶段，而且对外声称自己是“敏捷开发”，敏捷成为不用写文档的借口。实际，在开发阶段，需求文档是非常重要的，它将有效的指导开发工作，让技术人员按照统一的标准实施，它将有利于让技术人员统一思想，开发时也不用频繁的进行沟通，前期需求阶段多思考后开发阶段就可以节省大量的时间。敏捷只适用于小团队作战，在大项目中，开发文档将保证所有的技术人员按照有序的、准确的方向前行。
三、很多公司为了应付客户或领导，在产品开发完成后补文档，这时编写的文档基本上没有什么价值了，真正要做好产品，需求文档的编写是成功的必要条件。
需求文档在产品团队中要如何使用和管理呢？
需求文档应该是共享的，所有项目参与人都可见，一方面有利于干系人理解产品，还有利于其它人提出不同的意见和见解，帮助产品优化。在项目中尽量用一些版本管理工具来管理文档，如CVS、VSS。这些版本管理工具可以设置权限，哪些人可以看哪些文档，哪些人可以修改哪些文档，在版本管理工具中都可以实现。另外文档要可维护，随着需求的变更需求文档也会跟着变化，要保证需求文档与产品功能一致。另外，为了保证产品文档的风格一致，尽量让专人负责文档的维护工作。
文章作者
产品人老吴，微信公众号：ChanPinLaoWu，产品壹佰专栏作家，北京金马甲产权网络公司产品总监，产品讲学堂自媒体人。十多年软件行业从业经验，做过软件开发、项目管理、产品经理，希望能够与大家分享更多产品经验和知识，欢迎关注更多老吴产品讲学堂的产品观点。
关键字：产品经理, 需求文档, 文档, 需求
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
