这世界走的再快，也与你无关，一步一步成长，也挺好。
受公司学院的邀请，师父出山为广大同事做了一次含金量超高的分享。打从上周接到邀请，师父就开始紧张兮兮的准备这次分享，满脑子都是如何做分享（偷偷告诉你们，他都没心思工作了）。因为，这事情关乎他的面子，我想这世上可能没有什么比他的面子更重要的了。
他一直说“我满脑子的东西，怎么讲！” 最开始他打算把整个产品设计流程全部讲一遍，然后一个人在那里神经兮兮哔哔了一天。
我实在看不下去了，于是给他讲了一下我平时听得一些分享的情况。
我说：“大家都是已经入门的产品了，其实早在我还没做产品工作的时候就已经对流程滚瓜烂熟了，但是知道流程并没有什么卵用。我们需要的不是大的框架和虚的概念，不如你就抓住流程里面非常细小的点来讲实际工作中的应用”。
好在师父在懵逼的情况下听取了我的意见。于是就有了下面的分享内容，这里我将放出我师父的演讲稿，这比听分享和看分享后整理的文档更有参考意义（我在师父分享完之后是整理了一份分享文档给学院的）。
主题：如何写好一份prd（我将草稿只字不改，虽然有点乱，但是这样完全代表他思考逻辑的稿子可以看出他的思维逻辑多缜密，还有丝丝尴尬和搞笑）
1.
大家好，我是家庭网络产品线产品中心的产品经理**，在部门主要负责路由APP的产品工作，很高兴在这里和大家做这个分享会，由于我之前从事的行业比较多，根据之前一些产品经验，结合自身的特长，总结了一套自己产品设计的方法，用来跟大家分享，由于时间关系，我这里着重分享下我写需求文档的一些经验，希望能抛砖引玉，互相交流学习。也希望大家能在今后的过程中能总结出自己的一套更好的产品需求文档的编写方法。
我认为，一款产品的上线，产品经理需要负责其四个阶段：概念阶段，设计阶段，实施阶段和运营阶段。
概念阶段里我们需要提供产品的商业模式（即BRD）的内容以及产品的市场分析（即MRD），公司立项一般会需要提供这两个文档，特别是商业模式特别重要，斐讯0元购就是一个非常好的商业模式，往往一个好的商业模式基本决定了一个互联网产品的成败。而市场分析会对市场环境，竞品和商业对手，市场容量等等进行评估。
当商业和市场条件都满足以后，我们需要确定我们的业务流程，这里的业务流程是个广义的业务流程，意思是我们的核心交互是什么。比如商城的业务流程就是：查看商品-加入购物车-提交订单-支付-发货-收货-售后；而我们路由APP的核心业务流程就是：路由设置-路由管理-路由控制。一个大型的APP往往会有多条线的业务流程。
接下来我们就要开始做竞品分析了，一般会选择相关行业里的排名靠前的，或者是比较有自己特色的产品，比如路由器APP，我们就经常会拿小米，360，TP-LIANK，网件等等来做竞品分析，竞品分析的维度有：产品定位，功能列表，价格，市场销量，目标用户，版本迭代等等。
然后我们就开始做需求分析了，也就是我们会在很多书本上看到的那些：用户画像，用户场景，需求来源等等，我这里稍微提一下我自己做需求来源的几个点：
- 关注行业趋势和动向
- 根据友盟数据或者是市场数据提炼需求
- 用户痛点和痒点挖掘
- 用户反馈
- 竞品参考
- 自身优化。
由于时间关系，以上概念阶段的要素我就不详细展开讲了，这里只是顺带提一下，让大家有个了解。
2.
我今天要讲的主要是产品的设计阶段，从文档上来说就是PRD-产品需求文档。很多人认为PRD就是用WORD写写我们需要做什么就好，其实一份完整的PRD不仅仅需要写一份文档来说明你要做什么，而是包括多份文档内容，也就是广义上的PRD。我从文档上和流程上把它分成四部分：逻辑流程，思维导图，原型图，以及狭义的PRD输出文档。
3.
首先我们要理清楚产品大的逻辑流程，一般是用VISIO来做这方面的工作，就和画人像一样我们需要先确定其三庭五眼，这样我们的逻辑才不会走偏。
还是回到我们路由APP上来例举，由于路由产品的特殊性，我们一般需要用多方交互的泳道图来表现我们的产品逻辑，一个路由功能一般会牵涉到APP端，后台，设备端的多方交互。
这里举个简单的功能来作为例子，比如远程控制路由器上的指示灯，APP端做出打开的操作，操作命令发送到云服务器，云服务器收到指令后找到对应设备的MAC地址，然后发送到对应路由器上打开路由器指示灯，这就是一个简单的多方交互。我们需要用VISIO画出这个逻辑，让别人知道这个功能大概是什么样子。
除了多方交互逻辑，我们有时候也会用来设计业务逻辑，业务逻辑里有时候也会有多方出现的情况，比如B2C的产品就会牵涉到B端用户和C端用户的逻辑流，各端用户也会对应到其分别的前端和后台。逻辑流程的种类非常多，我这里就不一一例举了，分析一个锻炼自己熟悉逻辑流程的好办法，每天在应用市场下载一些推荐的APP下来，自己试着用VISIO画出它们的逻辑流程，同时也可以学习它们的功能设计方法，这样会让自己的产品设计能力进步的非常快。
4.
逻辑流程整理清楚以后，我们就可以根据大模块开始做思维导图，我一般会用XMIND来做这个，很多人会用思维导图来做业务逻辑，我一般喜欢用思维导图来做产品结构和逻辑判断。
一般来说做完这个，整个产品有些什么页面基本就都知道了。比如我的提纲，就是在写我要讲的东西的结构，不过APP的思维导图里会多一些逻辑判断在里面，举个例子，账号登录，密码输入正确怎么样，不正确会怎么样，各会显示或者是到那个页面，就是逻辑判断。如果大家有兴趣，会下可以找我具体看思维导图该怎么画。
5.
接下来就要画产品经理最熟悉的原型图了，我一般用AXURE来画原型图，经过上面的逻辑流程和产品结构以及逻辑判断的整理，实际上到原型图这一步，我们只需要把逻辑页面化而已。
实现我们要弄清楚整个产品的框架与层级，打个比方，一般的产品框架有：登录注册，首页，个人中心，设置等等，而层级关系则是登录页面下有：用户名输入，密码输入，已经相对应的判断页面等等。类似于这种，大家可以举一反三，这样一层层的去做，你就发现整个APP的框架就会搭建起来了。
然后我们需要设计好页面，页面上有什么元素，如何展现。这个我想大家都会画，不过画的好看不好看，清晰不清晰就另当别论了。这个大家要是有兴趣，平时我们可以私下探讨。
不过我个人认为原型图的页面一定要简洁清晰，不要加过多的设计元素在里面，除非你是要抢UI的饭碗。很多小伙伴都喜欢把原型图画的特复杂。接下来就是做交互跳转了，说到这里，肯定有很多小伙伴觉得，这不是UE的事情吗？其实UE负责的更多的是交互的用户体验，而里面的交互逻辑一般都需要产品来确认。而且，交互跳转做的好，你给别人讲你的设计的时候也会更轻松，思路也更清晰。
一般来说，做到这里原型图基本上已经完成了，不过我个人更喜欢在原型图上继续做标注，第一，是为了让UE或者程序员更清楚你的功能设计，其实也为你后面写需求文档做了标注提示。这里我一般会做两种标注，一种是逻辑说明，大的页面之间的关系或者跳转我会做逻辑说明的标注；一种是功能规则标注，一般标注在功能点或者是字段上面，对具体的功能点做说明。
6.
接下来就是狭义上的产品需求文档的编写了，实际上整个产品逻辑在这个阶段你应该已经一清二楚了。剩下的就是怎么把它表达出来，让别人知道，这个其实还蛮难的，导致了很多程序员都不爱看PRD。这里我还是呼吁一下各位程序员大哥，还是给产品一个机会，多看看PRD,谢谢。话题偏了，还是让我们回到需求文档上来吧！
7.
产品文档一般的格式我这里就不赘述了，我这里讲讲几个重要的点吧：首先是需求说明，很多产品会忽略这个东西，我这里的需求说明是要说清楚，我们为什么要做这个需求点。举个例子，之前路由APP是支持邮箱用户的，后来因为业务需要，需要取消邮箱用用户登录，所以我这样来写这个需求说明：
8.
考虑到以后要上线的，比如打赏，蓝汛游戏加速等牵涉到提现和充值的和金钱挂钩功能，必须有手机验证才能确保安全。其次，现在斐讯所有平台只能用手机注册，不会再产生邮箱用户，如果继续支持邮箱用户则后期开发需要为这些用户做多余的适配工作，所以需要禁用邮箱用户，强制用户绑定手机。
9.
这样大家就清楚知道你为什么要做这个需求了，这个对刚刚走上产品岗位的产品经理还是特别重要的，你如何说服你的领导，或者是其他人，让他们觉得你做这个需求是有意义的。有时候我们也需要对某个功能写上需求预期，也就是说我这个需求需要达成什么样的数据指标，这样就可以对照后面的数据分析做个对比了。
10.
接下来要写的就是功能描述了，新入职场的产品经理往往会把这块写的特别重，基本上会占到整个PRD的八成内容，其实我要说的是，你可以把这块叙述得更清晰明确，只用说明你这个需求有哪些功能模块，模块之间功能流程是什么样，用户是如何操作的。
这里很多人会有另外的写法，喜欢把规则插进去写，我个人不是很喜欢这样做，功能说明就直接描述功能是什么，会让别人更清晰的了解整个功能操作，而规则可以写在下面另外的模块里，我一般叫他约束性描述，或者功能规则。这一块在产品文档里特别重要，一般的产品所说的有“坑”，问题就是出在这里。
11.
那我们如何来避免这种“坑”的情况发生呢？
我从两个方面来讲这个，第一个就是产品规则里需要有哪些要素，第二个就是如何自检自己的文档里有没有纰漏；
首先产品规则里需要有：约束性描述-即这个东西只能怎么样，功能规则-这个功能该执行什么逻辑，这两个东西，基本上都会有，下面的有些东西可能只会有些特定的需求才会有，不过也是特别重要的。
比如数据来源，我这里的显示的东西调用的是那张表或者是哪个接口；
储存方式，我这个规则是缓存在本地还是保存到服务器上；
异常情况，如果发现异常或者错误，这个逻辑该怎么走；
极值，如果在这里出现了999条记录我该如何处理；
操作提示，用户使用这个功能不知道是啥，我改怎么提示用户或者是用户做了什么操作，我该告诉用户什么；
防呆规则，这里的输入框是不是只能输入数字或者输入多少个数字；显示内容及其格式，某块地方是显示的什么东西，或者是可能显示什么，显示的是图片还是视频还是文字或者支持的是什么格式。
前后台逻辑关系，前端操作会对后台产生什么影响，后台的设置会让前端显示什么；
前置条件和后置条件,发生这个用例的前提条件，或者满足什么条件才能触发这个用例，发生这个用例之后的结果，会产生什么影响等等。
当然，你的产品规则可能远远不止以上那些，只要是你觉得有必要特别说明的东西，都可以算作你的产品逻辑，同样的要求就是，一定要完整，明确并且清晰，不要留“坑”。
12.
那当我写完产品规则以后，我该如何自检自己的PRD呢？我这里也总结了一些我的经验用来自检。主要分三个角度：1产品角度，2运营角度，3，风险评估；
13.
从产品角度，我们需要注意以下的要素：
- 流程是否形成有效的闭环（什么叫闭环，就是功能走着走着不能走不通了）；
- 文案是否易懂，是否存在歧义（你的提示或者描述是否表达清晰，无文法错误，你的slogan是否有情怀，吸引人）；
- 版本兼容问题（如固件/第三方插件/第三方接口/APP各版本之前是否有冲突，功能之间或者交互之间做了好兼容）；
- 与其他系统(后台系统/服务器)的调用是否能相互兼容跑通（这里一般是牵涉多方平台的处理方案）；
- 新功能是否存在其他关联功能点冲突（做一个新功能的时候一定要考虑到和其他有关联功能的相互影响）；
- 业务高峰的系统降级处理逻辑（如果你做的是以为重度业务APP，一定要考虑很多用户同时涌入的风险以及处理方案，比如某米的商品抢购）；
- 后续新功能或关联产品如果下线的影响点（当你要下架某个功能的时候，要考虑到下架以后的风险和对其他功能会产生什么影响，要写功能下架预案）；
14.
从运营角度，我们需要注意以下的要素：
- 是否存在数据报表、埋点需求；
- 是否存在客服查询需求；新功能的客户宣传策略；
- 是否存在运营需求；数据指标和预期验证；
- 运营需求和产品功能是否相互影响；
15.
从风险评估角度，我们需要注意以下的要素：
- 是否会因为功能设计而导致平台审核不通过（特别是苹果）；
- 是否引发诸如骚扰、欺诈等安全隐患；
- 是否存在用户资料泄露，财产，数据泄露安全隐患；
- 是否存在负面舆情风险；
- 是否存在法律及合规风险；
- 发布审核风险；版本撤回及异常评估（回滚策略）；
所以我们经常会设计一些条例或者是用户须知来防范这些风险。
如果时间充足，接下来我会将产品的实施阶段和运营阶段产品需要做些什么。
啧啧啧，半个小时的分享时间，写了这么多还怕说不够。最搞笑的是，他最后说了句大家有需要的可以随时可以来找他。我跟他说考虑清楚要不要这么说，他说就客套一下啦，没人会当真的。于是第二天有人来找他，有人加他微信。
严肃点说，这次分享真的是干货满满，只有非常认真仔细的阅读，理解和实践，才能转化成自己的能力。跟了师父快半年了，学了这么久的我仍在反复练习，你是否也应该放下所谓的“***天成为优秀的产品经理”，而是踏踏实实的练习呢。
这世界走的再快，也与你无关，一步一步成长，也挺好。
作者：Jelly妮
来源：https://www.jianshu.com/p/e61f7eb59b94
本文由 @Jelly妮 授权发布于人人都是产品经理。未经作者许可，禁止转载。
题图来自unsplash，基于CC0协议
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
