【3002】常用文档类别解释

BRD:Business Requirements Document 商业需求文档

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

MRD:Market Requirements Document 市场需求文档

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

PRD:Product Requirements Document 产品需求文档

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

FSD:Functional Specifications Document 功能详细说明

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

【1002】如何应对“别人有这个功能”

做产品经理,肯定曾经被多次提问这个问题:

“别人有这个功能,我们什么时候做?”

出现这个问题,大部分是需求方提出的,他们一般的理由都是:BAT哪个不是这么搞的,同行竞品都有这个功能,我要用这个功能。或者这么说吧,很多时候,大部分需求都是这么产生出来的。

作为产品经理,我相信同样的问题肯定有考虑过,并且比其他部门的人想的更深入,当然,有时候也会出现长期高强度的快速迭代,有些功能缺失看漏眼了,或者缺乏思考时间,没想到。在这个情况下,只要少用时间进行分析思考,相信你的见解也会比提问者更深入。

需求方有这个诉求,总要看看背后的原因是什么,凡事都是有原因的,你可以问:

“这个功能你想用来做什么?”

    “你想做这个功能背后的原因是什么?”

一般情况下,你听到的回答是:“这个功能能干这个这个这个……”

这里其实有个误区,功能提供的是方法和结果,一定是某个事情引出了他们的诉求,提出这个需求。我们要知道的并不是简单的这个功能能帮助他们干什么,而是他们要干什么,我们用什么方法去协助完成,或许这个功能可以,或许用别的方法也可以。同时也要考虑整个产品的整体结构性,既然原来没有这个功能,也是有原因的,要告诉他们原来没有这个功能的原因是什么,如果有,会产生什么关联的影响和效应。再之,要告诉他们这些功能别人虽然都存在,但具有一定的差异性,差异性背后的战略逻辑和政策思路是什么,如果真的要做,希望达到什么样的效果。

小结

在这个沟通过程中,尽可能的保持和睦,大家肯定都是为公司好,为团队好。但各自也有自己的立场,只要解决了事情就行,尽可能不要拔刀相见。只要把上述的关键点都问清楚了,最好把自己对这个需求的想法和思路描述表达,柔和的给予建议。这样,多来几次,别人就会觉得你考虑的比他们深入且长远,久而久之,既可以降低无效开发成本,又可以提升沟通效率,并在团队中建立良好的印象,话语中有一定的说服力。

【4001】关于文件名管理

在工作中,常常会遇到一个场景

  • 那文档叫什么来的?
  • 发了好多个文档,哪个是最新的?
  • 那文件好久了,找不到了。

常常出现这样的情况,一般出现在工作流不太规范的公司、大学宿舍和私人电脑等,没有对电脑中的文件名称进行合理的定义所导致的。今天根据我这些年的工作经验,介绍一个我比较喜欢的一种命名规则:

如上图,“【设计】小小航海家专题页V1.2.3_PC端”看到这个文件名,能让任何人很直观的知道这是个什么样的文件,用在什么地方。

前缀

首先要将文件有个宏观的分类,选择一个合适的维度,然后所有命名都是根据这个维度进行展开,就不会有命名打架或者命名冲突的情况出现。

文件名

关于这个文件的中心思想,表达清楚即可。最好是包含比较关键的文字,方便日后搜索或者找文件时的联想。

版本号

关于版本号,很多人命名喜欢在文件名后面加“1234……”,表示第一版第二版,这样不是不行,但日子久后,会忘记版本之间的区别,区别的大小,哪个是关键版本。通过三层到四层的定义,可以有效的看出一个文件的发展历程,哪个是重要版本,在什么阶段调整比较大,什么时候是小改动比较多等等。

环境/姓名/日期

这些都是辅助性的信息,这些内容大部分不是给自己看的,是工作流程协同合作中,给别人看的时候比较有用的标记。

小结

文件名的目的是让使用者可以清晰了解这是什么,只要能理解,怎么命名都无所谓。这个文件名的管理规范也是仅供参考,一套自己习惯用的规范,能更好的在记忆宫殿中寻找资料,能更好的归纳与总结。大家也可以根据自身情况,设计属于自己的一套文件名管理规范,希望小小的浅见能帮助大家。

 

【1001】今年的詹姆斯

    今年对于詹姆斯来说是艰难的一年,欧文的转会,队友的轮流伤病,2K游戏一样的转会交易,让今年的骑士完全没有过去的王者风范,詹姆斯的场均出场时间也估计是09年后最高。可以说,今年是詹姆斯背着骑士往前冲。

    第一轮对阵步行者,感觉已经不是普通的“季后詹”了,是“总决詹”。眼看还有猛龙和76在后面,真替詹姆斯累。站在詹姆斯角度,他有自己的目标,但道路总有起伏,并不会一帆风顺,虽不知赛季结束是否会有决定3,但作为当今联盟唯一有机会超越乔丹的人,真的没的黑了,33岁的人了,只希望他保重身体,打多几年球,这是老球迷都想看到的。

    说说今天,猛龙后场双枪真的是被詹姆斯打怕了,感觉这轮稳了,最多也就6场。对于东部的年轻人来讲,詹姆斯是座大山,太强大了。第一场在詹姆斯抢七后状态不佳,加上猛龙早早晋级以逸待劳,也被骑士加时胜出,就感觉猛龙已经泄气了。

    我也只是看完比赛,随便感慨下,写写字而已。

    人们往往看东西只会看光鲜面,詹姆斯有今天的能力,虽说身体天赋超群,但真的,背后付出的汗水可不是盖的,自问看球也有20年了,真没见过多少个这样的球员,太伟大了。在这个浮躁的社会,天天看到有人敲钟上市,融资过亿,一夜爆红的新闻,正因为这些新闻,让普通人觉得自己渺小,很多事情遥不可及。常常人们都会有各种借口和理由,去帮自己解脱,让自己好受,如果不对自己狠心点,是不可能成功的,成功是非常不容易的,“4点的洛杉矶”不是用来说的,科比是做出来的。

