我感觉我今天可能要写一份伪分享，为什么呢？因为自己对于自己产品文档的高标准和高要求，可能自己和我自己的团队都没有达到，也是在不断的鞭策的过程中。什么样的产品文档是高质量的产品文档，我们应该如何做，如何思考，才能输出一份高质量的产品文档呢？今天我们就来讨论一下。
好的产品文档，一定能够完整的呈现产品经理的思路，能够看到产品经理从项目最初阶段（或者刚刚开始接触一个产品的时候）到发展到现在的思考历程，能够看到产品经理对项目的理解，对产品的定位，对用户需求的思考，对解决方案的敬畏之心……那么我们先从产品经理说起，在面对一个产品，一个项目的时候，我们要了解哪些东西，从何入手呢？
一、了解公司的业务情况、愿景、规划。
这虽然是不一定体现在你产品文档或者原型里的内容，但是却会对你的产品思路产生非常大的影响。最重要的是，它影响了你产品扩展性的边界。
举个例子，前段时间红红火火的现金贷行业，很多公司靠单纯的项目复制去盈利，一个公司可能有十几二十几款APP在线上运作，然后，公司提出（或者你作为产品经理自己提出）要做中心服务化，多个项目独立维护实在成本太高了。你作为后台产品经理，要设计服务化的后台，你的思路应该是什么？这个时候你可能就要了解到公司的战略，比如公司还有很多条业务线，未来很多条业务线要接不同的商家，那么你只做一个现金贷业务的服务化，是不足以支撑公司未来业务的发展的，所以除此之外你可能还需要一个中台产品来做支撑，做平台化。这个时候你就心里大概清楚现金贷业务服务化的边界在哪里，他与中台产品平台化的连接又是什么。
其实了解公司的战略愿景和规划，对于职业发展也非常的重要，我面试过一个产品经理，他在了解了公司的整个业务体系之后，非常深入的一个问题就是公司最大的愿景是什么？公司上层对这个项目的支持力度如何？公司对这个项目是否有足够完整和清晰的规划？这都决定了他是否来我们公司，未来的职业发展会不会在这里浪费几年的时光。我很欣赏这位产品经理。
二、了解该项目在公司的内部定位。
这对于你写一份好文档的最大帮助就是：明确需求的边界，资源充分利用。
比如现在的现金贷行业，政策下达之后，大家都在纷纷转型，金融场景变得非常重要，成为了合规的标志。由于趣店利润和一些恶性新闻事件的爆发，社会普遍对现金贷嗤之以鼻，认为是吸血的行业，害人的勾当，很多现金贷公司开始进入消费分期业务。那么分期商城在本公司的定位应该是怎样的呢？是一个假场景，还是一个真的要做好的电商？你的设计应该面面俱到吗？应该添加购物车、退款退货、纠纷处理等功能实现线上闭环吗？你可以推动运营资源去做商城的电商业务吗？这些问题留作慢慢思考的问题吧。
明确需求的边界，对产品多一份敬畏之心，绝对不应该是“我想怎样做”，而应该是“在公司这样的背景下，我应该怎样做，从而解决了这样那样的问题”。每一个产品经理，都应该从解决方案开始。
三、熟悉该项目所在行业的普遍业务流程和通用做法。
不论是新接触一个项目还是新加入一个公司，都要先了解这项业务的行业普遍做法，这样对于你写一份文档的最大好处是：提高效率，不需要重新发明轮子。假如要设计一个分期购物的下单-支付流程，你就需要知道，在普遍的分期购物中，是否有购物车存在，收银台是如何设计的，大家都采用哪些方式进行支付，分期的额度是如何给出的等等，熟悉了这些，初步的设计模型已经在你的脑海中了。不过，还有一点是很重要的，我见过很多的产品、UI，在描述为什么这样设计时，说的最多的一句话就是“XXX就是这样做的”，这里的XXX一般都是腾讯、阿里等大厂。熟悉行业通用做法，并不是给你一个不需要思考的产品设计，为什么要做这样的设计思路，应该和自己的产品相结合。一个开发曾经跟我说，如果什么都靠抄一抄就能做，那任何人都可以，为什么还需要产品经理？
所以，在去开始一个新需求的设计之前，对同行业的竞品进行全面分析和体验是非常必要的。按照竞品或同类产品的流程输出思维导图，覆盖多种业务场景，分析优劣势，择优参考非常重要。这也是为什么一个产品经理要尽可能多的去体验产品的缘故之一。
四、详细了解主业务流程的关键结果、状态等，常念“生命周期”原理。
我在我们部门中实行的方案就是，产品需求经过多次内部评审，第一次先评审思维导图，思维导图会占用产品设计40%的时间，需要包含多种异常，多种业务状态下的逻辑操作。等思维导图评审过了，再去进行原型图设计，当然了，这个过程会持续的时间比较长，这就需要产品经理在对整个项目节奏的把控上有非常大的时间空间。我们是规定提前两周开始进行需求设计的。
那么再引用我原有的文章来表述一下我所说的生命周期理论是什么。
上学时，学经济或者贸易的同学多少都会了解，产品和市场生命周期曲线。今天我们要说的是业务状态和生命周期。熟悉自己业务的多种结果、状态，并常念“生命周期”规律，对于产品文档的好处就是：严谨的交互逻辑和业务闭环。举个例子，电商的同学肯定非常清楚，普通的电商下单购买中，订单的生命周期有：待付款，付款中，付款失败，取消中，已取消，待发货，待确认收货，已确认收货，资金处理中等等，还未包含退款的多种状态。那么熟悉订单的整个生命周期，你在做产品设计的时候，就可以知道每个状态下相关的操作以及字段展示，相应的交互和体验，涉及到的业务流程等等。一环扣一环的，业务就严谨了。
五、熟练掌握5W1H原则。
这里引用我原有文章的内容。
什么是5W1H原则？其实上学的时候都学过，那就是WHY,WHO,WHAT,WHEN,WHERE,HOW：为什么，谁，在什么时候，在哪里，做什么，怎么做。5W1H原则需要与“生命周期”原则相结合，能够更加严谨的实现你的业务逻辑。举个例子，假如某天运营同学跑过来跟你说，产品狗，我要做砍价的功能。你一看需求，毛也没有呀！运营同学描述说：老用户邀请新用户参与砍价，砍价者必须是新用户，砍完后可以参与砍价，也可以邀请好友帮忙砍价。我需要设置砍价的规律以及底价。OK，动手吧，5W1H原则：
要做什么？砍价，砍价的本质是团购。为什么砍价，砍价的目的是什么？拉新，好了，目的清楚了，主页面主功能大致清晰了；谁砍价？老用户发起，新用户砍价，那么新老用户的不通状态下的不同页面以及不同操作，就在你的脑海里了；什么时候砍？活动期间，ok你需要一个活动期限，那么未开始，已开始，已结束的状态就在你的脑海里了；在哪里砍价？产品详情页，分享出去的页面，那么主邀请方和被邀请者的页面，结合第四条不同的状态，页面也在你的脑海里了；怎么砍？点一下砍一下，限定砍价次数吗？砍完了做什么？邀请，邀请去哪里？那么砍价活动交互也出来了。5W1H原则在工作中非常有用，假如你要接一个需求，一定要明确其中的5W1H，才能自己想清楚，也让对方想清楚，到底要不要做，为什么做，怎么做，不至于把自己陷入非常被动的环境中。产品经理绝对不是一个被动接受需求的人，而是产品的主导者。
六、先出框架，再出细节。
其实当你的思维导图评审过了，你的脑海里就有一个非常非常清晰的产品框架了。
先搭框架，再出细则，这是每个人都会说的一句话，但是做起来可不是那么简单的。先搭框架再出细则对于产品文档的好处就是：效率，效率，效率。重要的事情说三遍。效率对于互联网行业的意义不言而喻。如何搭出框架呢？画一个框，写出这是干什么的页面，涉及到什么字段，主要按钮是什么，点击了之后去哪里，这个页面分几种状态，每种状态的操作是什么（这里列个表格就可以，不需要全部画出来），对于开发的难点在哪里。这时候如果是紧急项目，其实就可以和开发评审关键点了，开发难点抛出来，大家讨论一番，评审完毕补出细则。
以上都是方法论，是意识，需要理解和培养。下面第七点是实践举例。
七、产品文档应站在观看者的角度思考呈现方式。
其实这就是产品经理思维的体现，你的产品文档也是个产品，他的阅读者包括开发、业务方、测试和以后的继承者。那么如何让这些人都看得懂呢？也就是你必须能够描述从这个项目从始至终所有的信息；能够让所有人从大框架到细节点，都能具备项目整体认知和功能点需求认知；同时理解当时当下这样做的目的。
产品经理管理自己的产品文档，应该具备以下特性：
1、整体完整性。公司如果是多业务线，那一定有一个产品总监或者主管负责全部业务线。每条业务线，一定有一个负责该业务线的主产品经理，并配备多个分模块产品经理。主产品经理一定要有整体需求完整性意识。我们的做法是每个产品经理维护主业务线的全部更新记录，记录主负责PD，记录版本更新功能点。
下图的左侧树状结构是公司全部业务线的产品目录，每个产品线下的每次需求都可找到。可以看到前期我们的需求命名方式不规范，后期新的需求都按照规范编写了需求编码和需求名称。
右侧是【流量池产品】业务线的版本更新和迭代记录。对于后续新加入者来说，对于了解需求历史，很有帮助。
2、需求可追溯性。在维护版本迭代和更新记录时，附上需求链接，即使功能点概述不全面，也能在需求详细原型看到每次更新迭代的内容。（也就是上图的右侧表格）
产品经理在呈现产品需求的时候，必备以下内容：
1、需求概述。需求版本记录，需求版本背景，需求当下目的，当下需求期望排期。
其他当时当下需要的重要信息，如：三方资料，接口文档，参考文件等。
下图是需求概述的相关描述内容。
2、原型文档
首先，原型文档应该是自己负责的模块，整个模块的每次迭代画在一个文档里，除非已经完全放不下了。
其次，因为每次都更新这个文档，就需要记录每次更新和新增的内容。
再次，是全局的复杂概念、配置化先后关系描述和举例。这个尤其对于后台产品经理尤为重要，后台多是逻辑关系，如果没有从大方向到小细节的关系认知，只看线框图是非常难以理解透彻的。图文并茂先讲解全局复杂概念和逻辑，如果有配置的先后关系也要描述，那么所有人都清楚了。
下图是左侧是原型图的整体树状结构目录，第一页一定是版本记录，右侧是版本更新描述，方便开发查阅。
下图是全局概念定义和流程图的举例，能够图文并茂的先让阅读者从概念性对逻辑有个先入理解。
最后，应该是：功能结构图，页面流程图（页面框架图），泳道图（主业务逻辑流程图），功能列表（功能类，功能点，功能点优先级），页面线框图，字段逻辑解释等（注释）。
记得，输出的东西越全面，思考的越多，遗漏的就越少，逻辑就越清晰严谨。
当然，产品文档包含的内容，并不一定每次都全面，但是总是要有个优先级，哪个要先画出来以帮助思考，自己根据项目不同来确定。
以上，如果都做到，必然要花费非常多的时间。所以，这就需要自己在平时日积月累的过程中，甚至是在工作间隙和领导交流的过程中，抓重点信息，做关键推断，以了解项目背景，公司愿景和规划等等。平时多思考业务逻辑，多了解行业，对市场和业务变化敏感，不等需求方出需求，产品功能就已经包含了可能发生的异常情况，这就是高手。产品设计时常总结，有自己的方法论，让自己的原型在详尽的同时保持高效，这也是高手。
以上7点的顺序是不能变的，他们一环扣一环，承载着思考的边界，从规划到定位到资源再到落地方法，是一个思路，也是一个成长的过程。
