PRD之道：活用Axure快速撰写轻便的需求文档

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

关于PRD的几个建议
1、PRD有且只有一个目的，描述清楚要做什么，怎么做，并保证团队的及时同步；

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

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

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

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

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

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

以上，供你参考。

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

文档导航：让你的团队成员知道怎么看，尽可能一份文档描述清楚而又完整；
版本摘要：让你的团队成员明白为什么做；
变更日志：让你的团队成员知道你“又做了什么手脚”；
产品原则：通用性的规范，让所有人都知道应该遵从什么标准，什么要求，做成什么样；
功能结构：通俗一点的说法就是，“用图来描述”你现在想从哪里动刀子了，是要改动“个人资料”模块还是订单页面；
关键流程：别什么都画一个图，把核心的流程描述清楚即可；逻辑完整，你宁可缺少一些场景的逻辑，而不是连一个场景都讲不清楚；
故事板与原型：用场景化的语言描述某个功能是什么，配合适当的例子，让团队成员真正理解这个场景下的用户行为。
文档导航
给PRD加一个导航系统，是为了清晰的引导团队成员看快速找到他所关注的内容。

为什么要有导航？

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

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

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

版本摘要

版本定义与目的

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

为什么要这个版本，是运营驱动还是产品驱动？
这个版本主要做了什么，能为用户带来什么？
做完这个版本，对产品的竞争力能带来什么提升？
里程碑计划

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

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

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

其他

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

一个建议是，尽可能的把文档归拢，而不是完全依赖邮件满天飞。

变更日志

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

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

需求变更带来的困境
额外的开销
项目的延期
团队士气低落
质量失控

应对需求变更的建议

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

这个锅，产品经理得彻底背起来。需求的频繁变动，往往最根本的原因就是需求与用户的真实场景相背离，产品经理直接套用了用（ling）户（dao）们（men）的“解决方案”演变为功能需求，导致在整个功能的设计阶段，流程梳理环节越走越远而往往不能够自知，鉴于此，产品经理一定要学会如何扮演角色，倒推场景下的用户行为。只有在这个阶段，把自己演变为“小白”才可能真正发现和理解用户——秀一场cosplay吧。

（2）借助团队的力量验证需求

不要维护自己的方案，你的方案第一次拿出给到设计师、程序猿的时候，就是为了让他们来给你找出问题，在第一次需求评审的时候，尽可能的倾听来自团队的声音，你应该把第一次需求评审会议改为“需求表演会”。产品经理应该要理解，只要在越早期的时候，被研发质疑，然后再通过需求验证，才能让团队感受到这些团队的力量，你应该让你的团队协助你，而不是让他们按照你的方案来执行。

（3）保持需求的唯一出口

这是一个重大的灾难。需求多端发起，特别是甲乙方的项目，涉及的干系人过多，以及跨部门协作的时候，每个人都在发表声音，从而导致局面彻底失控。这就是为什么建议在一份PRD的开头明确一个协同规则的根本原因，把它作为项目的头等大事，写在最首要的位置，时刻同步给到每一个人。产品经理应该尽可能的建立一种“只有PM确认的工作才付诸行动”的氛围。

（4）保持持续性更新

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

所有的关于需求变更技法，都是在补救你此前捅过的娄子和埋下的雷。不要奢望能躲避需求变更，而是要引导和管理在合适的范围内。
不要害怕变更，毕竟唯一不变的，就是变化。

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

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

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

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

功能架构

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

从这样一个粗糙的描述里面，你应该能够理解，所谓架构，就是把各个部件进行归纳汇总，提炼抽象，并通过适当的链接方式打造成一个稳定的形状，满足人们的实际需要。在你面对一个产品/一个需求的时候，应该能在脑海里勾画出模型，什么东西是4个桌腿，什么东西是一个桌面，4条腿和一个桌面如何共同构建和支撑这个业务的稳定运行。

通常情况下，一份PRD中，只需从物理结构层详尽的描述“功能结构”即可。实际情况是，有的情况下，你并不需要画一个结构图，因为产品的结构可能已经千年不变了，这个版本也可能仅仅是修复一些问题，甚至只是把方形的用户头像改成圆形——因为你的老板觉得好看。

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

关键流程

越是复杂的系统，越是推荐把流程图做一个目录，不但是引导阅读者，而是检查遗漏的方法。同时，产品经理在绘制流程图的时候，尽可能的遵从通用的规范，并养成养好的习惯。好的流程图，可以快速让整个团队熟悉理解业务，并优化业务。

梳理业务流程的步骤，估计没有多少经验的产品经理们都能想象得到，先要去调研，然后画成图，在这个过程里面会有确认，完善的工作。调研的过程是为了解决who，what，why，how，以及where的问题：谁，在什么情况下，做了什么事情，这个事情需要什么前置条件，又输出了什么，这个事情在哪里完成的

但这极可能陷入形式主义性质的错误，这种调研仅仅是在知道“用户现在怎么做？”最后极可能得出一个流水式的糊涂账。产品经理需要的是探索更深层次的问题，为什么要这么做，为什么不这么做？
流程的基本意思是指水流的路程，也就是工作进行中的次序或顺序的布置和安排，由两个及以上的业务步骤，完成一个完整的业务行为的过程。对一项业务来说，从它的输入到最终的结果，理论上来说就是一张流程图就可以画完整，但为什么不这么做呢？

没有多少人可以一口气看完一张横跨多个业务角色、多个业务部门的流程图后，能有一个全局的概念。这种形式的流程图，会让人陷入一种不可收拾的泥潭中。产品经理不仅仅是要知道每个环节的流程，更要理解整个业务的体系，并协助团队成员从全局来理解业务逻辑。你需要把业务的核心剥离得出来，抽象出多个可以支撑业务的关键支点。只有先搭建了一个好的戏台，人物角色才能够全面铺开。在你的脑海中想象一串葡萄的样子，你的业务流程图也应该是这样，一条主线若个支线无数节点。

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

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

