需求文档遗漏问题的良方：认识它并干掉它
编辑导语：在日常工作中，有接触过需求文档的人，想必都会遗漏掉一些细节问题，也有可能还有人不知道需求文档是什么？该如何避免？本篇作者就分享了自己在输出需求文档时的经验，以及为什么要正确的输出需求文档。推荐给产品经理或在团队里需要输出需求文档的童鞋阅读。
案例1:
错误示范：公司名称字段字符长度限制为50个字符，不可为空。
正确示范：公司名称字段长度限制为50个字符；不可为空，异常提示：请输入公司名称。
问题解析：产品经理在需求描述没有给出恰当的异常情况提示，开发在需求实现过程中按自己的理解写了一个错误提示，测试环节或上线后，发现提示文案有问题然后返工，这样的情况在我目前所在的公司是时有发生的。
案例2：
错误示范：手机号字段字符长度限制为11个字符，只能输入数字；不可为空，异常提示：请输入手机号；手机号格式校验，异常提示：手机号格式错误，请重新输入。
正确示范：手机号字段字符长度限制为11个字符，只能输入数字，文本框获取焦点时弹出数字键盘；不可为空，异常提示：请输入手机号；手机号格式校验，异常提示：手机号格式错误，请重新输入。
问题解析：类似场景2的情况，产品经理在描述需求时，如果是移动端产品且字段限制只能输入数字，最好是能在需求描述上给出出在交互上的期望，否则开发实现的结果不符合期望，那么可能在测试环节或上线后需要返工。
案例3：
错误示范：【删除】按钮默认为不可点击状态，用户选择数据后，【删除】按钮为激活状态；用户点击【删除】按钮，显示操作确认弹窗，用户点击确认按钮执行数据删除操作。
正确示范：【删除】按钮默认为不可点击状态，用户选择数据后，【删除】按钮为激活状态；用户点击【删除】按钮，显示操作确认弹窗，用户点击确认按钮执行数据删除操作；权限说明：仅XXXXX组的用户有【删除】按钮权限。
问题解析：产品在为用户提供增、删、查、改、显服务时，产品经理需要考虑每一个动作背后的权限问题，例如：不同账号之间的数据查看权限。
以上三种场景，举例说明我或团队成员输出的需求文档中出现的遗漏现象，这些遗漏可以概括为细节点和关键点的遗漏。
在最近一两年的工作中，本人自身、项目团队、公司内发生的这些现象，对我造成了很大的困扰。看似不严重的问题的，但是久而久之对产品经理个人、对项目团队、对公司会产生不可估量的影响，例如：
需求文档中频繁出现的细节遗漏或关键性的遗漏，会给开发、测试造成不必要的困扰，久而久之可能导致开发、测试同事对产品经理专业性的质疑，从而影响产品经理在项目团队中的公信力。
需求文档中的遗漏，必然会在需求开发阶段、测试阶段增加沟通的次数，这种因产品经理的造成的问题的沟通的过程中，有可能会发生摩擦，这种摩擦就有可能影响项目团队的氛围。
以上两点分别从产品经理个人和项目团队的角度，阐述了需求文档的遗漏可能造成的影响，从这个因果关系当中，不难推出，如这种现象得不到控制并减少，最终影响的公司的经济与效率。
各位同道中的人，你或你们的同事，在输出需求文档的过程中，是否遇到过类似的情况，你们是怎么解决看待并解决类似问的呢？
一、如何避免
1. 是如何发生的？
基于发生在自己和同事身上的案例来看，造成以上种种现象的原因主要有两方面：
1) 经验限制：例如刚入行的新人，由于自身经验不足的限制，对需求里面涉及到相关点或对需求涉及的关键点分析不足，造成需求文档遗漏，如此除了专业技能的加强与学习，可以多多参考团队中前辈的方法与经验。
2) 细节执行：生活、工作中，总有人声称自己十分注重细节，但是在实际工作执行中时不时犯细节上的问题，例如本文开篇举例的三个场景的现象，这里面的原因包含很多的主观或客观因素，在这里不展开去阐述。
2. 它们是什么？
需求文档是产品经理以“产品”作为描述对象产出的文档，主要的组成部分包括：文档变更历史、背景&目标、文档约定、系统概述、功能描述、非功能需求……等，其中功能描述是最重要的组成部分之一，那么我们在对产品的功能进行需求描述时，究竟在描述些什么东西呢？
产品是用户与公司业务之间的桥梁，从用户以及自身使用产品的过程来看，无论是常规的互联网产品，还是B端的业务系统，从产品的实现层面来讲，其实都是在为用户提供增、删、改、查、显服务，例如：
用户填写并提交账号注册表单，这属于新增。
用户删除过去已经发表微博或朋友圈，这属于删除。
吃瓜群众在微博中搜索“吴签”的信息，这属于查询。
微信→发现→朋友圈，可以查看朋友和自己发的朋友圈内容，这属于显（反馈）。
修改微信绑定的手机号，这属于修改。
既然可以机械化的将产品理解为是在为用户提供增、删、改、查、显服务，那么在假设需求的真伪、需求的价值、解决方案的设计……一切都已OK的情况下，需求文档功能部分的描述其实是在对增、删、改、查、显用户界面中元素规则以及数据交互规则、权限规则等关键点的描述。
以上图“创建企业”表单为例：需求文档需分别描述：企业名称、公司对外联系邮箱、所属行业三个字段的规则和按钮规则，例如：
企业名称字段是否必填，字符长度限制是多少，是否允许输入特殊字符，异常提示是什么。
用户点击完成按钮时，需校验表单的合法性，合法则允许提交表单，不合法则限制提交数据，并显示异常提示。
数据唯一性：提交数据时，需校验是否存在名称相同的数据，如存在则限制提交数据，并提示异常。
3. 我的尝试？
如果将所有问题笼统的分类为经历过的和未经历过的或常见场景的问题和非常见场景的问题，那么针对那些经历过的问题或常见场景的问题通过复盘总结：认识问题→ 设计解决方案→ 执行→ 修正→ 总结，是可以找出通用的解决方案的，例如各行业的软/硬件产品的通用方案的解。
在解决自身需求文档遗漏问题的过程中，我利用以下思路将需求描述用通用的模板去规范自己的需求描述，避免需求文档在关键点或细节上的遗漏。
1）避免关键遗漏
在输出需求文档的过程中，要避免关键部分的遗漏，就需要了解一份完整的需求文档包含哪些关键部分。上图是我们团队使用的标准的需求文档框架，每次写需求前和在需求文档完成后，都会基于自用的标准进行自查，看看是不是有哪个关键部分的内容被遗漏。
2）避免细节遗漏
由产品是在为用户提供增、删、改、查、显服务，可以得出需求文档中，具体的功能需求描述其实是在增、删、改、查、显规则的描述。
基于自身和团队成员的情况，以及根据增、删、改、查、显动作涉及到的关键需求点，将需求描述模板化。
这样的模板对于自身而言：一方面可以让我清晰的知道，一个新增表单的需求描述有哪些关键点需要注意、需要描述，例如：企业名称字段，在需求描述时要描述字段的编辑规则、交互规则、校验规则等；另外，在文档输出的过程中，只需要根据模板要求，将相应的需求描述填充上去即可，可以在一定程度上避免细节点的遗漏。
作者：汪童学；公众号：汪童学
作者@汪童学
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
