需求文档2.0：我为什么用 Excel 写需求文档

正文

请到「今天看啥」查看全文

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

产品输出：

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

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

当然开发团队的规模，技术能力，以及需求复杂度，都会影响可开发的需求量。但这些的前提，我们得有能量化下来的需求才行。

需求变更：

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

谁不想消灭需求变更呢？毕竟被大家不信任，以及质疑，总不是一件让人感到高兴的事情。可似乎我们总是做不到“不变更”，甚至不知道自己的变更算严重还是在可接受范围。

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

在上个版本一共有 40 个需求点出现了变更，这个版本变更记录只有 20 条，是不是离目标近了点？即使某个版本出现变更较多的时候，比如出现了 60 个需求点变更，我们也能立即发现问题出在哪个环节，能发现自己对何种类型的需求掌握不足。

开发输出：

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

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

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

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

请到「今天看啥」查看全文