PMCAFF
本文由作者 张集群 发布于社区
产品设计，绝不是简单的画原型、写文档，而是充满匠心精神去制造一个真正产生效用的产物，为企业产生价值并驱动运营形成良性循环，企业发展基于有效整合任意一环的力量，产品设计起到关键作用，如产品设计毫无可用性、易用性、体验性，没有在真实场景下解决业务痛点，那一步错将会引发步步错的蝴蝶效应。
进行产品设计时，应更清楚产品最终所承载的目的，所表现出的效用，为公司创造的价值，而不是为了做出一个系统而真的只是做出个系统，绝不是简单获取客户想要什么，然后整理一下，画个原型，或是由于各种因素，简化产品的办公成果。
必要的成果，客观情况下根本无法减少，现在欠下以后也会花费同样、甚至更高的成本弥补，而且将增加开发、测试人员的理解成本，降低效率，导致整体效率。
本系列文章详细描述了一款产品进行原型设计前，所需要完成的工作事项，包含需求调研阶段、需求分析阶段、需求管理阶段、沟通协调、信息架构设计等，基本贯穿产品思考工作的核心流程，且更规范的描述各个阶段所面临的重点，以及设计时核心思路，产品设计人员，可在各种场景下灵活应用。
本文将描述下列文章结构中，需求管理中的需求调研和需求分析。
需求管理
需求管理中涉及需求调研、分析、管理、确认及校验、变更、漏洞，贯穿需求的始终，掌握其原理，方能做到良好的承上启下，为前期的需求理解及设计，在广度深度，宏观微观，通过不同维度，更高效率理解，为后续的最终产物，原型设计、流程设计、文档编写，起到铺垫意义，此模块中思维应用居多，故，重心在于思考。
需求调研和需求分析，在进行时两个方法论有重叠，且相辅相成，没有固有的环节，可在实际场景中，灵活应用。
需求管理是无形的剑，需要把握使用时机及使用的方式，它的使用方式是需要思想的调控，此剑是克制浮躁，按照招式使用方能达到最大的效用最好的效果。 需求调研
此类需求调研方法，应用于对企业内部客户调研，非C端用户调研方法，但整体的理论知识仍可作为实践需求调研的基础。
1、了解项目背景及干系人
清晰项目目标及里程碑，方可明确每个阶段该做的事，避免浪费无需的成本。 明确项目中的全部干系人，产品是服务于用户，明确每个需求的对应干系人，更能为需求后续的可用性和准确性做铺垫。 需求调研过程中，确认探讨的需求是否是该干系人负责，如若不是，需找对的人去做决策，避免浪费时间成本，避免让需求出现偏误。
2、明确调研目的及范围
界定每次需要调研的需求范围，重点放在核心诉求中，降低时间成本的使用，提升整体需求获取的效率。 例如，准备沟通购物车需求，但谈到订单，虽然订单尤为重要，但此刻重点是闭环购物车需求，展开讨论之前需先将原有需求讨论彻底，项目是在时间维度中的产物，任何对时间不确定的使用都可能产生风险的引发。
3、调研前的准备
在调研前，为了提高效率，以及在客户前提高自身的专业性，可在必要情况下，提前对调研内容做准备，下图为例，是在做某二次元项目，对一些行业词汇及情况的了解：
如果是优化、重构现有系统功能，则需要使用现有系统，通过功能的场景、角色、任务、流程等维度了解业务。 如果已有的参照物，则拿出参照物进行沟通。 提前针对调研业务的相关知识及相关术语进行了解，通过政策去驱动自身分析、了解业务。
4、引导客户输出需求
进入到沟通阶段时，由于每位客户的专业水平，以及业务了解程度参差不齐，在表述需求时，可能存在疏漏点，或者不全面，或者有些客户觉得没必要去阐述，或者由于限制原因不能讲，如此很可能导致最终产物与真实需求不一致，导致返工。且在需求设计阶段也会存在疏漏，以及逻辑不能闭环，与开发、测试讲述时缺乏论证。
因此需要通过“结构化方式”引导客户说出相对闭环的流程，以及富有结构性的需求集合，而不是零散的每一个点。
结构化需求，顾名思义就是拥有清晰且层级分明的需求点，通过多个抽象的维度，来标准化需求的完整性，在沟通时带入下，如下图：
在沟通时，更侧重于引导客户说出业务痛点，对产品需求的真实效用进行校验。 在引导客户进行结构化输出时，也需要将流程捋顺，在结构化的基础上去抽象出流程。 需要在客户表述时，因时而动，而说出辅助用户输出的话，例如附和、补充、拓展等。
5、引导客户输出需求，并非面面俱到的确认
在调研需求与客户沟通时，无需事无巨细的与客户进行交谈以及询问意见，部分工作量小、常识型功能、辅助型功能均可通过自身专业理解去进行设计，这样会减少时间的分散，更加利用时间去沟通重要性需求。
即使最终设计所有偏颇，可在最终有产出物后，进行确认需求时，进行相关调整，且工作量基本不会太大，更加节省时间。
而且如果事无巨细的沟通，会给客户造成一种不专业的形象，即便我们产品设计人员出发点是好的，想准确无误的实现需求，但时间便是金钱，客户也有重要的事情要处理，小事情也无心从力，良好的利用时间对双方，对整体的项目进度均有好处。
6、校验理解的需求
由于每个人的认知不同，又或者思维出现偏差，在调研整理需求时，将会存在一定偏误，可能是由于以为与客户达成一致，或者自己没有确定而主观理解，导致偏误，故，在整理完每次调研的需求后，需富有结构性及流程性的，将客户所表述的需求，以标准化的形式复述一遍，作为需求调研的总校验。
7、产出物
经历过需求调研后，所需要产出客户的原始需求记录，作为抽象功能需求时的参照，具体模板，可参考下图，在实操时此步骤整理需要花费时间，需灵活应用，可跨过此步骤直接输出功能清单，无需整理此需求清单。
需求分析
不分析需求，直接让研发工程师进行技术实施，会严重缺乏需求的可执行性，大到容易出现各种异常疏漏，以及逻辑不能闭环，导致资源停滞，后期研发返工，需求不能完成客户真实意图；小到总是丢失需求细节，进度延迟等。
本节主要讲解，如何客观进行需求分析，并将需求演变成，规范性、可执行性、有价值的功能。
1、组织零散需求
此步骤需要将零散需求结构化，与需求调研中的结构化需求询问法一致，在于整理富有逻辑性和流程性需求，这是需求分析的基础，如果在需求调研时已经做好此步骤，则此步骤可略过，此步骤可以产出，也可以不产出输出物，主要更侧重于思考。
2、需求统一
每一个需求被客户所阐述时，因为各种数据、反馈、思考维度的不同，其表达的含义也不同，可能多个干系人同时阐述一个需求，但表述的需求均有偏差，此时可通过“需求预期”（需求预期在本模块第6），来考虑每个干系人的权重等情况进行分析，来平衡每个干系人的需求，并达成统一。
3、需求真伪分析
客户所表述的需求，由于错综复杂的原因，可能是由于私心、由于政策、由于未考虑清楚等原因，导致未表达出真正需求和真实目的，此时需要判断用户所表述的需求背后，是否隐藏了其他目的，而所谓的目的才是真正需要解决的需求。
分析的方法，可通过察言观色，又或者是通过分析需求与整体其他的需求，是否产生对比性，或客观判断需求不符合实际场景，去推测功能是否实现。
例1：用户想加一个删除清除日志功能，但实际业务中删除操作不允许，只能修改，因为需要排查哪些人员新增出错，并进行相应的处罚等，那么此类需求不允许实现。
例2：客户说，当会员存在行为A时，需要自动扣除积分，可经过分析发现，真实的业务场景中，会员进行为A时，客服需要打电话给会员，进行需要扣除积分的说明，即便用户不同意也要扣除，但是需要提前做到通知让用户知晓，不然后续会产生大量客诉，可能是因为客户新来办公，对原有业务不熟悉，又或是想减少与会员电话沟通工作量而提出此类需求。
4、判断更精准实现方式
由于客户可能更倾向于表述需求，而表述过程中夹杂着对功能的设计，此时应该判断需求最佳实现方式，包括基于效用、体验等。（但需要考虑具体所能动用的资源，来约束功能边界）
例如：用户在统计数据时，提出了各种数据的算法，而经过讨论发现，有些人需A的算法，有些人需要B的算法，有些人不在乎A不需要A，那此时如果将此功能做成算法明显不能适用于所有用户且缺少灵活性。
可直接做成用户可配置，可以针对各种指标进行随心组合计算，然后输出成自己想要的指标，此番操作也更能方便业务的拓展性，以及挖掘业务细节。
5、需求抽象合并
需要合并同类意义的需求。 并识别需求是否可以在已有功能中进行加工合并。 以及判断需求特性，判断是否有必要抽象合并成为拓展性高的功能，而无需新做一个功能，此步骤为了功能拓展性，减少不必要的工作量，以及零散的功能随处可见。
例如：用户需要对库存进行编辑，和锁定，而其实目的只是锁定，因为库存编辑只是减少，不会增多，库存的增多是通过系统同步的，那么此时其实只实现锁定功能，即可完成此需求，无需多做一个编辑。
例如：用户需要为不同渠道创建优惠券，并统计优惠券的领取使用占比，那么实现方法有两种。第一种针对A操作的埋点位置，来创建多个点击率统计事件，当有多个时也就要创建多个事件，这相当于一个Key对应一个Value值；
第二种是将A操作当做一个事件类型，为事件中增加增加多个统计维度，也就是说当A出现在新页面时，只要给A事件增加一个统计维度的值，而无需在新增多个事件，这就相当于一个ID对应多个Key Value，此番做法是 维护成本低，易理解，减少沟通成本，拓展性高。
6、需求预期
需要对需求的预期效果，进行明确的分析，以此也能确定各个需求中更侧重哪个，以此来确定资源的使用情况，以及可以通过预期反推需求的实现方式及特性，并判断权衡功能所产生的效用，以及投入的成本后，是否还有必要执行。
可通过以下维度进行判断：
7、需求影响
判断每个需求，是否对其他需求，会产生影响及弱化，会对用户造成困扰、感到不适、引起反感等，此类需求需要慎重考虑，是否实现，又或是改变实现思路。
例1：如果页面某区域增加过多图标按钮，导致经常产生误操作。
例2：如果功能A分流了功能B的大部分流量，且功能A产生的效用并没有功能B高，此时降低整体的收益，此时需要判断，是需要主推功能A，弱化功能B，又或是弱化功能A，维持功能B，这需要通过真实场景及企业战略去权衡分析。
8、输出功能清单
经过需求调研及需求分析，产品输出功能清单/流程图/功能架构图，此前，需求调研、需求分析、需求设计的工作是必不可少的环节，需求清单在于让客户快速预知系统后续所产生的整体功能框架，又或是直接输出原型及文档，不同场景下灵活应用即可，功能清单参照模板见下图：
至此讲完需求调研和需求分析部分，下期讲需求设计、需求管理等内容……
俞军：产品经理必备的2个模型 用户细分指南：6种模型与5类维度 产品方案：我的PRD撰写规范
点个“在看”吧
