同样是写需求，为什么有的人能一次过，而有的人改了又改，甚至还要推倒重来？同样是写需求，为什么有的人考虑全面，而有的人丢三落四，直到评审的时候被怼得体无完肤？同样是写需求，为什么有的人简单易懂，而有的人长篇大论，大家却看不懂？
这种情况在我们工作中经常会看到，优秀的需求文档和拙劣的需求文档，就像产品经理的脸面。
那么，怎么才能写出一份漂亮的需求文档，结合这几年的工作总结，和大家聊一聊
1、准确理解需求，才能有的放矢
写需求的大忌之一，就是自嗨。
很多自嗨型选手，自傲型的，会觉得自己的理解才是最完美的，用户提的需求或者场景，都是欠考虑的。
他们不屑去找用户求证，也不会使用简单的方案先验证需求，而是完美主义的妄想一步到位，他们信奉乔帮主的一句话：用户并不知道自己需要的是什么，直到我们拿出自己的产品，他们就发现这是我想要的。
自卑型的，他们不愿意找用户，害怕找用户求证。因为担心自己没有理解用户的需求，会被其他人看不起，怀疑自己的能力。
所以即使不理解，也不愿意找用户求证，但是又要交差，最后就只能按照自己的理解硬着头皮上。
不能准确理解业务场景，就敢写需求的，最后都会成为烈士。理解了需求是1，后面所有的文档，开发和测试都建立在这个1上，没有1，后面再多的0也白搭。
准确理解需求，其实就是要理解需求背后的使用场景，可以使用常用的5W1H框架。
what：用户的问题和需求是什么？
when：用户什么时候会遇到这样的问题？
why：用户为什么会遇到这样的问题？
where：用户一般在什么地方遇到这样的问题:
who：遇到这个问题的用户是谁？用户群体有什么特征？
how：用户当前是怎么解决这个问题的？
比如我最近负责的产品，有一个预警的需求，主要是针对平台的异常数据进行预警。
预警一般就分为三步：预警的数据从哪来？预警的规则如何设置？产生预警后以怎样的形式发送给谁？
前两步我跟用户（公司的业务方）都对的比较清楚。而在第三步通知上，我就犯了理所当然的错误，陷入了自己的想象中。
我的想法是，产生预警的消息通知因为需要根据模板来配置的，这就有点类似于微信消息通知，都有固定的模板。
所以我想当然的认为，我们也只能通过设置几个固定的模板，然后根据产生预警的内容往模板里面填充信息。
但实际用户的需求并不是这样，固定的模板不能满足用户的需求，用户不仅需要预警消息，还需要自定义通知哪些信息给哪些用户。
所以最终的后果就是定好的开发计划需要重新制定，需求需要重新评审。好在还没有进入开发，只是耽误了2天的时间。如果是在验收的时候发现这个问题，那简直就是灾难了。
磨刀不误砍柴工，前期需求确认越准确，需求的不确定就越小，后期修改和返工的概率就越小。
2、学会制造和使用工具
确认好需求以后，就可以着手开始写文档了。
需求文档本质上是将我们脑子里对需求功能的构想，准确的传达给设计师、开发和测试同事。
那么，有哪些方法能提高信息的传达率呢？总结起来，大概有三种方法：
第一，换位思考，站在开发的角度思考问题。既然我们主要是写给开发同学看的，那么就应该用他们熟悉的思考方式来撰写需求文档。
什么是开发的思维方式呢？答案是函数思维。所有的函数都由三部分组成：输入—方法—输出。针对某一功能，用户的输入是什么？经过什么样的方法或流程？最终输出是什么？
例如，登录功能，用户输入账号和密码，点击登录按钮，这过程经过了哪些？
输入：用户的账号、密码；
方法或流程：请求后台用户账号表，校验用户账号和密码；
输出：返回登录结果，登录成功跳转到首页，登录失败则返回失败的原因。
因此，功能的详细需求描述，应该包括：
（1）要写清楚功能的输入是什么？输入的参数有哪些？是否是必填，参数的字段类型是怎样的？
（2）调用什么样的方法或流程
（3）输出是什么
（4）异常情况有哪些，如何处理？
其中，调用的方法或流程，我们可以使用流程图来对功能的数据在各个系统之间的流转做出精确的刻画。如果涉及到多个角色或系统，可以使用泳道图来进行描述。
异常情况的梳理，后面会具体讲到。
第二，学会使用动态面板。字不如表，表不如图。将我们脑子里对需求和功能的构思用原型图的方式展示出来，这是最直观的方式。
对语言的理解，由于各自的理解水平、阅历经验等不同，一千个读者就有一千个哈姆雷特。
用原型图画出来的保真图，能够清晰的告诉大家，我们最终想要实现的效果，页面自己的跳转是怎样的？同时在我们绘制原型图时，也是我们对需求的进一步梳理。
第三，搭建专属的高保真组件库。写需求的颜值和效率如何兼顾？怎样又快又美观的完成需求文档？答案是高保真组件库。
这里的组件库，不是市面上流传的那些通用的组件库，而是专属于我们所负责产品的组件库。
通用组件库因为是通用的，所以每次我们使用这些组件库时，都还需要对这些组件进行一些个性化改造。
所以为了进一步提高我们的效率，可以在这些通用组件库的基础上，进一步个性化为自己所负责产品的组件库。
组件库搭建成功以后，写需求就真的是搭积木一样了，不仅美观而且效率很高。
通用组件库可以在antidesign上下载一份。当然，如果你有一位交互设计大佬，也可以求她帮你做一份，就看你的本事了~
如果是自己来设计组件库，可以参考制作PPT的一些基本设计原则，这些都是相通的。
这里简单介绍下美国著名设计师Roibin Williams提出了四个关于设计的基本原则：
重复，作品中的一些元素可以在整个设计中重复出现，可能是某种图案、颜色、文字、空间关系等，重复促成统一；例如一些重复组件的样式和设计，弹窗、提示、输入框等
对齐，任何元素都不能在页面上随意安排，每一项都应当与页面上的内容存在某种联系。页面上的组件都应该才有某种方式对齐，组件与组件见的间距也要一样。
对比是为作品增加视觉效果的最有效途径之一，同时也能清晰地起到区分作用。例如：标题、正文、说明注释等字体的大小应该有层次感，相同类型的文字格式，包括字体大小，加粗/倾斜，颜色等都应该保持一致
亲密性原则是指，将相关项组织在一起而使他们之间产生凝聚力，因为物理位置的接近意味着存在关联
文字建议使用冷色调，文字颜色和背景色要对比明显，例如黑底白字，蓝底白字，白底黑子等。只有一些特殊的信息使用鲜艳的提示，例如报警、注意、异常情况等
3、增删查改显算传，尽量做到MECE
我们写需求的时候总是会遇到考虑不周全的情况。
首先要说明的是，切忌不要完美主义，没有人总是一次就能把所有因素都考虑在内。
关于需求的完整度，我们尽力即可，而且这其实是非常吃经验的事，我们可以在工作过程中多总结。
MECE虽然做起来很难，但是做得好的话，它其实是一件令人上瘾的事情。那种算尽一切的感觉真的很棒。
尤其是在需求评审，研发、测试等同学问什么问题，你都能回答出来的时候，不仅会给人一种专业的感觉，而且自己也会获得一种极大的成就感。
给大家分享一些写需求时，可以提高需求完整度的“7字真言”：增删查改显算传。
增就是新增，删就是删除，查就是查询，改就是修改，增删查改是形影不离的四兄弟。
所以在设计功能的时候，有其中之一，你就要考虑其他三个有没有漏掉。
当然，还是要根据业务实事求是。例如有的系统对删除比较敏感，有的低权限的用户只能新增，不能删除，也是有可能的。
显就是显示，以怎样的形式呈现给用户。列表，还是图形，弹窗还是新的页面，文字展示不完怎么办？数据太多是否需要翻页？数值数据使用哪种格式？最终，还是要根据具体的业务来。
算就是计算，常见的就是功能的某些字段的值是如何计算得来的？最常见的就是数据埋点，数据的来源，指标的计算方式等
传就是传值，该功能前后端的数据交互是怎样的，中间的数据流转涉及到哪些系统。例如支付功能，就至少涉及用户账号系统，钱包系统，第三方支付系统等。
除了这些，还有写需求经常会犯的一个错误，就是只考虑正常流程，不考虑异常流程。
其实对于异常流程考虑得是否完整，才是对一个PM的专业度的考验。
常见的一些异常，供大家参考：
（1）当功能有限制时，就需要考虑两头的极端情况，例如活动是有时间限制的，就需要考虑用户在参加活动时，刚好超过时间限制，此时该如何处理？
（2）输入框，支持哪些字符，中文，英文，数字。如果支持特殊符号，具体支持哪些符号，这些都需要提前定义好。输入框的长度限制，最大最小支持多少字符，输入时超过最大长度怎么办？字段字符太长展示不完怎么办？
（3）批量导入文件，文件支持哪些格式？文件大小有哪些限制？是否一次性支持多个文件导入？如果支持多个文件导入，有个别文件格式不正确或大小超出限制怎么办？文件的内容不符合要求怎么办？
（4）有权限限制，正常情况下操作权限范围内的功能没问题，但是在操作过程中，如果没有权限了，此时该怎么处理？如果对同一个页面，有多个用户拥有编辑权限，那么同时编辑的时候，如何处理？
（5）定时任务型功能，例如预警任务，预警任务的运行频次是怎样的？是否允许重复发送预警？预警消息发送失败了怎么办？定时任务启动失败怎么办？
（6）页面没数据时该怎么展示？这个是比较容易被遗忘的点，很多页面的缺省页都是需要设计师设计的，因为放一个空白页面太不友好了，不知道是正在加载，还是没网，还是出bug了。
（7）网络异常如何处理？网络弱的情况如何处理？（APP比较常见）
异常情况，其实可以多跟测试同学聊聊，他们才是真正的专家~
如果能把以上7字真言和常见的异常情况都考虑清楚，可以说就是一个合格的需求文档了，更进一步，就需要从整体上进行设计，当前的设计要为后续的迭代和完善做好铺垫。
这个比较吃经验，我们在工作的过程中可以多总结，针对一些常见的功能复盘他们的迭代路径。
这样积累下去，以后一看到类似的需求，就能做到胸有成竹了。
4、追根溯源，举一反三
如果是新需求，要举一反三。简单来说，就是在细化需求的时候，要把和这个需求相关的其他功能点都考虑在内。
我做这个需求会影响到哪些功能模块，需要哪些功能模块配合？
举个我做过的APP的例子来说，为方便理解，先交代下背景：
我们的APP里有代驾和打车两项技能，打车已有，代驾需要新增。
打车和代驾都是属于先享受服务，然后再支付的类型。
那么，为了防止白嫖，我们采取的是先冻结部分用户在APP账户内的金额。
原来只有打车的话，那么冻结金额就只有打车的，现在增加了代驾，也需要冻结金额。
那么，在写代驾订单逻辑的时候，就需要考虑到这部分冻结金额的逻辑，该如何处理，才能不影响打车。
冻结金额就需要从原来的只有打车，变成需要区分为打车和代驾。其实不止这些，代驾还涉及到订单后台，账单系统和钱包系统的修改，都要考虑到。
如果你没考虑到打车这个已有功能，就会让别人对你的专业能力产生质疑，三番几次就会失去开发的信任。
所以，我们在完善需求的时候，不仅要关注当前的需求，还要抬头看看四周，与这个需求有关的还有哪些其他的系统，这些系统要相应做哪些修改，都要考虑周全。
如果是功能优化，那么不仅需要考虑与其他功能的关系，还要考虑与自身的关系。
简单来说，就是要考虑以前数据，功能和交互的兼容性。我在做后台的时候，吃了很多次亏。
还是举个我自己的例子。
最近我们对账单进行了升级，原来的账单数据非常简单，就是对账单数据的简单罗列，没有筛选功能。
在账单升级后，数据结构发生了改变，增加了可按照业务类型（打车和代驾），支付时间和支付方式三个维度进行筛选。
当时我做的时候，没有考虑到一个重要的因素，就是要对以前的账单数据做兼容，导致账单升级以后，只能看到升级以后的数据。
这样就只能后面再补需求进行处理。虽然这没有造成很大的影响，但是如果是后续处理不了了，那就是真的大麻烦了。
所以，我们在迭代需求的时候，一定要考虑这个需求的来龙去脉，注意对这个需求以前的数据，交互方式等进行兼容。
5、注意考虑相关方，尤其是B端
相关方，简单来说就是跟你做这个项目或者需求有任意联系的人。比如说你负责的是某业务后台的搭建项目，那么相关的人就至少有：
你的领导，该业务负责人，该业务核心人员（实际使用你后台干活的），开发人员，测试人员，设计人员。
如何识别这些相关方呢？可以从是否参与项目与所受影响两个维度来区分。也可以按照相关方类型来区分。
比如：上游供应商，下游客户，中间有老板，领导，开发团队，测试团队，设计团队，运营团队，业务团队等。
将相关方识别出来之后，我们就知道哪些相关方是需要我们重点关注，哪些相关方是无关紧要的。
毕竟我们的精力是有限的，我们必须把80%的精力用在关键的20%的人身上，才能保证效率最大化。否则面面俱到只会把自己累死，吃力且不讨好。
最后，虽然我们总说不要成为功能或者需求经理，但是过硬的写需求的能力，是决定我们底线的关键，只有基础夯实，才能建起高楼大厦~
