请经营好自己的需求库，他将会成为你个人价值的一部分

网络中，已有太多关于PRD撰写方法的文章了，包括我自己也曾分享过一个技巧，但是，你知道为什么要写需求文档吗？

文档我们可能写过很多了，但是有没有发现他的重要性呢？或者说，在实际工作过程中，除了评审以外，是不是就没有什么时候用到了？

我还是强调这个观念： 10年后的现在，产品经理已经从探索阶段逐渐发展到规模阶段并且正在向标准化发展。

最早对于PRD文档的定义，在于需求评审，以及对需求的表达。但这对于现在来讲是不够的（如果仅仅将需求文档当做是表达，或者是评审的载体，那您仔细阅读本文的内容吧，或许对你有所启发）。

我们一起来看看，需求文档在这些地方产生的影响。

产品技能的熟练度

对于app、HTML5、web的产品而言，我们的功能很大程度是受限于编程语言的，所有的功能都包含在我们基本不会触及到的编码边界内。

这个是我亲身经历的一个示例：一个编码边界值在android平台里，能够调用的方法不能超过65536个；一旦超过后，就会无法编译，并且提示你错误信息。

这意味着什么呢？ 这意味着：并不存在真正意义上的“创造”，我们所谓的“创造”产品，都是基于已有规则内的“应用”。

你觉得不同平台之间的手机号码注册以及第三方登陆，会有什么不一样的吗？其实大家都是一样的，我们都是基于一定条件下，对规则、对逻辑的应用。

既然是“应用”，就会出现熟练度的问题。

你有没有发现大量功能的背后，是存在“类型”的，相同“类型”的功能，他的需求文档总是惊人的相似，你需要做的，也许只是调整“参数”。

我们拿个人资料来看看吧，看看他们都是什么样的功能类型。

微信的个人资料，设计的很是巧妙，他将预览和编辑分离了，这对我们去理解这个命题很有帮助。

我会这样来写他们的需求文档：

点击类的功能，不仅仅适用于个人资料，在我们的信息流页面，基本上都是点击类的功能，你要做的是将需求描述后面的跳转页面地址更换成正确的地址，就足够了。

我们往往会先绘制原型图，再对比原型图进行需求文档的撰写，这是为了减少调整的幅度，也是为了需求的完整度，要知道很多功能随着原型图的改变而改变。

当你在看着原型图时，能否立即反应出这个页面都是什么“类型”的功能，这种“类型”的功能，通常都会有哪些“功能点”？

这是我们对产品技能掌握的熟练度。

我需要向你再次强调一件事实，就目前市面上大部分的产品而言，我们的需求文档是相同的！你未来要做的一款新的产品， 他的需求文档也和你现在正在做的产品，是相同的，你所需要的，仅仅是将已有的需求文档，重新排列，组合。

这正如我告知你的： 我们只是对规则的“应用”， 并不曾真的创造“规则”。

减少不必要的思考时间

从自私的角度来讲，需求文档大概是你能够为自己做的最偷懒的事情吧，但也是你最应该做的事情。

现在，我在设计一个信息流时，我大概需要5分钟来写这个页面的需求文档吧？而且我可以肯定的告诉你，这份文档会很完整，包括错误机制，数据获取机制等等。保守估计，这会有40个需求点，你需要多少时间呢？

我能做到这点的原因很简单，我对需求非常熟悉，熟悉到我只需要从我以前的需求库中copy出来，做微小的调整就可以了。

当你拥有了一个需求库，这个库里保存了你一直精心维护的需求文档，并且你平常空闲时会将他们做整理，分类，让他们更像一个库而不是文档这会是什么感觉吗？

这将会为你减少非常多的工作时间，如果每一个版本的研发周期是3周， 你在需求文档上花的时间应该会在2天以上，并且这还会容易遗漏需求。

有没有发现，我们大部分的时间是在做重复的事情吗？ 不断的重复的写着“点击跳转xxx”“字符长度xx位”。

难道你没想过有什么样的办法，把这些重复的，又占据了你很多时间的工作处理一下吗？当你开始建立需求库时，当你开始去经营自己的需求库时，就像经营一个只为你服务的“产品”时，你应该很快就能从这样的状况里解放出来了。

你也不需要每一次写需求文档，都再去思考、担心有没有遗漏的，这样的参数合不合理。这是因为：他已经被使用过了，因为这是在你曾经的项目过程中，就如此使用了；如果有问题， 那也一定在文档里进行过修改了。

如果你对需求文档足够的重视，他将会在你未来的时间，也许是一年，也许是半年，开始回报给你。

减少团队时间耗损

需求文档节省的不仅仅是自己的时间，好的需求文档还会为整个团队带来可观的时间节省。

对于QA而言，是需要产出test case，这和我们产出需求文档时一样的，不一样的地方在于，如果你的需求文档不够详细，那么QA同学将会把我们的工作重新做一遍，并且这里面的时间耗损将是1+1>2的状况。

这是因为在QA按照你的粗糙的需求文档编写测试用例时，会反复找你沟通，确认需求，因为没有明确的需求表达，QA同学无法界定程序实现的正确，或者错误。

对于研发而言，你有没有发现 Android 和IOS在同一个功能上用了不同的实现方法，我曾经遇到过。

在我们的需求文档里，没有提及首页在数据请求后，需要将内容缓存下来，当然，文档里，也没有提到“不缓存”，于是我们的IOS 没有缓存数据，而android 缓存了，最后的结果，无论是缓存还是不缓存，都有一端需要调整。

你的需求文档，能够最大限度的解决研发过程的漏做，错做，自定义需求三种恶劣情况的产生，从而减少研发同学的编程耗时。

数据分析

我已经和你提及了需求文档将会为你还有你的团队，减少许多不必要的时间耗损，相应的等同于提高了整个项目组的产能， 这只需要你重视自己的需求文档。

我还会为你介绍一个原因，数据分析，这将帮助你成长。

我们这里提到的数据分析，实际上需要你 对数据足够敏感，具备数据驱动的一些思维。

你在实际工作中，会反复经历评审，研发，评审，研发的循环，如果是这样，你一定会经历另外一件事情：“需求被拒绝”。

需求被拒绝的原因有很多，诸如上层不通过，研发拒绝等等，当你把这些被拒绝的需求单独拿出来进行分析时，你会不会发现里面的“共性”呢？

而这些共性，则会加强你对需求的掌控力，让你知道什么是“可以实现”，什么是“无法实现”。

冒昧问一下， 产品新人，和产品老司机的明显差异不是正好包含：知道什么能做，也正好知道什么不能做吗？

最后，我希望你真的能够重视你的需求文档，建立好自己的需求库，这好比研发人员手里的代码一样，他将会成为你个人价值的一部分。

作家#

枯叶，微信公众号，枯叶咖啡馆。擅长社交，社区，细分群体挖掘。

关键字：产品经理, 文档

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！