故事板与原型

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

产品经理们的PRD文档会出现”写了没有人看“的尴尬，一个重要原因就是用户需求的描述方式。你写了很多也足够细致，但读文档的人却始终没有办法进入角色。过于技术化的描述让人昏昏欲睡没有思考的欲望，根本在于阅读者不能通过角色置换想象一个用户在干嘛，要干嘛，以及为什么。

随着业务复杂性的提升，”需求清单“会变成像裹脚布一样让人不愿意忍受。
根据用户的业务场景写成故事板，而不是列出一张”需求清单“。这么做的目的是为了保证团队能够理解、认同为什么要这个功能，以及用户是怎么做的，并引发团队的思考。

产品经理描述的功能需求（故事板），应该尽量用团队可以理解的业务语言来描述，而不是描述诸如字段，存储的技术语言。作为产品经理，必须把重心放在用户所能理解的问题上。你解决的是用户的问题，而不是程序猿们的问题。比如页面响应速度这个问题，产品经理可以描述为“启动页3秒后自动跳转到首页”，而忽略“响应速度”本身是个什么概念——原因在于你的用户并不能理解你的响应速度，而你应该像你的用户一样思考问题。

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

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

源文件下载：
链接：https://pan.baidu.com/s/1vwhqgwhlOkJOq8eDWu8mkg
提取码：0nqk

PRD之道：活用Axure快速撰写轻便的需求文档相关推荐

Axure电影购票服务产品需求文档+Axure体育球赛购票服务产品需求文档+Axure演唱会购票服务原型+在线购票系统+在线买票+在线选座+移动端票务系统+Axure电影购票服务prd文档
Axure原型作品介绍:Axure电影购票服务产品需求文档+Axure体育球赛购票服务产品需求文档+Axure演唱会购票服务原型+在线购票系统+在线买票+在线选座+移动端票务系统+Axure电影购票服 ...
产品需求文档（PRD）的撰写方法
产品需求文档(PRD)的撰写方法做好产品需求文档的这十步,是经过长期的实践经验和反复验证而得到的.可能这里描述的不是很全面,但他已经足够让你做一个成功的产品需求文档.做好这几步花费的时间要以项目的大 ...
Axure写PRD：倒推淘票票APP产品需求文档
Axure写PRD:倒推淘票票APP产品需求文档本篇文章从业务流程及交互逻辑这两个方面入手,对一款生活类手机软件--淘票票进行了分析. 写在前面的话:笔者作为一个有意向进入产品岗位的菜鸟,希望通过倒 ...
【收藏】需求文档（PRD）终极撰写指南
对每位产品经理都知道需求文档是最基础的基本功,但是要想写好需求文档还真不是一件简单的事情,那么本篇文章我就向大家来分享一下这么多年做产品经理以及带产品线新人得出的经验,要如何去写一份完整的需求文档. ...
产品需求文档、需求结构图、数据字典、全局说明、用例描述、需求描述、逻辑流程、原型设计、页面交互、登录注册、词汇表、数据统计、用户表设计、接口需求、功能清单、业务流程图、Axure原型、prd、文档实例
产品需求文档.需求结构图.数据字典.全局说明.用例描述.逻辑流程.原型设计.页面交互.登录注册.词汇表.数据统计.用户表设计.接口需求.功能清单.业务流程图.Axure原型.prd.产品需求文档实例 ...
商城前后端原型、商城prd文档、商城后台管理系统、商城app文档、电商需求文档、限时秒杀、电商平台、促销助力、拼团抽奖、电商文档、prd文档、电商前后端原型、电商原型、Axure电商系统、rp原型
商城前后端.商城prd文档.商城后台管理系统.商城app文档.电商需求文档.限时秒杀.电商平台.促销助力.拼团抽奖.电商文档.prd文档.电商前后端原型.电商原型.Axure电商系统.rp原型 Axu ...
prd移动端通用产品需求文档+Axure高保真app社交订餐通用prd文档+产品业务说明+PRD功能性需求+移动端公工通用模板说明+需求分析+竞品分析+产品结构图+产品业务流程图+产品信息图+餐饮系统
作品介绍:prd移动端通用产品需求文档+Axure高保真app社交餐饮通用prd文档+产品业务说明+通用prd文档+移动端公工通用模板++全局说明+需求分析+竞品分析+产品结构图+产品业务流程图+产品 ...
Axure版PRD产品需求文档
Axure版PRD产品需求文档(教程+下载) vigo梓贤原型设计 10 人赞同了该文章今天给教大家用axure做一个产品需求文档(PRD)模板,其中包括目录,版本修订记录,产品概述,功能说明,全 ...
Axure电商后台业务管理系统原型模板+app电商原型交互+移动端电商通用PRD文档+全局交互用例说明+Axure高保真电商社交prd文档+电商prd+电商需求文档+订单、购物车、配货、物流、仓储
作品介绍:Axure电商后台业务管理系统原型模板+app电商原型交互+移动端电商通用PRD文档+全局交互用例说明+Axure高保真电商社交prd文档+电商prd+电商需求文档+订单.购物车.配货.物流 ...
[转]产品需求文档(PRD)的写作
产品需求对产品研发而言非常重要,写不好需求,后面的一切工作流程与活动都会受到影响.转载一篇文章,关于产品需求文档写作方面的,如下: 本文摘自(一个挺棒的医学方面专家):http://www.cnblo ...

PRD之道：活用Axure快速撰写轻便的需求文档

PRD之道：活用Axure快速撰写轻便的需求文档相关推荐

最新文章

热门文章