导读
不只是我自己在用excel，我还推荐朋友使用，在培训时，我也将excel需求文档的写法教给大家，并且将excel版本 定义为 需求文档的2.0阶段。
写在文章之前：
这篇大概是我改的次数最多的文章，因为好处实在太多，最开始我从使用特性来分析，然后又从管理来分析，但总觉得不妥，毕竟这些好处并不是绝对的，还要看个人和团队的升级应用，然后就有了这版，绝对肯定一定大概也许可能打死不改的版本。
我决定，写几个最基础的好处，属于每一位用excel写需求文档都会拥抱它的好处。
需求可量化
如图，我们一旦使用excel写需求文档，会立即知晓需求数量，图中便有15个需求点。
你还记的上一个版本做了多少个需求吗？
我们使用excel来攥写需求文档，会很明确每个版本的需求量，比如我在上一个版本里总共开发的需求点有240个左右。
不论是word版本又或者是原型图标注，在这一点上都无法做到与excel相同的效果。
（ps.我始终不认为原型图标注是一种需求文档的撰写方法，它应该是表现形式才对。）
需求量化以后，我们能做到哪些事情？
将需求量化以后，我们可以轻易得到以上四个信息。
产品输出
基本上每位产品经理都能生产需求，但却无法将这些需求进行均衡，这也是许多创业团队的PM进入成熟团队后，很难适应的问题。
每个开发团队的生产力都是有限的，越是成熟的团队，周期内开发的需求量越是显得均衡，比如一个月固定开发量在400-500之间。
当然开发团队的规模，技术能力，以及需求复杂度，都会影响可开发的需求量。
但这些的前提，我们得有能量化下来的需求才行。
需求变更
需求变更不仅仅是让开发，测试同学深恶痛绝，也是我们产品从业人员心理的痛。
谁不想消灭需求变更呢？毕竟被大家不信任，以及质疑，总不是一件让人感到高兴的事情。
可似乎我们总是做不到“不变更”，甚至不知道自己的变更算严重还是在可接受范围。
量化以后，这些数据就能成为我们最大的评判工具。
在上个版本一共有40个需求点出现了变更，这个版本变更记录只有20条，是不是离目标近了点？
即使某个版本出现变更较多的时候，比如出现了60个需求点变更，我们也能立即发现问题出在哪个环节，能发现自己对何种类型的需求掌握不足。
开发输出
大概是习惯使然，我们一般都会质疑产品的需求遗漏，却不怎么会留意到功能漏做，一个好的团队，出现功能漏做的可能性比较低，但在团队初期时，这个问题，可是非常常见的。
我们可以借助规范的方法来避免这个问题，也是寄托于需求可量化的特性，能够统计到漏做的数量，也能关注到哪些需求容易漏做。
这是word乃至原型标注所不能达到的效果：需求可量化。
需求量化后就可被统计，而有了统计，就会出现完成率，变更率。
这部分就不再展开了，我们来看看除了需求可量化以外，我选择excel撰写需求文档的其他好处。
认识功能
这是我强调的另一个概念，对于产品经理而言，这是一个分水岭：认识功能。
其实有许多产品经理认识需求，但却不认识功能。
这并不是一个值得提倡的趋势，需求的来源我们可以理解成分析阶段的产物，也是一种想法，思考的表现，但始终要用功能来实现。
互联网产品经理本身有很大的局限性质，我们的想法必须依赖功能才得以实现，而这些功能都受到编程语言的限制，那就表示，功能是有限的。
需求是什么呢？
用户将内容从A产品里分享到朋友圈里，如果他的微信好友访问了他分享出去的内容，那在A产品里能够记录并通知用户：你的微信好友xxx，访问了你分享的。
这是一个需求，也是我所做过的一个需求，实际的效果非常好，我们不需要将用户的微信好友转移到A产品里，就能实现简单的熟人互动。
怎么实现呢？
Word版本的需求文档，大多是以描述需求为主，就像这个案例一样，这个描述里有多少个功能，都有哪些功能，我们都是不知道的。
但excel的需求文档里，如果我们不认识功能，就无法撰写，excel并不只是将需求点罗列出来而已。
按照列顺序，依次是功能模块，需求点，需求描述，参数。
功能模块可以有多个需求点，需求点却只能包含一个功能点。
我们只有认识到什么是排序规则，什么是首次加载，什么又是翻页，什么是缓存，才能去将这些功能罗列出来，并且对单个功能点进行描述。
我们只有认识到什么是参数，才能在参数列里，将参数的内容独立出来。
这就反过来对我们产生了督促效果。
在撰写的过程中，会反复思考需求如何实现的，并且向开发询问，进行技术调研，经过了这一系列的过程，最终写出来的需求文档，就会极大的规避遗漏掉的需求，以及会变更的需求。
要知道，在我们掌握一个需求的实现方案之前，这份文档是写不出来的。
所以，使用excel写需求文档的PM，在相同的一年里，往往能比word版本的PM，具备更多的功能素材，积累更多的关于技术的认识。
这并不需要学习代码，excel写需求文档就能达到这个效果。
积累需求库
当我们进入这个行业后，会逐渐的发现，功能的复用度很高。
我所了解的设计师有一些开源的素材，开发也会有封装好的SDK，可以直接使用。
产品经理也可以，我们的需求文档也可以积累下来，也是可以被复用的。
图中是一个功能模块的需求文档，我们会发现很多产品里使用到发布时间的，都会有一些相同的表现结果。
那么这部分的需求文档就可以复用到多个项目中。
随着这样的模块化需求越来越多，我们自身就会积累非常高效的需求库。
怎么做呢？
这只需要我们单独再建一张EXCEL，将每个版本的需求，按照一定的规律进行集合就好了。
Excel的需求文档，由于是对功能进行定义，也就是说从功能的角度来写，这就导致复用性非常高，不牵扯到业务逻辑，需求场景，功能就是功能。
久而久之，就会让我们发现其实不同的需求所用到的功能很多都是相同的。不论我们做什么样的项目，图片还是那个图片，输入框还是输入框。
这时，我们再写一份需求文档，大概只需要1-2小时，从我们的需求库，提取出相应需求就可以了。
需求库的形成，会有几个典型好处
1.对功能的认识可积累下来
2.极高的复用性能
3.逐渐完善需求，减少遗漏
有时候，我们会反复在同一个类型的需求里犯相同的错误，就拿统计数字来讲吧。
统计数字现在经常被使用，像是点赞数，评论数，关注数，粉丝数，照片数，阅读数等等，非常多的地方使用到了统计数。
我们可能在第一次写统计数字的需求时，会漏掉单位转换，没关系，我们将这个遗漏掉的需求，以需求变更的形式，记录下来。
第二次写的时候，我们会直接复用这块的需求，可能还会漏掉四舍五入，同样的，还是用需求变更的方式记录下来。
到后续的第三次，第四次，直到我们不需要再补充了，直到不会再因为该类型的需求，增加需求变更记录了，我们的需求库就成熟了。
后续使用时，直接复用就好，无须再思考了。
这篇文章，我给大家讲述了三个选择使用excel的原因，但就如同我在前文里提及到的，excel的好处实在太多了，甚至还有很大的挖据空间，等待大家的发现。
今天来说说前端的“判断”逻辑。
判断逻辑是指在指定结果里，选择某一个结果进行展示。
每个结果，都会有一个唯一的原因，
以关注按钮而言；
后端会告诉前端该用户是否已关注对方，0表示已关注，1表示未关注；
前端就判断这个参数是0还是1；
如果是0的话，就显示已关注按钮，或者隐藏关注按钮；
如果是1的话，就显示关注按钮。
判断条件的结果可能有多个，但一定是有限的，而且是一对一的。
比如有四种结果，那就是在四种结果中间进行判断。
