作为从产品小白一路踩坑过来的产品经理，曾经面临的一个最大的挑战，就是如何写出一份“好”的产品需求文档，作为一个新手产品经理，确实会在这一步感到困惑，写出一份需求文档可以，但是写完使用的时候总是觉得不够完美，不够好，如何定义“好”呢，笔者认为写出来的文档需要能够满足以下几个条件：
1. 有主旨，文档写出来是要给同事看的，需要能让人快速明白这个需求是为了什么而做，为什么这么做。
2. 结构清晰，大家那么忙，不要写乱成一锅粥的文档给人家看。结构不限，但是要能有明显的区分，让人明白这块是说这个事儿的。
3. 细节完整，在有主旨和结构清晰的情况下，需求文档算是有了合理的框架，真正决定需求文档写的好不好的，正是文档中的细节，而这部分正是最能够区分出产品经理功力的部分，一个产品心思是否缜密、动不动设计、懂不懂用户心理、懂不懂技术，懂到什么程度、产品设计是否巧妙，甚至语言文字功底均能在此有所体现。
身边有几个中级，甚至是高级产品经理也写不出完善的产品需求，开发测试使用的时候发现缺东少西，不住地吐槽并且频繁找对方反复确认，给工作造成了诸多的不便。这也是笔者的写这篇文章的初衷，希望能够抛砖引玉，帮助大家写出一份“不错”的产品需求文档。
以下是产品研发周期内，每一步的设计框架及其需求文档中需要注意的点，藉此减少产品设计环节存在的问题和漏洞，保障产品上线成功和可靠。
需求调研
开始一个产品的第一步，就是需求调研，正是所谓的“万物之始”，关于需求调研的方法在后续的文章中单独探讨，但总体的思路就是“自上而下，自下而上”，有人会觉得困惑，这是什么鬼话，其含义就是先从宏观上，一个比较高的视野看需求，再逐层细化需求，最后也要从细化的需求回归到整体需求上，避免钻牛角尖，跑偏。一般而言，产品需求文档中不需要体现需求调研部分。
业务流程梳理
经过第一步的需求调研，业务的概貌应该是做到了心中有数，这一步则是将其系统化、可视化、规范化，抽丝剥茧，将庞杂的业务流程整理成一个系统实现上的最短路径，梳理完毕后将其可视化，绘制成为一个业务流程图，其中标明业务实体、角色等，让人能够清晰明了地了解业务是怎么开展的，有哪几个核心过程和步骤。这部分工作的最终输出一般是一个业务流程图，关联到需求文档中。
产品流程设计
产品流程设计即是将上一步的业务流程进一步抽象，适配到系统流程中，在这个过程中，需要考虑关联的系统，以及粗略的数据走向，能够确定一共有哪几个关联方，每个关联方输入什么、输出什么。这部分工作的输出一般也是流程图，在需求评审过程中，需要和关联方从定位、架构合理性等方面确认好整体的产品框架是否合理，存在争议则需要上升，由架构或资深人士进行拍板。
产品功能原型设计
产品功能原型设计软件一般使用的是Axure、墨刀、XD、sketch等，甚至有人使用windows自带的画图软件进行原型设计，工具不限，相比于工具，更重要的是人的思考。设计是一个方面、设计完成后输出也是一个方面，而很多人关注的是第一个方面，设计好了，自己想清楚了，但是没有输出，或者说输出了自己脑海中完美蓝图的一部分，对于需求文档的使用者而言，这份需求就是不完整的需求，别人没法完全了解的原型不是一份好的原型，那么一份好的原型需要具备哪些关键要素呢？
1. 页面间的跳转路径，除了正向的页面跳转规则，页面中还有存在其他的跳转，比如某操作提交成功后，页面跳往哪里，又如何跳回。页面存在登录校验，登录完成后跳回首页还是原来访问的页面，如此种种均需要仔细思忖。
2. 页面的各种状态，这点对于B端产品尤为显著，C端因为大多数页面都是独立的，单个页面的状态变动的场景较少，但是一旦出现，需要在原型中依次枚举，每种状态，页面中的元素是否有变动，有什么样的变动，均需罗列清楚，并且标明状态是什么，如何触发。
3. 原型中的标注文字，这点经常被人忽略，原型中恰到好处的标注文字可以让人更加顺畅的理解需求，以及可能隐含的需求。最好将自己的想法和注意要点标注在原型中。
4. 原型可交互，这点非必须，在很多的大厂里，因为时间原因，这点都没有做到，如果时间允许，原型中加入页面间以及页面上的交互，将带给研发同学更好的体验，以及沟通效率上的提升。
数据链路设计
产品的数据链路设计，就是从数据流向层面对产品进行梳理和设计，寻找到产品所需的数据和数据源，并且对数据情况进行调研，是否需要清洗，获得的数据的业务含义是什么，业务场景是什么，获取到数据后要做什么样的处理、怎么存储、甚至怎么将其做成服务，赋能给其他人等等，均是需要考虑的，这部分的工作，一般需要和开发的同学协同完成，因为具体实施的细节以及底层的逻辑，开发的同学更加熟悉，设计起来也更是得心应手，作为产品经理，这部分的工作虽然不用像开发那样懂，但也是要梳理的非常清楚。
只有这样，在后续的迭代、运维等工作过程中，才能不需要请开发翻代码查逻辑，很大地提高效率。
产品网络情况
产品的使用网络情况是很容易被设计者忽略的，在产品设计的时候，不仅仅是实现功能，还需要考虑产品的使用场景中的网络情况，是WiFi还是蜂窝网络、是内网还是外网、产品的某些功能对于网络时延要求是否很高等，都需要纳入考虑，如果在产品设计之初，就将此纳入考虑，那么后续因此造成返工或迭代的几率就非常低。比如支付宝在刷地铁的时候，如果地铁站的人非常多，超出或接近通讯基站的服务能力阈值，网络则会有较大时延，甚至短时间断网，这种情况下，支付宝刷地铁的功能如果还单纯依赖网络，实时请求，再回调，则会使得功能不可用，如果做成离线执行，异步数据同步的方案则会解决这一问题。
交互设计
交互设计的部分工作在产品原型设计的部分就已完成了一部分，在产品需求和UED的同学进行评审的时候，UED会对需求中的不合理或者交互体验有待提升的部分做一个整体的梳理或重设计，如果产品经理的功底很好，则这部分工作就变成了UED执行公司的交互设计规范检查的工作，统一且符合整体规范即可。
视觉设计
一个产品，人们最先看到的，最关注的就是这个产品长什么样，产品的UI设计风格、整体色调、给人情绪层面带来的直观感受都是视觉设计的功劳，在视觉设计的过程中，视觉设计师会与产品经理以及业务方进行反复地沟通，通过做情绪版的方式对于产品的设计框架定一个整体的基调，在此基础上再进行细节上的设计，以交付给前端精确到像素的完美设计，在此环节，也并非是视觉设计师一个人拍板，而是大家都参与其中，以输出一个完美的视觉稿。
产品安全设计（产品数据安全和业务风控）
产品安全设计是最容易被忽略的部分，如果没人提，这部分的工作可能永远都不会做，但是抱着对用户负责的态度，非常有必要补充和完善这部分的工作，从源头，就将信息安全纳入产品设计的方案中，产品安全设计一般包含以下两部分：
第一部分是产品中的数据安全，关键数据是否会通过某个接口泄露？是否可以通过穷举业务主键，获取到用户的敏感信息？是否可以通过虚构业务ID，套取用户信息？安全是个大的话题，咱们另外讨论，在此举一个例子，比如可以通过http://baiduo.com/9908332访问到一个用户的用户信息比如身份证、电话等信息，9908332是这个用户在该网站的用户ID，如果在访问的时候没有做用户ID和密码登录校验，那么完全可以通过暴力破解，也就是穷举的方式获取到此网站的所有用户的敏感信息。之前有很多小网站的用户信息泄露都是因为如此简单的一个原因造成。
第二部分是业务风控，也就是业务进行中的风控，比如黄牛、恶意下单等，这部分的工作在设计一个营销活动是更需要着重考虑，营销活动中往往会投入一些成本，以补贴或大折扣的方式来引流或者促成交易，但是黄牛和恶意下单等会使得这部分的成本白白浪费，无法达成预想的效果，那么如何识别过滤黄牛客户、恶意客户等对于业务开展存在重大影响的客户，则是需要通过产品设计中的一些手段进行实现，具体的方式包含但不限于接入实名信息、引入外部的风控数据，用户画像数据、根据自身业务制定异常交易识别规则等。
产品中的数据初始化
产品上线初期，系统中要正常运行可能需要一些初始化数据，例如权限、人员信息、组织信息等，在产品设计的时候，需要确定好方案以及执行的步骤等。
产品埋点
产品埋点是为了有数据能够查看产品的使用情况，看页面的PV、UV，看按钮的点击量、看页面停留的时长等，以此确定产品的使用情况如何，甚至能用埋点数据排查产品或业务中存在的问题，产品埋点是一个很大的话题，通常在埋点后还需要建立一系列的数据指标来监控产品的健康状况，产品埋点通常可以由粗到细，即在产品上线的初期，对于关键的功能或页面进行埋点监控，后续的版本中进行埋点数据的完善。埋点就是为了提供产品的数据，优先级低于产品本身的设计。在此也说明下笔者对于业务和数据哪个优先的观点，先有业务，再有数据，数据指导业务是锦上添花，数据不是无源之水。
产品异常场景处理方案（异常业务流程、系统异常、网络异常）
一份完整的产品需求文档，需要包含产品异常场景的处理方案的系统设计，所谓的异常分为以下三种：
1. 异常业务流程，在业务流程设计的时候，总是有一条主线，但是主线之外，非“正常”的操作也是有存在的可能，那么这种流程一旦出现该如何处置，走什么样的流程才能保证不卡死、不阻塞，这部分的工作需要和业务方一同完成，在能力范围内穷举各种可能，并且对每一种可能存在的情况，均确定一个处置方案。订单类，需要履约的产品尤其需要关注异常业务流程。切记，什么样的可能都会存在。
2. 系统异常，系统异常通常包含各个系统服务间的中断、错误、超时等，一般来讲，如果设计之初进行了详细和完善的设计，系统异常可以避免一部分，一旦出现，需要有合适的解决路径给用户选择，最次也需要提供一个较为妥当的文案以消除不好的影响，并且记录错误日志，以监控异常。在产品设计时，梳理系统的各个关联方，对于其存在异常后对本系统造成的影响均需要合理地评估。
3. 网络异常这种硬件层面的异常出现的概率较低，但是一旦出现就会造成大范围的，较大的影响，软件作为硬件服务的消费方，能做的微乎其微，但是也并不是啥也不能做，比如保存用户填写的表单到本地以应对提交时断网，网络异常时给一个完整、有说服力、又巧妙的文案等。
笔者的公众号是“长江93号”，公众号内回复产品学习，即可免费随机获取一本产品成长相关的电子书哟，欢迎小伙伴们和我一起沟通，一起成长呀~