【3001】产品服务体系-Product Service System

导语

在网上看到的一个概念——Product Service System,暂时叫它产品服务体系

从纯产品到纯服务,逐渐过渡分为五种,并且举例说明。需要解释一下,这里说的产品可以是任何东西,例如实体、硬件或者软件,而服务通常指人工的服务,这里把产品和服务加在一起,可以认为是大产品的概念。

第一种,纯产品:Pure Product,简写为PP

用户使用的东西实体,不包含任何服务。例如我们进入711便利店,看到各种各样的商品,这个商品就是纯产品,我们买的是纯产品,若真有服务,这个服务并不是此商品的商家提供,是711便利店提供。

第二种,产品导向:Product Oriented,简写为PO

实体为主,包含少量服务。服务目的是让用户可以顺利使用产品,都是和产品紧密相关的服务。

Product Related:安装调试、保修服务、保养与耗材供应等,比如你买了空调,就会有人上门给你折腾到可以用的状态,买车的时候含3年10万公里保修,送几次保养,送几张机油券。

Advice and Consultancy:培训咨询服务,公司买了一套OA系统,就会有人来教大家怎么配置、怎么使用,你用的过程中碰到问题也可以寻求帮助。Apple Store里,给产品用户提供的一些课程,答疑解惑也是此类。

第三种,使用导向:Use Oriented,简写为UO

依然以实体为主,和PO的区别在于,供给方给你的不是所有权,而是长期独占的使用权(Product Lease),或者是某种条件下,比如一段时间的使用权(Product Renting/Sharing),甚至是共享的使用权(Product Pooling)。因为并非买断实体,所以相关的配套服务会跟上,确保使用顺利。

上面提到的,公司买一套OA系统,卖家可以选择完全卖给你(PO),也可以按时间卖你lisence,也可以按使用人数/使用量收费(下一种模式,RO)。你有骑行需求,满足你的产品服务可以是一辆自行车(PO),也可以是一辆叫ofo的自行车1小时的使用权(Product Renting/Sharing)。你有住的需求,有的情况下得买房(PO),有的情况下长租,有的情况下买酒店里N间夜的使用权(附带的服务比较多,比如打扫、叫早、送餐、洗衣等)。公司需要打印服务,可以买一台打印机(PO),然后自己买耗材,也可以买一台打印机的长期使用权,加上定期维护、补充耗材的服务(Product Lease)。坐车出行,用滴滴拼车的话更是可以只买一辆车在某一段行程内的一个座位(Product Pooling)。

第四种,结果导向:Result Oriented,简写为RO

到这里,就以服务为主了,你买的不是一个实体,而是一种结果,使用实体只是为了达成结果需要用的过程。

Activity Management:活动管理,类似外包,通常外包合同都包含了对服务质量进行控制的性能指标。典型的,大多数公司会把保洁工作外包出去,采购服务,只要拿到预期的结果就行,而不会选择购买(招聘)保洁人员。

Pay Per Service Unit:按用量付费,你家里用的水电煤都是这样,相应的服务是为了确保你正常使用。比如网络广告,按点击、按成交付费等模式都是按照某种用量在付费。去体检的时候,你做多少项目,给多少钱,莞式服务里貌似有某种菜单,也是这个模式。很多软件做版本区隔,也是类似的处理。

Functional Result:按有价值的结果收费,典型的例子是你需要“宜人的办公环境”(结果),而不是需要制冷设备或者冷气,你需要一次提升团队士气的团建,而不是需要一个教练、几组游戏。相关的还有买保险,你买的是一份保障,可以买不同级别,保额不同、条款不同,对应的服务结果也不同。

第五种,纯服务:Pure Service,简写为PS

纯服务也很好理解,就是钟点工,家政,家教之类的服务,买的就是他们的服务,他们的产品就是服务。

其实两两之间的界限也不是非黑即白,但整体从左到右有一种变化趋势:

从PO到UO,会造成的必然结果是短期收入减少,资产投入增加,利润减少,但预期利润增加,比如房企不买房,改做长租生意了,那就没有了卖房那一大笔的即时收入,在一段时间内的资金压力就很大。这表现在财务报表上就很难看,如果是上市公司,敢不敢做这样的决定?

从PP到PS,厂家与用户的关系有越来越紧密的趋势,触点越来越多,用户尝试的成本越来越低,PP的话,与用户的关系往往终止在销售达成的一刻,PS的话,与用户的关系往往真正开始于销售达成的一刻。在这个时代,这是一种利好,每家公司都应该想一想有没有更偏服务的模式。

不同的卖法,规模化(Scalable)的想象空间差别很大。比如卖车,瓶颈在于产量(Model 3),但卖已有车辆的使用权并抽成,瓶颈就完全不一样了。不同的卖法,可以充分利用“价格歧视”。比如UO卖软件1年的使用权,就没法向数据量大的用户收更多的钱,这时候改为RO根据数据量收费,即可以让数据量少的用户几乎免费使用,降低他们尝试的门槛,也可以充分赚取大客户的费用,对方也更愿意为好的结果付费。