产品设计体会(3009)PD的几种文档

今天看到一篇讲述产品设计中几种文档的文章(一个老外的blogMichael on Product Management & Marketing),感觉很好,结合工作的实际整理一下。按照那篇文章的思路,从产品的抽象到具体主要产出的文档有BRDMRDPRDFSD

BRDBusiness Requirements Document,商业需求文档。这是产品生命周期中最早的问的文档,再早就应该是脑中的构思了,其内容涉及市场分析,销售策略,盈利预测等,通常是和老大们过的ppt,所以也就比较短小精炼,没有产品细节。

MRDMarket Requirements Document,市场需求文档。获得老大的认同后,产品进入实施,需要先出MRD,具体来说要有更细致的市场与竞争对手分析,通过哪些功能来实现商业目的,功能/非功能需求分哪几块,功能的优先级等等。实际工作中,这个阶段PD可能的产出物有Mind Manager的思维图,ExcelFeature List等。

iamsujie补:我们的模式下,上两种文档会合并成为BRD,参见“4004资源与BRD”)

PRDProduct Requirements Document,产品需求文档。进步一细化,这部分是PD写得最多的内容,也就是传统意义上的需求分析,我们这里主要指UCuse case)文档。主要内容有,功能使用的具体描述(参见下一篇:UC写作),Visio做的功能点业务流程,界面的说明,demo等。Demo方面,可能用dreamweaverps甚至画图板简单画一下,有时候也会有UI/UE支持,出高保真的demo,开发将来可以直接用的那种。

FSDFunctional Specifications Document,功能详细说明。有一点像“概要设计”,这步就开始往开发衔接了,产品UI、业务逻辑的细节都要确定,细化文档并保持更新。相应的,有很多内容,比如表结构设计,要由架构师来编写了。

再往后,就到“详细设计”和编码了,就此打住。

产品设计体会(4004)资源战争与BRD

2008年春。

产品团队刚刚经历了一场公司内部的战争,争夺的是下个月的开发工程师与测试工程师的资源。

先说一下为什么以前没有过这样的战争吧,因为公司原来是按照产品线划分的部门,这样对于某个产品来说,有自己的PD、开发与测试等,下个月要做哪些需求,完全可以在产品经理的层面上决定;而现在公司变成了按职能划分团队,有了统一的产品运营中心(PD和运营)、研发中心(所有开发工程师)、质控中心(所有测试工程师),这样的话,下个月各个产品就都想尽可能多的抢到开发与测试,然而资源总是严重不足的,所以最终做哪些,就必须要上升到几个中心的大老板层面来决定了,而大老板的决策依据就是各个产品经理的pk,对各自产品发展BRDBusiness Requirement Document)的描述,于是,战争爆发了,:)

所以前段时间,大家一起在准备BRD,这就是我们的武器,我们需要尽力说明我们要做的东西的商业价值,才能抢到各种资源,因为在pk之前,全公司的资源需求已经是现有资源的好几倍了……(一般以“人日”来简单估算衡量,有同学说一群人pk简称群p,就是多争取点~~~~~~,呃,很邪恶!)

武器主要包含以下几个部分:项目概述、项目背景、商业价值分析(重点!大老板最感兴趣的,一定要说在点子上)、功能需求描述、其它需求、资源评估(重点2!大老板们要看成本)、风险和对策。大家可能也发现了,其实本质上还是那个词——性价比

当然同学们也会搞点技巧性的东西,比如卖个破绽,故意加入一些让老板砍的东西,有点类似谈判技巧里的玩意。

最后谈一下两种组织架构的各自优缺点,按产品线划分的部门对产品本身是有利的,产品经理可以按照自己的想法做,资源有保证,产品规划不会被动改变,它的缺点也就是按职能分部门的优点;职能部门对全公司的资源共享有利,确保所有资源都用在对公司最有意义的产品上,另外它能把资源战争的鲶鱼效应从产品内部扩大到公司层面,使PD和产品经理们更抓狂的去为产品的发展而苦苦思索……

iamsujie补:

1.     两种组织结构的变化,我的理解是公司自然发展的必然过程,随着产品的增多,全公司变成了越来越多个资源局部最优,他们之间可以互补的资源越来越多,此时全局最优的效益越来越明显,所以打通。

2.     产品线的优势,还有个是沟通的顺畅,单线领导,都向产品经理负责。

3.     更多有关组织结构的讨论,其他篇章里还有描述。