不只是我自己在用excel,我还推荐朋友使用，在培训时，我也将excel需求文档的写法教给大家，并且将excel版本定义为需求文档的2.0 阶段。

　　写在文章之前：

　　这篇大概是我改的次数最多的文章，因为好处实在太多，最开始我从使用特性来分析，然后又从管理来分析，但总觉得不妥，毕竟这些好处并不是绝对的，还要看个人和团队的升级应用，然后就有了这版，绝对肯定一定大概也许可能打死不改的版本！

　　我决定，写几个最基础的好处，属于每一位用excel写需求文档都会拥抱它的好处。

　　需求可量化

　　如图，我们一旦使用excel写需求文档，会立即知晓需求数量，图中便有14个需求点。

　　你还记的上一个版本做了多少个需求吗？

　　我们使用excel来攥写需求文档，会很明确每个版本的需求量，比如我在上一个版本里总共开发的需求点有240个左右。

　　不论是word版本或者是原型图标注，在这一点上都无法做到与excel相同的效果。

　　（ps.我始终不认为原型图标注是一种需求文档的撰写方法，他应该是表现形式才对）

　　需求量化以后，我们能做到哪些事情？

　　将需求量化以后，我们可以轻易得到以上四个信息。

　　产品输出：

　　基本上每位产品经理都能生产需求，但却无法将这些需求进行均衡，这也是许多创业团队的PM进入成熟团队后，很难适应的问题。

　　每个开发团队的生产力都是有限的，越是成熟的团队，周期内开发的需求量越是显得均衡，比如一个月固定开发量在400-500之间。

　　当然开发团队的规模，技术能力，以及需求复杂度，都会影响可开发的需求量。

　　但这些的前提，我们得有能量化下来的需求才行。

　　需求变更：

　　需求变更不仅仅是让开发，测试同学深恶痛绝，也是我们产品从业人员心理的痛。

　　谁不想消灭需求变更呢？毕竟被大家不信任，以及质疑，总不是一件让人感到高兴的事情。

　　可似乎我们总是做不到“不变更”，甚至不知道自己的变更算严重还是在可接受范围。

　　量化以后，这些数据就能成为我们最大的评判工具。

　　在上个版本 一共有40个需求点出现了变更，这个版本变更记录只有20条，是不是离目标近了点？

　　即使某个版本出现变更较多的时候，比如出现了60个需求点变更，我们也能立即发现问题出在哪个环节，能发现自己对何种类型的需求掌握不足。

　　开发输出：

　　大概是习惯使然，我们一般都会质疑产品的需求遗漏，却不怎么会留意到功能漏做，一个好的团队 ，出现功能漏做的可能性比较低，但在团队初期时，这个问题，可是非常常见的。

　　我们可以借助规范的方法来避免这个问题，也是寄托于需求可量化的特性，能够统计到漏做的数量 ，也能关注到哪些需求容易漏做。

　　这是word乃至原型标注所不能达到的效果：需求可量化

　　需求量化后就可被统计，而有了统计，就会出现完成率，变更率

　　这部分就不再展开了，我们来看看除了需求可量化以外，我选择excel撰写需求文档的其他好处。

　　认识功能

　　这是我强调的另一个概念，对于产品经理而言，这是一个分水岭：认识功能。

　　其实有许多产品经理认识需求，但却不认识功能。

　　这并不是一个值得提倡的趋势，需求的来源我们可以理解成分析阶段的产物，也是一种想法，思考的表现，atv直播，但却终要功能来实现。

　　互联网产品经理本身有很大的局限性质，我们的想发必须依赖功能才得以实现，而这些功能都受到编程语言的限制，那就表示，功能是有限的。

　　需求是什么呢？