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