需求文档的主要作用是让团队对业务流程及功能规则达成共识，产品、设计、研发和运营人员都是需求文档的受众，为团队成员间高效沟通起到了重要作用。编写需求是产品经理的基础技能，需求文档的质量直接反应了产品经理能力，然而很多产品经理产出的需求不能有效指导开发测试工作，在开发阶段不断变更来修补需求中的问题。那么编写需求需要注意哪些问题呢？
动笔前，先梳理框架脉络
很多产品经理在产品方案确定后便开始着手编写PRD，而需求评审和开发阶段会暴露出影响点遗漏、流程不完整、规则前后矛盾等问题。要解决这个问题，那就在动笔前先梳理需求的框架脉络，会让你在编写需求时事半功倍。
梳理框架脉络的过程就是UML建模的过程，通过建模图形直观的表达系统需求概要，更方便的与开发测试沟通、与业务确认流程规则。产品经理在明确业务需求、用户需求之后，首先理清产品方案中事件、实物、人物的关系，完成领域模型图，从而明确需求的框架结构，然后制作流程图、状态图、用例图，概括的整理产品方案的影响范围和功能结构，接下来再编写需求时就不会有逻辑混乱、调整点遗漏、规则矛盾等明显的错误了。
背景和目标写清楚了吗
产品经理期望开发对产品的理解与自己完全一致，但是在需求中却没有明确的表达需求的背景以及功能的目标，这是我们经常会犯的错误。开发也需要对产品发展和定位有深刻的认识，所有产品经理请认真写需求背景和目标，分析当前哪类用户，在什么时间、做什么的时候，遇到了什么问题，会给产品带来哪些损失，为此我们需要做什么、如何做，最终达到什么效果。这样的背景和目标会让开发看的神清气爽，即使加班也都无怨无悔。
一图胜千言
有时候需求描述的再多，不如一个线框图表达的清楚，这也是大多开发厌倦开发文档的一个原因：太多文字却不知道在说什么，原型的页面和需求的规则也不能很好的对应。产品经理不妨在需求中做原型截图示意，图文结合的形式让需求更易阅读。而一些复杂的规则和流程可以借助表格、公式、举例的方式，让需求更简洁直白。
写系统能够识别的规则
产品经理在做产品方案时，会根据用户使用产品的场景、时间、操作的不同，而设置一些不同的规则，要将这些条件转变成系统需求时，需要我们定义系统可识别的条件、执行规则，例如：欢迎语在晚上显示：晚上好。这个规则初看没有问题，可是系统如何识别什么时间是晚上呢？所以要系统可识别的规则应明确指定时间范围。
别忘了分支流、异常流
业务主线是最先确定也是最容易确定，然而很多分支流程、异常情况却不容易考虑全面，产品经理被开发问到最多的问题也是分支流程、异常流程如何执行。产品经理在正常流程的每个环节，要深入思考各种场景下可能发生的情况和异常，避免分支流程被遗漏、用户操作后无法正常流转的情况。
记得解释专业术语
产品经理在需求中不可避免的会出现一些行业专业术语，而开发团队并不是人人都对这个行业非常了解，开发常常被一些术语搞的晕头转向，不知道这些术语的意义及用处，因此很容易误解这些术语的意思，对业务的解读也会偏离产品需求。在需求文档最开始对文档中的行业术语做详细的解读，可以帮助开发正确理解业务要求，与团队统一术语的解读。
不要秀文采
产品经理不乏文采优秀的人，但也不能把需求写成散文、文言文、小说……
需求文档的规则和说明尽可能的用大白话描述，描述不清楚的就举几个示例辅助，切忌过于简化描述、自创名词、冗长的说明等。
用对模板
需求模板可根据团队、项目的不同而分别定制。大多团队会使用固定的需求文档模板，便于阅读、存档，也有些团队更喜欢需求和原型合并，直接在原型上编写所有的需求规则，更加直观。无论哪种形式，都是为了让团队更高效的沟通和有效的传递产品价值，所以不需要过分纠结需求形式，只要团队都能接受即可。
网友评论