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