方法论产品经理如何更加高效高质量输出需求

　　18年，在做年度复盘时，回顾了自己过去一年的产品工作，发现了几个共性的问题，其中有一个就是：需求场景考虑不全面，开发过程中还会有需求变更。很不巧，开发GG们最讨厌的就是需求频繁变更。作为一个有强烈求生欲的产品，这个问题真的不容轻视啊因此不禁问自己：你真的会写需求吗？换一种问法就是：产品经理，如何更加高效高质量输出需求？
　　前言：阅读须知
　　在开始进入正文之前，先对内容做一些概要说明，若未能满足你的阅读需求，可自行绕过，避免造成不必要的时间浪费，引起身心不适哈哈
　　（1）适用人群
　　作为一个2年级产品新生，认知边界肯定有一些局限性，建议阅读人群为：12年的产品经理。产品前辈们可随意，当然欢迎提出宝贵的批判意见。
　　（2）解题思路
　　针对自己存在的这个问题，进行现状、成因的深入思考，以更好地对症下药，提出一些粗浅的解决办法。
　　（3）内容说明
　　写该文章的初衷，主要是为了给自己一个答案，在解决写需求中的问题做一些沉淀，分享出来是希望志同之士一起探讨成长。文章涉及面较为广泛，因篇幅和个人时间有限，仅做框架梳理，不做深入展开，内容概要见下图：
　　1。现状
　　这一部分解答是什么。还是围绕目标：高效、高质量输出需求。那么不高效、不高质量的需求是什么样子的？
　　1。1写需求不高效
　　不高效比较好理解，很容易想到一点就是：憋半天没写出几句话哈哈。通过长时间的暗中观察哈哈，身边厉害的产品经理，写需求基本都是信手拈来的。
　　为啥能这么快？
　　得到的回答是：都是套路！在这里，我们不妨拆解下，你就可以发现，可用套路的一些蛛丝马迹。从写需求整体用时来看：包括了需求调研时间长和需求编写时间长。
　　（1）需求调研时间
　　完整的需求调研应该包括：业务诉求调研、竞品调研、系统实现调研。
　　业务诉求调研
　　需求的来源方很多，比如老板、用户、业务部门，业务调研是为了深入了解业务的诉求，以便更好实现业务目标。比如做电商的，业务目标可以为GMV。
　　竞品调研
　　是基于产品目标、满足客群去锁定直接竞争对手、潜在竞争对手，然后开展具体的产品调研，可包括：产品功能调研、产品迭代方向、盈利模式等，这部分调研可大可小，视具体需求而定。
　　系统调研
　　对系统现有能力的了解，接口字段有哪些、前中后台的数据如何传输、储存怎么样？产品需要关注的原因是：写出的需求能更好地落地，不过不是重点。这部分一般看产品所处阶段，从0到1，可能看得不多。后续迭代优化的，需要多看看。
　　（2）需求编写时间
　　为啥别人写一个需求，蹭蹭蹭三五下就完成了，而你还在吭哧吭哧写半天？其实，前面的需求调研很关键。要是写需求也有二八法则的话，需求编写占20。需求编写用时可以包括如下3个部分：
　　需求方案设计
　　用什么样的方案满足用户的需求，以保证业务目标的达成？这个偏向战略层和范围层，比如：抖音：记录美好生活，其实通过短视频解决用户碎片时间消磨问题（仅代表个人见解）。
　　需求流程设计
　　完成一个闭环任务，需要用户走进什么样的流程？比如患者去医院的看病流程：挂号候诊问医生出诊断结果缴费取药。
　　线框图绘制
　　前端页面交互部分的绘制，这很好理解了。
　　1。2需求质量不高
　　这个部分，可能相关同学最直观感受就是：需求根本没法看啊：义正言辞、慷慨激昂、长篇大论，却不知所云！需求写得好不好，产品经理应该具备一个敏锐的意识就是：当开发经常来找你了解需求，这个时候，你该反思自己需求编写问题了。
　　个人理解：需求质量高不高，可以分为以下两个部分：场景缺失及文档可读性差，对于是否更好满足用户需求，这里不讨论。
　　（1）场景缺失
　　这个部分可以看出一个产品的内功是否深厚了。我理解这里的场景包括：业务场景和系统场景。
　　业务场景缺失
　　产品功能经常考虑不完整，导致后面变更需求。比如说：漏了一个未登录用户的展示状态；比如说，漏了用户优惠券过期之后，前端界面的引导
　　系统场景缺失
　　有些系统实现场景考虑不完全，也是开发经常找的一些点。缺失范围可能为：系统页面交互、数据交互、判断逻辑、异常处理。
　　（2）文档可读性差
　　正如章节所说的，一些常见的现象是：文字太多、逻辑太乱、语义表述不清、没有区分人群针对性得编写。
　　2。成因
　　这个部分，解答为什么。其实上面的问题列清楚之后，再进一步思考，很容易知道为什么造成这样。写需求基本可以有三大组成部分：搞懂问题、找到合适的解决办法、将办法写出来。
　　因此下面的点可能是导致问题出现的原因：
　　2。1搞不清楚问题的本质
　　其实搞懂一个问题的本质，谈何容易，因为这个跟每个人的教育程度、社会阅历、认知水平密切相关，这都是硬伤，除了提升认知水平，真的没有根本的解决办法。不过为啥还值得拿出来一说呢？因为这些套路，可以降低你去快速一个问题的费力度。
　　所以，在短时间内搞不清楚，其实是缺乏有效的调研办法，对于这个问题，曾经做过一些思考、整理，一会说。（网上其实也一大把，关键你自己去不去找，找到后适不适用）
　　2。2找不到合适的解决办法
　　了解了问题之后，还需要知道怎么做，否则也只能说纸上谈兵。在这里造成问题的细分原因如下：
　　（1）无清晰的目标
　　写需求的时候，目标不明确，要解决用户的核心痛点是啥，价值主张不清晰，将无从下手。如果这个目标（大饼）没画好，大家伙为啥给你做需求呢？。往大里说：比如阿里巴巴，让天下没有难做的生意。往小里说：这个页面需要提升用户的点击购买率。
　　（2）无明确的优先级
　　想做的太多，很容易决策困难，眉毛胡子一把抓是很容易犯错的。因此市场反馈未知、资源有限情况下，快速迭代试错的敏捷开发流，是一个很好的指导思想。从0到1，考虑mvp。从1到100，考虑当下产品阶段、业务目标最需要解决的问题。
　　（3）无合适的载体
　　知道目标及优先级之后，困扰产品经理的可能还有：满足用户需求的介质选定。微信公众号、小程序、还是app？这个决策也是依赖于对用户、业务的深入思考。
　　2。3场景缺失原因
　　这个问题导致的原因很简单：就是对业务、用户、系统的不了解以及经验不足导致的。
　　2。4文档可读性差原因
　　主要分两个点：没有区分阅读人群和信息呈现形式差。
　　（1）没有区分阅读人群
　　产品经理的PRD，将会给到前端开发、后端开发、测试、设计师几类同学阅读。文档本身也是一个产品，每一方的需求点都是不同的，如果没有差异化满足他们，可读性当然就不会好到哪里去。
　　（2）信息呈现形式差
　　为啥需求文档是一些规范的框架，其实是有意识地提升单位行间距输出的观点密度。框架内的内容就得靠产品经理陈述了，基本上是产品经理组织信息并且表达出来的能力不足导致的。
　　3。解决办法
　　前面的废话说了很多哈，承蒙不弃，能看到这里。其实主要是为了帮助大家更好理解办法是怎么给出来的。来点实际套路吧：
　　写需求前：
　　3。1项目调研思路
　　下面展开又是一篇文章：
　　3。2选定解决办法
　　找解决办法的思路，其实在前面阐述问题原因的时候，已经说过了，适用才是王道。这里可以参考用户体验五要素里面的几个维度去思考。
　　战略层：确定为什么做
　　范围层：确定做什么
　　结构层：确定整体的业务流程
　　框架层：确定交互原型图
　　表现层：视觉的呈现，UI
　　（可能描述得不准确，求轻怕）
　　写需求时：
　　（1）场景缺失问题
　　1）业务场景层
　　首先的要了解用户的痛点及人群（通过调研）、产品的目标。这样在产品设计的时候，更容易去拆分场景去设计功产品功能。可以拆解为：
　　同一个用户在不同的场景下面，有时间维度、地域维度、登录状态维度等，举个例子：读书app，需要满足用户在白天和晚上的阅读需求；
　　不同用户群体在同一个场景，在从会员等级、客群区分、任务状态上，产品如何满足群体个性化需求，等等找个时间可以归归类。
　　2）系统场景层面
　　注意考虑如下几个方面：
　　（2）信息表达形式
　　1）整体思路就是
　　在信息内容传递上，视频图片文字。
　　2）需求规范
　　有侧重描述：前后端、测试和设计关注重点，对于设计同学，可单建一个文档说明。
　　背景（痛点）、需求实现、需求价值文字
　　需求管理表格
　　需求范围表格
　　需求流程VISO图
　　页面交互及逻辑Axure或者墨刀，线框图
　　3）需求类型及表达式
　　数据类：报表需求、埋点需求，侧重表字段来源、加工逻辑及更新逻辑；
　　后端类：侧重字段定义、判断逻辑；
　　前端类：侧重交互逻辑、展示逻辑。
　　好了，以上都是一本正经地胡说八道，希望对大家有帮助！