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

请经营好自己的需求库，他将会成为你个人价值的一部分 网络中，已有太多关于 PRD 撰写方法的文章了，包括我自己也曾分享过一个技巧，但是，你 知道为什么要写需求文档吗？ 文档我们可能写过很多了，但是有没有发现他的重要性呢？或者说，在实际工作过程中，除了评审 以外，是不是就没有什么时候用到了？ 我还是强调这个观念： 10 年后的现在，产品经理已经从探索阶段逐渐发展到规模阶段并且正在向标 准化发展。 最早对于 PRD 文档的定义，在于需求评审，以及对需求的表达。但这对于现在来讲是不够的（如果 仅仅将需求文档当做是表达，或者是评审的载体，那您仔细阅读本文的内容吧，或许对你有所 启发）。 我们一起来看看，需求文档在这些地方产生的影响。 产品技能的熟练度 对于 app 、HT ML5 、web 的产品而言，我们的功能很大程度是受限于编程语言的，所有的功能都包 含在我们基本不会触及到的编码边界内。 这个是我亲身经历的一个示例：一个编码边界值在 android 平台里，能够调用的方法不能超 过65536 个；一旦超过后，就会无法编译，并且提示你错误信息。 这意味着什么呢？ 这意味着：并不存在真正意义上的 创造“ ”，我们所谓的 创造“ ”产品，都是基于已有 规则内的 应用“ ”。 你觉得不同平台之间的手机号码注册以及第三方登陆，会有什么不一样的吗？其实大家都是一样的 ，我们都是基于一定条件下，对规则、对逻辑的应用。 既然是 应用“ ”，就会出现熟练度的问题。 你有没有发现大量功能的背后，是存在 类型“ ”的，相同 类型“ ”的功能，他的需求文档总是惊人的相似 ，你需要做的，也许只是调整 参数“ ”。 我们拿个人资料来看看吧，看看他们都是什么样的功能类型。 微信的个人资料，设计的很是巧妙，他将预览和编辑分离了，这对我们去理解这个命题很有帮助。 我会这样来写他们的需求文档： 点击类的功能，不仅仅适用于个人资料，在我们的信息流页面，基本上都是点击类的功能，你要做 的是将需求描述后面的跳转页面地址更换成正确的地址，就足够了。 我们往往会先绘制原型图，再对比原型图进行需求文档的撰写，这是为了减少调整的幅度，也是为 了需求的完整度，要知道很多功能随着原型图的改变而改变。 当你在看着原型图时，能否立即反应出这个页面都是什么 类型“ ”的功能，这种 类型“ ”的功能，通常都 会有哪些 功能点“ ”？ 这是我们对产品技能掌握的熟练度。 我需要向你再次强调一件事实，就目前市面上大部分的产品而言，我们的需求文档是相同的 ！你未来要做的一款新的产品， 他的需求文档也和你现在正在做的产品，是相同的，你所需 要的，仅仅是将已有的需求文档，重新排列，组合。 这正如我告知你的： 我们只是对规则的 应用“ ”， 并不曾真的创造 规则“ ”。 减少不必要的思考时间 从自私的角度来讲，需求文档大概是你能够为自己做的最偷懒的事情吧，但也是你最应该做的事情 。 现在，我在设计一个信息流时，我大概需要 5 分钟来写这个页面的需求文档吧？而且我可以肯定的告 诉你，这份文档会很完整，包括错误机制，数据获取机制等等。保守估计，这会有 40 个需求点，你 需要多少时间呢？ 我能做到这点的原因很简单，我对需求非常熟悉，熟悉到我只需要从我以前的需求库中 copy 出来， 做微小的调整就可以了。 当你拥有了一个需求库，这个库里保存了你一直精心维护的需求文档，并且你平常空闲时会将他们 做整理，分类，让他们更像一个库而不是文档这会是什么感觉吗？ 这将会为你减少非常多的工作时间，如果每一个版本的研发周期是 3周， 你在需求文档上花的时间 应该会在 2天以上，并且这还会容易遗漏需求。 有没有发现，我们大部分的时间是在做重复的事情吗？ 不断的重复的写着 点击跳转“ xxx ”“字符长 度xx 位 ”。 难道你没想过有什么样的办法，把这些重复的，又占据了你很多时间的工作处理一下吗？当你开始 建立需求库时，当你开始去经营自己的需求库时，就像经营一个