美文网首页产品微言@产品产品经理
还在写PRD?早点抛弃word吧

还在写PRD?早点抛弃word吧

作者: dusong | 来源:发表于2017-09-12 14:32 被阅读311次

    PRD对产品开发的重要性无需多费笔墨,但PM们经常遇到一个尴尬,“写多了大家未必都会看;写少了又怕别人不懂”。实际上,PRD的问题不在于如何写而在于让团队能够理解业务,以及开发过程中如何被传递与执行。

    还在写PRD?早点抛弃word吧

    PRD的撰写,最开始几乎所有人都是用WORD,其一是当时没有更便捷的工具,上手容易,目录大纲清晰,但这种方式对撰写者而言其实是非常痛苦对过程,对阅读者而言很不直观,很难快速对理解全文。

    曾经负责过一个项目,应甲方要求,洋洋洒洒输出六万余字的PRD(一式三份打印出来,推在桌上蔚为壮观),依然感觉意犹未尽。这种巨幅的PRD文档,在传统软件领域,极为普通。尴尬的是,这种文档往往写完就束之高阁。

    对一份PRD来说,没有什么比可读性还重要的事情了。可能的情况下,尽量不要输出WORD版本的PRD,WORD版本的PRD文档会随着内容的增长可读性直线下滑,原因在于WORD更善于线性描述。

    写在前面的几个建议


    1、PRD有且只有一个目的,描述清楚要做什么,怎么做,并保证团队的及时同步;

    2、不要列“需求格子”,任何一个功能方案不要再用传统的软件工程师法来描述“前置条件”、“状态机”、“输入”、“输出”这种格式来框定需求,它会使得产品的功能仅仅是功能,这是给产品带来风险的一个引子;

    3、让你的PRD只有一份是个不错的尝试,文档多了,除了增加管理成本之外,就是让人不知道从哪里去找想要的东西;

    4、程序猿并不是害怕产品经理变更需求,而是害怕产品经理自己没有想清楚,给出的产品方案难以自圆其说,反复修改而又达不到想要的结果;

    5、让团队的每个人都参与进来,发挥程序猿的主观能动性,认真听取来自技术、设计、测试端的那些“莫名其妙”的建议,善用并适当采纳这些建议,你会发现很多事情会简单很多;

    6、放松一点,保持头脑清醒,激活你的团队,让成员给你反馈。

    以上,供你参考。

    从现在出发,我们的目的是让你的PRD相对轻便,别人愿意看,自己也不太“痛苦纠结”。

    1、文档架构


    任何一份文档都有其框架结构,目的是使得整个文档的逻辑更清晰,增加可读性,也就是让别人能够快速的知道应该怎么查阅。

    通常来说,一份PRD至少包括下述内容:

    1、版本摘要:让你的团队成员明白为什么做;

    2、变更日志:让你的团队成员知道你“又做了什么手脚”;

    3、产品原则:通用性的规范,让所有人都知道应该遵从什么标准,什么要求,做成什么样;

    4、功能结构:通俗一点的说法就是,“用图来描述”你现在想从哪里动刀子了,是要改动“个人资料”模块还是订单页面;

    5、关键流程:别什么都画一个图,把核心的流程描述清楚即可;逻辑完整,你宁可缺少一些场景的逻辑,而不是连一个场景都讲不清楚;

    6、故事板与原型:用场景化的语言描述某个功能是什么,配合适当的例子,让团队成员真正理解这个场景下的用户行为。

    所以,在用Axure直出PRD时,建议增加一个文档导航系统,是为了清晰的引导团队成员看快速找到他所关注的内容。

    PRD框架

    为什么要有导航?

    1、从这个导航结构,所有人都能一眼就明白这个版本的概貌,能清晰的知道要做什么,也知道你又改了什么,更重要的是,这个结构的第一步描述了整个版本为什么要做的原因——需求的出处,以及产品的价值。

    2、如果有条件的情况下,可以弄一个小型的服务器,整个团队其实只需要通过浏览器直接范围这个地址即可。【一定要创造条件,避免产品原型,或RP文件,或压缩包通过邮件、QQ、微信漫天飞的现象。

    产品经理有责任确保整个团队只有一个需求的输入口——需求的及时同步,产品经理也需要确保流转到下一个任何环节都是经过确认的版本。

    2、版本摘要


    版本摘要

    版本定义与目的:

    在定义一个版本,编写一份PRD的时候,整个团队首先需要了解的是,这个版本为什么要做,做了有什么用。尝试描述这些问题有很大的帮助:

    为什么要这个版本,是运营驱动还是产品驱动?
    这个版本主要做了什么,能为用户带来什么?
    做完这个版本,对产品的竞争力能带来什么提升?

    里程碑计划:

    很多公司,产品经理和项目经理是完全两个不同的角色,通过彼此的协调配合共同来推进一个项目【迭代】。但在一些创业公司,或者相对小型一些的企业,产品经理&项目经理统称为PM,有PM来统筹资源,推进进度,当然也包括产品需求。对这一类的产品经理而已,必须把控整个项目的进度。

    在这种工作环境下,需要保证整个团队(从上到下)对进度节点的一致认可和知悉,并尽可能的严格按照计划来执行。否则,极容易出现场面失控,一口又一口结结实实的锅,会让PM们吃不完兜着走。

    具体到项目进度的编制、执行和控制,是另外一个话题,暂且略过。

    其他:

    摘要都可以起到一个极好的归纳作用,引领整个团队正确的理解项目。视不同的情况,不同的产品(业务)类型,版本的摘要有完全不同的内容,如果是乙方的项目,则还可以把项目架构,沟通机制都作为一个摘要来传递。

    再次提醒:尽可能的把文档归拢,而不是完全依赖邮件满天飞。

    3、变更日志


    所有应对和管理需求变更的“奇淫技巧”,首先要的是能够从心理上有所准备,能够摆正心态正确面对需求的变更,然后才是通过恰当的手段管理需求变更——不要想着去控制变更,一字之差之间有很大的不同。

    最善变的,不是你的女朋友,而是“需求”。

    需求变更记录

    需求变更带来的困境:

    额外的开销
    项目的延期
    团队士气低落
    质量失控

    应对需求变更的建议

    (1)通过角色扮演来挖掘需求

    这个锅,产品经理得彻底背起来。

    需求的频繁变动,往往最根本的原因就是需求与用户的真实场景相背离,产品经理直接套用了用(ling)户(dao)们(men)的“解决方案”演变为功能需求,导致在整个功能的设计阶段,流程梳理环节越走越远而往往不能够自知,鉴于此,产品经理一定要学会如何扮演角色,倒推场景下的用户行为。

    只有在这个阶段,把自己演变为“小白”才可能真正发现和理解用户——秀一场cosplay吧。

    (2)借助团队的力量验证需求

    不要维护自己的方案,你的方案第一次拿出给到设计师、程序猿的时候,就是为了让他们来给你找出问题,在第一次需求评审的时候,尽可能的倾听来自团队的声音,你应该把第一次需求评审会议改为“需求表演会”。

    产品经理应该要理解,只要在越早期的时候,被研发质疑,然后再通过需求验证,才能让团队感受到这些团队的力量,你应该让你的团队协助你,而不是让他们按照你的方案来执行。

    (3)保持需求的唯一出口

    这是一个重大的灾难。

    需求多端发起,特别是甲乙方的项目,涉及的干系人过多,以及跨部门协作的时候,每个人都在发表声音,从而导致局面彻底失控。

    这就是为什么建议在一份PRD的开头明确一个协同规则的根本原因,把它作为项目的头等大事,写在最首要的位置,时刻同步给到每一个人。

    产品经理应该尽可能的建立一种“只有PM确认的工作才付诸行动”的氛围。

    (4)保持持续性更新

    需求变更的另外一个重要原因就是,需求没有及时同步,任何一个小的变更,一定要随时同步到整个团队,它除了影响研发之外,还包括设计、测试团队,以及后续的运营团队。

    所有的关于需求变更技法,都是在补救你此前捅过的娄子和埋下的雷。

    不要奢望能躲避需求变更,而是要引导和管理在合适的范围内。不要害怕变更,毕竟唯一不变的,就是变化。

    4、产品原则


    产品经理应该尽早制定一份产品的基本原则,什么能做,什么不做。当然,这里可以完整的描述从体验角度需要遵从的基本规范。

    基本原则

    这里没有太多的建议和参考,你的产品原则,既可以是战略性的,也可以是产品功能性的,可以大到决定产品方向,可以小到颜色字体。

    制定产品规范(原则)的目的,是为了保障产品的体验一致性。更重要的是,保护你的产品不出现意外。产品经理应该尽可能的从多维度制定规则,但不要过于复杂。越是方向上的东西越是要简单。例如微信,如果倾向于发信者的立场,在后续的版本过程中更多的维护发信者的体验;如果是倾向于收信者的立场,则一定在保障发信者的体验。

    任何产品都很难照顾到产品的所有角色,必须明确产品的侧重点是什么。

    5、功能架构

    想象一栋楼,你能看到有地基、柱子、横梁、墙面、屋顶,这个楼之所以不会轻易垮塌,就是因为这些部件构建了一种稳固的结构——物理架构。你一定很快就能想象得到,房子要能适合居住,就得有进排水(系统),得有电力供应(系统)等等,这就从逻辑层来构建一栋楼的结构。

    从这样一个粗糙的描述里面,你应该能够理解,所谓架构,就是把各个部件进行归纳汇总,提炼抽象,并通过适当的链接方式打造成一个稳定的形状,满足人们的实际需要。

    在你面对一个产品/一个需求的时候,应该能在脑海里勾画出模型,什么东西是4个桌腿,什么东西是一个桌面,4条腿和一个桌面如何共同构建和支撑这个业务的稳定运行。

    功能架构

    通常情况下,一份PRD中,只需从物理结构层详尽的描述“功能结构”即可。

    实际情况是,有的时候你并不需要画一个结构图,因为产品的结构可能已经千年不变了,这个版本也可能仅仅是修复一些问题,甚至只是把方形的用户头像改成圆形——因为你的老板觉得好看。

    产品架构不仅是能支撑当下的业务,也要能具备适度的扩展性和容错性。

    6、关键流程

    越是复杂的系统,越是推荐把流程图做一个目录,不但是引导阅读者,而是检查遗漏的方法。

    产品经理在绘制流程图的时候,尽可能的遵从通用的规范,并养成养好的习惯。好的流程图,可以快速让整个团队熟悉理解业务,并优化业务。

    业务流程

    梳理业务流程的步骤,估计没有多少经验的产品经理们都能想象得到,先要去调研,然后画成图,在这个过程里面会有确认,完善的工作。

    调研的过程是为了解决who,what,why,how,以及where的问题:谁,在什么情况下,做了什么事情,这个事情需要什么前置条件,又输出了什么,这个事情在哪里完成的?

    但这极可能陷入形式主义性质的错误,这种调研仅仅是在知道“用户现在怎么做?”最后极可能得出一个流水式的糊涂账。

    产品经理需要的是探索更深层次的问题,为什么要这么做,为什么不这么做?

    流程的基本意思是指水流的路程,也就是工作进行中的次序或顺序的布置和安排,由两个及以上的业务步骤,完成一个完整的业务行为的过程。

    对一项业务来说,从它的输入到最终的结果,理论上来说就是一张流程图就可以画完整,但为什么不这么做呢?

    没有多少人可以一口气看完一张横跨多个业务角色、多个业务部门的流程图后,能有一个全局的概念。这种形式的流程图,会让人陷入一种不可收拾的泥潭中。

    产品经理不仅仅是要知道每个环节的流程,更要理解整个业务的体系,并协助团队成员从全局来理解业务逻辑。你需要把业务的核心剥离得出来,抽象出多个可以支撑业务的关键支点。只有先搭建了一个好的戏台,人物角色才能够全面铺开。在你的脑海中想象一串葡萄的样子,你的业务流程图也应该是这样,一条主线若个支线无数节点。

    每一项业务通常都能找到它的关键支撑点,比如O2O项目,我们可以抽象归类出“受理、派单、接单、回单、回访”5个业务动作,通过这5个基本的业务动作,能够让整套系统流转不同的业务单据,能够支撑多个的业务角色,而不是简单粗暴的让流程跟着单据走,不能演变出新增/删减一份单据都需要重新定义、修改流程的局面。

    实际上,你应该发现,对产品经理而言,是先有业务,再做框架,然后是功能,最后是过程。一定要避免直接操刀把一个产品拆分成多少个模块,模块多少页面,页面内是什么按钮。

    7、故事板与原型

    所谓的用户故事,就是描述用户想要实现的功能,最简单的说法,就是“谁想要干嘛”。

    用户故事

    产品经理们的PRD文档会出现”写了没有人看“的尴尬,一个重要原因就是用户需求的描述方式。

    你写了很多也足够细致,但读文档的人却始终没有办法进入角色。过于技术化的描述让人昏昏欲睡没有思考的欲望,根本在于阅读者不能通过角色置换想象一个用户在干嘛,要干嘛,以及为什么。

    随着业务复杂性的提升,”需求清单“会变成像裹脚布一样让人不愿意忍受。

    根据用户的业务场景写成故事板,而不是列出一张”需求清单“。这么做的目的是为了保证团队能够理解、认同为什么要这个功能,以及用户是怎么做的,并引发团队的思考。

    产品经理描述的功能需求(故事板),应该尽量用团队可以理解的业务语言来描述,而不是描述诸如字段,存储的技术语言。

    作为产品经理,必须把重心放在用户所能理解的问题上。你解决的是用户的问题,而不是程序猿们的问题。比如页面响应速度这个问题,产品经理可以描述为“启动页3秒后自动跳转到首页”,而忽略“响应速度”本身是个什么概念——原因在于你的用户并不能理解你的响应速度,而你应该像你的用户一样思考问题。

    故事板并不是为了追求完整性,而在于它能够被理解和有价值。

    所以,不太建议过于在意”故事板怎么描述“这个问题,这可能不是最重要的是问题。关键是场景覆盖的程度,覆盖越广,适应性会更强,程度越深,可能用户的体验相对会更好一些。产品经理需要在不同的版本里面权衡在什么版本做什么功能,二八法则可能是你很好的一个工具。

    想办法让你的团队在你的文档里面”看见“用户的具体行为动作,在每个人的脑海中构建出一副生动的画面,你的PRD才会有活力。

    关于axure

    如果你正准备尝试Axure直出PRD,这几条建议可能对你有用:

    1、使用最新的Axure版本;

    2、使用内联框架,可以让你把整个原型串联起来;

    3、尽量多用母版,不仅提升了效率,母版还能够协助你合理的解耦;

    4、组合是个好东西,特别是Axure 8以后给了组合更多的属性,你可以像用部件一样使用组合;

    5、动态面板要学会,它能充分展示一些交互过程,也要慎重,过多的面板降低了原型本身的协作,在早期的版本中,动态面板还会明显降低原型的流畅度;

    6、掌握栅格系统;

    7、Axure是个极好的工具,它几乎可以胜任写PRD的全部工作,掌握它是应该的,把它耍得很酷,看你的工作量和时间;

    8、保存清醒,不要炫技。

    PRD的问题不在于如何写而在于让团队能够理解业务,以及开发过程中如何被传递与执行。但是,作为PM,应该尽可能的追求更为高效的表达方式。

    9、模板下载


    百度云盘下载链接:http://pan.baidu.com/s/1sljsJJv 密码:xx32

    这不是一个完整的例子,只是为了表达你可以考虑尝试这种架构让你的PRD更可读,也便于管理。

    如果你有更好的点子,可以直接留言告诉我。

    如果你觉得需要的话,可任意使用这个模板。

    —— END ——

    相关文章

      网友评论

      • 老虎色:PRD的目的是为了清楚、清晰的记录功能需求,楼主的意思不是说不需要写或者不用wor写,而是一种良好的写作规范方式。
        比如我们可以在用原型+备注的方式来代替PRD的一些内容。
        PRD和原型还是相辅相成的,比如手机号我需要判断1开头,11位,纯数字,输入12、11、10都为错,这四种判断如果要做原型就需要较为复杂,如果写文字就较为简单。
        dusong:@老虎色 嗯,是的,简直深得我心
      • c692c01d718c:现在大部分公司都不用word写文档了吗
        dusong:@苹果为什么会变烂 word的文档可读性不高

      本文标题:还在写PRD?早点抛弃word吧

      本文链接:https://www.haomeiwen.com/subject/ldycsxtx.html