构建一套有价值的标签体系，光掌握基础理论是完全不够的，在实践过程中我们会遇到各种各样的”坑”，本系列，道明将手把手教你如何实操构建标签体系，提供一些实用技巧帮你“避坑”，最终生产出真正能让业务方用起来且有价值产出的标签。
案例
首先我们先看一个案例，相信很多新手都遇到过同样的情景：
为了进行用户精细化运营，小王所在的创业公司领导决定开始搭建用户画像系统，这个重担落在了数据产品经理小王身上。
小王发现，市面上，关于从0到1搭建用户画像平台构建标签体系的文章很多，从未接触过画像工作的小王同学认真学习一番后，很快掌握了基本的画像知识，如标签分类原则、标签应用场景等，已经开始跃跃欲试。
经过短短2天的时间，小王就构建了一套“大而全”的标签体系，并制成了一张树状脑图，其中涉及标签个数达200多个。
成就感满满的他，马上邀请领导进行需求内部第一次评审。没想到领导看到屏幕一张巨大的脑图，马上给他浇了一盆冷水，并提出了以下3个灵魂拷问，让小王一脸懵逼：
- 这些标签生产出来后，能够给业务带来什么价值？
- 构建这些标签的基本原则和判断标准是什么？
- 当前研发资源非常有限，短期内是否能够快速上线支撑业务？
可能不仅仅是新人，很多老手在标签体系迭代过程中新增用户标签时，也会接收到来自领导、数仓研发、业务同学的拷问。废话不多说，接下来我们来学习下实操流程之需求分析环节具体流程。
1、 明确标签生产目标
明确目标非常重要，因为在收集需求过程中，我们会收集到来自不同部门、不同角色的需求，可能几十个可能上百个。但是作为产品经理，我们知道绝大多数时候研发资源非常紧张，这就要求我们在有限时间内，投入有限资源做更有价值的事情。
这里目标分为企业战略目标、部门的考核目标、核心业务方的业务目标等，需要我们具体分析。比如当企业或者产品处在不同生命周期，对用户标签的诉求是不同的，如本季度公司战略目标是新用户同比上一个Q增长30%，那我们可以优先考虑生产和实现有利于拉新的标签。
当需求有明确的业务方，我们可以直接和需求方进入讨论阶段。如果公司高层或者自身部门提出，那我们可以基于目标，定位到和目标一致的业务方进一步讨论。
2、 挖掘和分析业务方的标签需求
在这个环节，我们要细致分析需求方的业务背景、业务流程、用户使用流程、各角色痛点等关键信息，充分和业务方沟通探讨，避免生成出“拍脑袋”的标签。这里有两点方面需要注意：
1.发起正式沟通会议前，提前做好功课，了解清楚业务方背景，保证正式沟通时，双方的信息基本保持一致。
具体包括私下先请对接人串讲业务情况、搜集业务方的现有介绍物料、亲身试用体验他们的产品和服务等。
2.提前准备沟通信息模板：
可以准备一个简单的Excel模板，列头包括标签名称、标签规则、使用场景等，开会时大家往表格里填充对应内容即可。
既可以避免遗漏需求，又可以让大家聚焦到核心内容，帮助我们高效进行会议。
如果条件允许，甚至可以提前发给业务方，让他们初步填充一版。
要注意的是，标签规则，业务方未必想得合理全面，需求收集阶段简单描述即可，后续需要数据产品经理仔细斟酌（该系列下一篇文章会讲到）。
（标签需求收集模板）
3、 明确标签上线后的使用计划和效果追踪
经过几轮和业务方沟通，可能我们会发现，业务方的需求可能多大十几个甚至上百个，但是我们的资源确实有限，在这里教大家一个屡试不爽的小技巧：结合“优先级工作法”和“减法思维“，与需求方明确需求上线后标签的具体使用计划，从而确定优先实现哪些，哪些暂缓实现或者不予实现。
生成xxx标签后，运营人员将圈选xxx标签用户，以xxx时间周期，进行xxx运营动作，预期达到xxx目标效果。（如新用户下单率提升10%）；
如生成出“近7天新增用户”和“用户活跃度”标签后，运营人员将每周一圈选出近7天新注册用户且活跃度较低的用户，进行优惠券短信下单，将新用户下单率较上月提升10%。
很多时候，对于经验不是特别丰富的业务方来说，他们什么都想做，觉得所有或者绝大多数需求优先级都很高，这个时候可以依据情况，使用上述技巧进行沟通拒绝不合理需求。
本文我们重点讲述了从业务价值角度出发，进行标签生产中的需求分析环节操作指南，在本系列下一篇文章，道明将继续教你如何结合业务需求，构建标签体系，敬请期待。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>作为视觉设计师，我发现很多设计师在进入设计阶段后往往只关注局部细节，例如“什么样的设计风格更好看？”“什么样的颜色更合适？”常常忘了向前思考，去思考“我为什么要做这个需求？“”这个需求有没有更好的解决方案？“。但是设计师不能仅限于眼前的需求，不要孤立的去做一个功能或者产品。“就事论事”能把需求做完了，但一定不会把事情做好了。我们应该在全局性上去深挖项目的设计价值，通过不断的质疑、思考来提出更有效的设计解决方案。
本文以京东秒杀首页单品feeds流中的品牌秒杀穿插楼层改版为例子，从设计需求分析、设计解决方案、验证归纳三个部分出发，阐述在小方向的产品迭代中如何输出有效的设计方案，并从设计端向产品和业务推进。希望在建立系统性设计思维上给大家一些启发。以及在设计师该如何把控流程，主导设计上为大家提供一些参考。
一、设计需求分析
从全局思考的角度出发明确了解改版原因和产品目标，可以帮助我们梳理出核心的方向及策略点。
1.1 全局思考
全局思考指了解业务在整个大格局和全站下的定位，了解当下任务的目标和中短期的价值以及了解典型用户需求，搜集分析海量用户群体的行为和特征。从全局的角度进行思考和理解，寻找设计机会。基于目前为小的改版迭代，我们从背景、现状、和问题出发，以求更全面的了解当下需求。
背景
京东秒杀作为平台最重要的自营频道，一方面作为营销产品为平台促活，秒杀产品定位于低价限时抢购策略，有利于吸引对价格敏感度高的消费者，定时访问电商平台，为主站*流，进而带动高客单价产品的销售。另一方面作为增长产品拉新，目前的电商是存量市场，新用户数量增长缓慢，获取成本非常高。秒杀产品可利用低客单价产品，抢夺其他平台的用户，为主站拉新。
品牌秒杀作为京东秒杀最重要的子业务，对京东来说是专注于为品牌商提供一站式服务的平台，全面实现品牌商在京东平台上从上新到库存清仓的全面需求的一个渠道，是京东做品牌特卖的一种优惠形式。对商户侧来说品牌秒杀为商户提供了新的推广渠道和活动载体，是品牌曝光，聚焦品牌粉丝的重要渠道。对用户侧来说品牌秒杀满足了“价格敏感、追求质量且无明确目标”用户的购物需求。承载了用户对整个频道品牌品质感方面的心智建立。
现状
用户在浏览京东秒杀首页单品过程中，穿插楼层是品牌秒杀曝光的重要渠道。而京东秒杀首页不但需要为其子业务分流，还需要为其他业务频道分流。首页穿插楼层除了品牌秒杀，还包括品类秒杀、即将售罄、排行榜、Plus等。
问题
品牌秒杀穿插目前线上的版本整体沿用京东秒杀主色调，品牌名采用了文字描述的样式。在众多穿插楼层中无法体现业务特点和优势。
1.2 改版目标
基于以上目前面临的问题，本次改版主要聚焦在增加频道品牌感知、提升品质感和差异化三个方面。在视觉体系升级的基础上提高穿插楼层的点击和转化。
二、设计解决方案
2.1 挖掘设计关键点
根据设计目标和业务的具体情况，确定本次设计策略和主要的打法。以发散的方式尝试挖掘各种机会点，提升最终的体验、用户价值；深入每个方向，拆解为更小的可掌控因子，细化、寻找机会点；
在这一步我们也可以采用共建的方式引入更多的利益相关方，共同讨论会更利于达成共识，而且可以减小后面方案推进的阻力。
竞品分析，扩大思考面
这是我们首先很自然就想到的问题之一，通过对竞争对手的产品分析，多观察了解竞品的产品特点、视觉特点和产品结构，帮助我们了解更多设计可能性能，在自己业务场景下提供符合当前产品的解决方案。另外竞品分析也是设计的一个有力支点，帮助我们在沟通中更好的向业务方传达设计理念。
下面我围绕视觉表现和产品结构两个维度来做个分析，梳理出业内常用设计技法特点和产品结构。
通过竞品分析可以看出，影响品质感的几个因素，以及竞品的产品结构中以品牌图片+利益点为主，只有少部分是品牌图片+价格。
信息归纳探索可行方案
整信息归纳是着手设计的第一步，面对多样的信息，我们可以从信息元素、信息限制、信息层级三个方面去整理。
信息元素
面对大改版我们可以从点击率、曝光量、转化率、关系等大维度出发，发散更多关键词。此次改版为小迭代，我们选用相对更小层级的视觉吸引力、关系和决策信息三个点作为信息发散点，再结合改版前样式以及竞品分析来看。视觉吸引力我们更多考虑视觉层面信息如颜色、图形、楼层差异性等等。关系为元素间前后的相关性，主要考虑现有穿插楼层规范、品牌秒杀频道规范等等。在商卡决策中，价格、利益点、品牌信息、商品图往往是决策重点，前三个因素不一定同时出现。但在考虑的时候需要尽量的把点展示全，以供筛选以及防止遗漏。
结合竞品分析，这个时候我们可以分析得出，决策信息是一定要重点突出的：
- 品牌信息，由文字描述变为品牌logo图，强化用户对品牌的认知。
- 价格或者利益点：基于业务对品质感的要求，目前不能判断突出样式。
信息限制
理清楚每个模块的信息元素后，务必要和需求方沟通确认。因为在实际的项目设计中，信息总会有各种限制。先确认再设计，能避免后期因资源限制而返工。
通常来说，我们会碰到的限制有如下两种：
- 该数据的来源
- 信息展示方式
信息展现：穿插楼层采用一拖三的样式，即一个穿插展现3个品牌，点击商品图进入品牌落地页。
数据来源：
- 每个楼层只能抓取前三个品牌的首个商品图片，不能抓取品牌图。而且不能过滤白底图，很多商品图带有各种牛皮癣。所以在图片品质这一块无法做到统一标准和高品质；
- 抓取品牌落地页头图的利益点，字数较多在8个字左右。
- 抓取的logo图片，来自品牌秒杀落地页品牌商卡中的白底图，所以logo只能在白底上呈现，不支持其他颜色。
信息层次
信息整合的最后一步需要明确各个信息之间的层次。划分层次可以从「相关性」和「优先级」这 两部分去着手考虑。
根据相关性，我们对信息进行分类或归纳展示，紧密性更高的元素放在一起，这样能让用户在阅读的时候更加有条理地接受信息。
而根据优先级，我们可以确定哪部分信息需要突出展示或者提前展示。
相关性：品牌logo与利益点强相关，商品与价格强相关。
优先级：商品图 > 品牌logo > 价格/利益点 > 楼层标题 > 更多推荐
2.2 归纳方向策略，快速迭代
以上，我们分别介绍了在方向策略阶段获取核心信息来源的攻略。当我们有效地获取了这些信息后，进入本环节的最后一个步骤——定论，通过信息聚类、分析讨论，输出最终的方向策略结论。并在结论输出后，与产品和运营讨论迭代并确认。
由以上信息归纳结合竞品分析我们可以看出决策相关的利益点、商品图、价格、品牌logo这个信息是一定要突出的，所以在归纳方时我们选取了「关系」和「视觉吸引力」这两个方面。
通过方案A、B快速和业务、产品讨论迭代方向。
方案A：强调视觉吸引力，突出品质和差异
颜色上选用浅金色、黑金搭配突出品质感；整个卡片采用颜色包裹，与其他穿插楼层形成样式差异。背景增加V型图案设计凸显品质和差异性。
讨论结论：
关于颜色：
- 完全脱离京东秒杀，用户认知有风险。
- 如果确定了红色以外的颜色作为品牌秒杀主色调，那么品牌秒杀频道内部也应该相应的调整主色。此项调整设计到品牌定位，不能贸然改主色。
版式上：与京东秒杀现有穿插楼层差异较大，目前秒杀穿插楼层较多，完全独立的样式不利于视觉统一性的建立。
方案B：强调频道和穿插规范，在原方案基础上优化
版式：沿用目前穿插楼层的大框架，背景图提供了两种处理方式：
- 沿用半圆半包背景；
- 缩短背景，让背景条聚焦于标题，以增加商品留白，提升楼层品质感。
颜色：b1选用浅金色，凸显品质感；b2沿用秒杀红色，由高饱和度的玫红-红色渐变改为红色明度上的渐变；降低红色饱和度和明度提升红色的品质感。
辅助图形：增加V型辅助图形，增加背景颜色层次，提高与其他楼层的差异。
讨论结论：
背景样式：不希望与其他楼层差异太大，建议统一样式，沿用半圆半包背景
颜色：同理方案a，建议选用红色系。
所以最终认定的方案是b2中的第一个方案。
方案C：利益点新方案
由方案a和方案b讨论结果我们可以确定下颜色和背景样式。但是根据竞品，以及点击后进入品牌落地页的跳转逻辑，我们认为品牌加利益点更符合用户认知逻辑。所以我们在原信息的基础上提出了方案C-展现价格换成展现品牌利益点。利益点采用黑色减小楼层红色面积，视觉降噪，提升楼层品质感。
讨论结论：
利益点：价格对于京东秒杀来说，多年来一直都是一个较为重要的元素，抛弃价格换成利益点，业务、产品一致认为风险太高，不能接受利益点方案。
但是我们希望能在每一次迭代中最大化的带来迭代收益，业务和产品相对保守的迭代策略，在这个时候虽然会成为阻碍，但我们仍然希望能通过设计的专业性，让产品和业务接受新方案。
2.3确定最优方案
至此，我们提出利益点和价格的两个方案做ABtest，希望通过客观数据来验证用户对利益点的感知是否真弱于价格。
为什么做ABtest方案
众所周知，每个人对设计的评判是主观的，设计效果也不容易被直接量化。为了设计效果检验，即针对设计方案进行数据验证，通过客观的数据来量化一部分设计方案中较为主观或存在争议的地方，以此判断设计方案的优劣，从而得出检验结论。
有理有据达成共识
在现实中设计师推动一些设计方案时，往往会受到层层阻碍，要想在设计推动上占话语权，还需具备一些小技巧。其中一个小技巧是引用权威，包括但不限于：引用数据、竞品分析、设计原则、设计规范、控件库等等
京东秒杀在4月份的时候刚好出了一份关于品牌力的用户调研报告，从报告中我们可以看出用户对于品牌“限时折扣”“换季清仓”等利益点有强烈认知。
加上我们之前做的竞品分析，最终成功说服业务和产品接受ABtest方案。
走过的坑
关于误导方案
在归纳方向策略的时候我们往往受到产品和业务的误导，但是这个时候我们应该回到设计原点去看，我们的初衷是什么，这个初衷是否可以妥协。比如当我们提出利益点更符合用户心智的时候，产品和业务一方面认同但另一方面不愿冒险，所以提出了弱化品牌logo，利益点和价格共存的方案，但是弱化品牌logo与我们凸显品牌的初衷明显不符合。这肯定不能作为备选方案，所以直接被我们pass～
关于细节
当我们完全确定好视觉方向、版式、元素之后再考虑细节，不要在确认方向的时候过早陷入细节的迭代中，过早纠结细节只会让方案在没有理出头绪的时候就已经一团乱麻。我们应该从大到小逐级确认，在最后阶段再进入重要内容的细节优化。比如利益点的颜色及展现样式我们就出过不下6中的方案，但基于我们整体视觉的确认，即使是比较多的细节方案我们也能快速确认。
三、验证归纳
品牌秒杀穿插楼层上线一个月之后，我们拿到了ABtest数据
由上图我们可以看到，利益点的点击和转化数据均要好于价格。
经验复用
我们在Q2除了品牌秒杀穿插楼层改版，还做了排行版穿插改版，从一拖三个商品改为一拖三个品类，大商品图变为小商品图，从突出商品改为突出排行榜品类。最后上线数据效果也有所提升。
结语
在设计中我们可以尝试着打破业务和产品的固有思维，通过客观的数据来量化一部分设计方案中较为主观或存在争议的地方。对设计效果的数据检验可以辅助设计决策，沉淀出优秀的设计案例，并且进一步衍化出更好的方案，同时好的设计方法论得以传承。从长远角度来看，设计价值得以彰显，设计师的说服力得到提升。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>调研结果和结论是无法直接使用的，我们需要对B端的产品进行业务分析，从而转换成为我们比较有用的东西。我们需要把一万五调研的数据，通过业务分析，转化为有用的业务流程和业务规则，以便于以后的需求分析。
一、认识业务分析
1、业务分析
业务分析就是针对每一项的业务时间，分析业务活动的特点；并确定业务活动之间的关系。具体要做的事情是：
（1）确定业务活动的规则，记录这些业务活动需要接收哪些信息；
（2）确定业务事件触发的流程，记录这些业务活动将产生哪些数据（报表），并确定数据传输路线；（同一条数据我也不是说一部就搞完了我的这个比方说某一个客户的信息，然后中间经过某一个业务的事件，然后不断的去完善，最终签完订单之后成为一个很完整的样子，产品一定要比较关注的一个词叫什么，数据流，这个数据从哪儿来到哪里去？它的整个链路是什么样子）
（3）确定事件触发相关部门、人员，标识出这些业务活动是由哪些部门、岗位在负责；（默认为所有的业务事件，所有的业务流，都是需要多个角色来协同解决，有可能是同一个部门的协同解决）
2、业务分析中常常遇见的问题
（1）不了解业务分析流程；
（2）传达业务需求的人不少使用业务的人；
（3）不同业务部门的经常有需求矛盾；
（4）客户直接告诉我怎么做。
二、B端产品业务的分析方法
1、业务分析关键要点
（1）业务的角色
产品中的角色是由多个角色进行组成的，然后在分析角色的这个过程中呢，我们会把它进行一个分类组织部门级和岗位级，他是有一个明确的，比方说是，他是一个宏观的一个视角，它的受众群体是什么？比方说，某一个高级的领导，或者是一个企业主，或者是一个部门的总监，比方说采购部门总监，财务部门总监啊等等，而他们的特点是什么？管理的是整个公司的业务，并且是业务的决策，人的决策，而且他们的岗位职责是各不相同的，例如销售部的总监的总监管理的采购啊，然后财务管理是财务系统，那在这个过程中多个业务的这个决策人，各自决策的是你负责的这个业务中，这个业务的战略。部门级的这样这样的企业当中的一个中间的一个脉络，中层的管理层啊，举个例子，刚才咱们讲的是一个销售总监，什么是这个部门的经理，部门的经理部门的一个管理岗位审批，有一些内容的数据管理，数据的统计，销售人员的统计，销售人员数据的一个管理岗位，最后他要去真正的去执行业务人员具体的事。在同一个部门，同一个业务中，通常是由这三种角色，进行一个承接的，一个是业务的决策，中层管理和人员实施。
例如一个企业中，企业主，或者是一个销售总监，他所承担的一个角色他要去干嘛？整个公司发展的一个战略，销售的一个战略的我明年的一个业绩目标是多少？然后我整个部门的一个部门管理啊，决策管理，我的销售经理要干嘛？要干嘛，销售经理他要去管理，可能有，我这个销售部，有三个销售小组，三个销售小组，分别负责华东区，华南区啊，东北区，那么每一个小组中，有一个销售经理；
销售经理，他管的就是我这一块地区，业绩管理中，有我这个小组的一个业绩目标，这个小组中也会有自己小组的一个，客户资源管理客户池，然后小组也会有自己的一个业绩目标的制定，最后，我作为一个经理，我下面我带了10个人，我要对这10个人做一些KPI的考核，KPI的考核，可能在这个过程中有很多的这种审批的环节，比方说销售承担的审批，比方说，这种也需要有销售经理去承担，是一个中层的管理者，一些业务的一个审批；
销售代表，所能够要去做的就是最终这个业务的一个执行，一个执行的动作，他要去做的就是比方说最终客户的一个跟进，我要带客户看房，我要跟客户沟通，我要跟客户上门拜访，最后呢我希望能够跟客户承担签订合同，这个客户的收款，打款的这样的一个情况，那销售代表做的就是整个业务过程中所有的业务执行。
同一个或者说同一个业务中，所参与的一个部门，可能是决策层岗位，咱们刚才讲的是不是同一个部门，多个部门，比方说，跨部门的销售，我可能要跟采购的人员进行沟通，采购人员要跟财务的人员进行沟通，跨部门的协作，有很多都是这样做的业务的类型，一般叫做叫做生产管理流程。
（2）业务类型
业务类型：
可视化工具体现流程分析的输出：
这个看房业务，有4个个角色，可以理解为是4个人员，第1个客户，现在是一个房地产的，CRM系统，比方说你现在就是一个房地产CRM的产品经理，然后这边你要去梳理这个流程中，你要找到关键的人，关键的角色，这个角色中有一个是外部的，有三个是内部的，比方说客户，经纪人，这边的经纪人，其实我们理解就是一个销售，就是一个销售经理，经理跟这个经纪人她俩是同一个部门的，他俩是同一个部门，但是他俩做的事儿，是不一样的，这个经纪人呢，他主要是去做一个具体的业务的执行，而经理做的是一个管理的工作对不对？那么我们刚才讲了一个决策人，比方说总监级别，但是，在这个业务流程中不需要总监的参与啊，因为不是所有业务流程，需要所有人都要参与进来。
还需要一个交易员，交易员这个这样的一个角色，销售经理跟销售经纪人他不是同一个部门的，他是属于另外一个部门，他属于一个要做业务支撑部门吧，交易管理部门。这样一个部门，他是属于这样的一个角色，所以先确定角色，针对于房地产行业看房，这样的一个过程，需要一个客户和三个内部人员来进行看横向的过程，横向过程，因为咱们做任何的这一种，是要分阶段的，例如，看房的这个阶段，这个阶段的话它就需要第1个，我要先去寻找业务，寻找业务，因为我们知道就像我们考虑到，房地产行业房产销售嘛，就比方说恋家的一个销售人员，在这个过程中，他也不是说每一个客户，他一定是，比方说带50个，有意向的这种客户去看房，最后有可能成交一套，这是他们的在分为多个阶段啊。
第1个就叫做寻找业务的阶段，寻找业务，也是要去撒网的去找到意向的客户啊，有可能我主动联系客户，有可能客户主动到我的门店，售楼中心来，沟通交流；第2个点，带客户看房这样的一个阶段，客户有意向，但是客户要走中间的一些环节，唉，我要去看房，而你看房的话可能会去看多套房或者是同一套房看多次都有可能，第三，客户最后确定确实有意向，确实有意向，然后，进行一个成交环节的过程的话，可能就比较放松，但是，咱们整体的这个业务流程，整体的业务流程会经历到三个阶段，这三个阶段的这个过程中；第三点，业务进行进行分类，也是同样的。
经纪人可能会根据系统系统，然后去查看，调到我这来，需要，比方说某某小区，这个时候调用一个资源非常重要的，通过审核才有权限来去接着去做下面的事情，而这个时候他就承担了一个，因为我要去做一个管理，不是说，让所有的业务人员，那整个市场可能就会全乱了的而可能咱们可以去看房了，但也要需要进行一个管理，看房也是一个，这样的一个过程，我就发起一个审批的通知，经理同意了这个客户看房，当然，看房之后的话可能要去签订的确认书，安全措施的一些保证，例如现在，那个对于房产的销售来讲，也会很怕这个客户私下直接找房东签订购房协议。
在这个成交的这个环节中，我们对于客户来讲，先要跟去谈一个协议，需要交给经理，进行备案，最后生成购房协议。进行一个审批，审批最后交易的操作，操作的过程中进行反馈，看完这一整个完整流程，我们会发现，在这个过程中比较多了，因为我这边用不同颜色进行区分，所承担的主要的角色是，不涉及到一些数据报表的统计，统计一些数据的分析，所以说这边更多体现的是一个考核，那么有一些管理的一些需求的话，那这个时候就是主要是由销售经理来去承担这样一个角色，我可以去看一些客户的数据，比方说一些交易的数据，一些合同的数据，它的一个销售的结果，考核比较大量的一些，比方说，系统匹配，或者是交易的一些算法逻辑，交易的一些反馈，是不是一些辅助性的。辅助支撑这样一个过程，泳道图是从不同的角度来去描述一个业务流流程，流程如果通过文字来描述，其实是很困难的，体现是非常非常苍白的，所以说我们要系统化的进行分析，因此我们必须要去借助跨职能流程图好，后面再去做任何的业务流的时候业务流程电话的事。
真正提供服务的这个角度上来分析这个是为什么，从0~1的说客户没有你这个系统的时候怎么样了啊？怎么样来去完成他的业务工作？就比方说，现在工业互联网，没有任何一款产品提供给工业互联网服务，工业化生产还是活着的呀，他也是在这样的过程对不对？只是说他们在这个过程中，并且效率比较低啊，这是他们的问题，但是这个时候你就完完全全没有办法通过这个产品它是这样做的啊。所以说你只能通过客户真实的使用场景，这样的结论流程是否真的准确，就好像是得到了一些客户的需求对不对？这是你能够得到的，我们没有办法保证100%的准确，但是这个过程我们是不是可以把这样的一个流程发给我们的调研的人来去进行一个二次确认，比方说你可以把这个流程搞定了，这个阶段我就发给你，我的经纪人调研调研的经历，跟他们确认他们会说，这个地方不是这个样子的，这个地方根本就不需要跟我去审批，或者是这个地方，审批之后还有一个环节，你遗漏了，还有一个比方说刚才说的拿钥匙确认，要是这样的一个环节啊，这也是不一样的，如果确认要设置这个环节，有需要的话，我还要去跟房东进行一个二次确认，这个地方你可能就是调研的时候漏了，或者说你也没问我们也没说，但是这个东西在我们沟通的这个过程中是有这个场景的，这是我们要去做的一些事情，而不是说所有东西想当然的，我们就要去做b端再去做产品设计，一定要非常的严谨，多去跟客户确认需求，这个是没问题的。
（3）业务规则
咱们干了什么业务业务流程第一部分，第二部分，最后形成一个，但是还不够，拿着一个业务流程你就能去做，做一个产品设计了吗？你就能够真正的去把它放到一个系统中了吗？你的规则，你举个例子是规则非常多的，随便讲的话也可以知道啊，其他销售的客户我不能跟进，很基础的一个原则申请，每天不能超过10单，这个交易的操作必须得是等到你的这个资质审核完成通过确认无误之后才能够去搞，那这些都是一项一项的这种业务规则，随便说的话都是几百项上千像这样的一个业务规则，业务规则在你的这个流程图里面是没有办法很好的体现呢，或者说你这个流程图中基本上是没办法体现出来业务规则，那这个时候，咱们就要引入业务规则的概念。
从流程中获得用例：
业务规则表：
三、案例分析–生鲜电商
当前我们所看到的是电商的链路图，第1步，使用户下单，等等就下单，完成之后的话，要去获取订单，这边的话需要一个订单管理系统，当然了，这个订单管理系统它可能里面就有非常复杂的逻辑了，它自己就能写成写成一个非常复杂的一个业务流程多，但是这边咱们就不管它拆开来就行，咱们以一个独立模块化的方式来去描述这家公司最核心的业务链，业务流程到底是什么样子的，下面他自己处理完成之后的话，要去拆单，我们都知道订单系统的话，一定拆单是一个比较复杂的过程，拆单的话给倒了，仓储管理系统，仓储管理，因为我现在知道很多这种生鲜电商的话，都会有自己的仓储管理仓储管理就是仓库，因为我不同的产品是放到不同的仓库的，然后有的时候我一单买了很多件商品，那么要拆单不同的仓库，去解决不同的订单的问题，不同的货物的问题，仓储管理又是一个比较大的系统，他自己也有很多这种复杂的业务逻辑，那在这边咱们还是不去讲了，咱不拆开来讲，它就是作为一个独立的仓储管理系统。
列入第2条链路要去做事情，第2条链路是什么？我要找到我的商城的，因为我这个时候我收到的是一条订单对不对？我收到一条订单，这个过程中我的商城同样要去做处理，处理什么东西啊？我不是说我这个仓库是，一直都是源源不断的货物，一般是有一个最大的限度，比方说某一某一个产品，我可能我最大限度是1万件，但是我可能他销号到3000件的时候我就要去补单啊，我就要去补足我的货物已经不足了，或者是我这1万件的情况下，我只能允许我的商城的前端的商城出售1万件，我就没货了，这个时候跟采购系统就会有一个家什么东西呢？他们我这个库存已经不足了啊，因为自己会有一套复杂的这个系统，它会触发掉这个采购的心，采购的系统会发送一个采购需求，它是一个独立运作的采购需求之后他会生成采购单，得到财务系统，采购采购系统其实自己内部也是比较复杂的，它也有采购人员，采购人员负责采购不同的产品，然后采购的采购经理进行审批，通过价格数量通过才能够下采购单，给到财务系统，财务系统，需要跟供应商这边呢，就是跟业务的不同，有一些呢，是直接面对的一些生产基地，有的呢是面对的是一些二手供应商，都是有可能的，在这个过程中，他们采购的需求结算相关的一些东西，最后供应商基地和仓储仓储物流，他们通过物流，在接收到货物之后，商品核心业务，物流运输管理系统庞大的一个月，但是在这边你是没有办法把它展开的，这边是讲究流程的不另外叫做业务。
这里引入CBM组件化模型，更好的分析其他相关的业务模型：通过对企业的业务组件化建模，形成企业业务架构的顶层视图，在一张图上直观的展现企业的业务蓝图。
这个架构有影响对不对？销售采购，这几个东西都是我们的，一个一个一个具体的一个业务系统，对不对？供应链管理系统重点，重点不在于，重点在于这个，是决策链路，刚才咱们讲的什么？总监经理和执行者。业务员三者不是这么回事，但是他们做的事情是完完全全不同的，为什么决策，什么叫决策给说针对于销售这个事儿，在一家公司来讲，不是说你去跟业务员去聊，这个你这个销售是先看房，再去审批，最后再去交易。这就了解到整个这个销售列入了吗？你只是了解了一个业务流了解了一个业务流而已，你还缺什么事儿？一家公司的任何业务都是一个自上向下的决策的任务，举个例子，2021年，比方说2020年结束的时候，每一家公司都会做年终总结和明年的工作计划，那在这个过程中比如说我是销售总监，那销售总监我就会说了，咱们明年销售额要多少多少多少，然后达到什么样的一个程度，然后纯利润多少，要签多少个客户？这是我的这个业务啊，整个公司针对于销售这一块业务战略目标，而我作为一个销售总监，制定的是这个业务的销售战略制定。这是我明年的目标，然后，是跟我下面的人，我下面人有各个部门的销售经理，有各个部门的销售代表，他们要根据这个业务再去逐层的去拆解，然后再去做具体的事情，他们不是为了做具体的，比方说看房签单这个事来去做的，他们做这个事的源头是有一个东西是我作为一个决策层制定的销售战略，然后他们再来去分析。
第2个层级，我为了去做好这个完成这个销售战略的制定，然后我这边要去做什么事，我要去做销售绩效的管理，销售绩效，然后为了提升销售业绩，我为了达到你的销售战略，所以我要去做的是什么？是销售活动啊，我要做各种各样的促销活动，双11活动，然后买房什么各种各样的活动，通过这样的一些事情，我才能够达到你这个目标，在进行各种各样的拆解后管理。
执行，执行要做什么事情？价格制定的销售活动我要去好好的去实施，我的这个加工的规划，加工工序标准化，加工的品控。那我的管理层就要做好进销存管理，质量管控要安全加工运输，损耗管理，冷链运输，常温运输，生产加工包装供应商计入考核等等。
这是一个决策的链路树，这是叫做什么东西叫做，比方说我这家公司的业务架构图，公司的业务架构图是一个自上而下的事情。决策层要去做什么事情，管理要去做什么事情，执行要去做什么，这是因果关系。只有知道这些了，我下面这些东西比方说，但是你不知道你为什么要这家公司为什么要去做这个冷链管理，原因是因为上面，比方说，冷链管理就可以画一个业务流程图，这样就知道了为什么要做冷链管理，因为上一层有相关的任务指定。
生鲜电商-销售：
具体来讲一下一些，比较简单，大家能够理解业务流程销售，其实是整个平台收入的一个源头了，那么它其实是属于的是一个核心业务，可以知道续费率多少，相关的战略等等。
生鲜电商-采购：
生鲜电商-采购流程图：
采购这种B端的流程图，跨部门，跨人员，用泳道图更加合适
收到一个采购或者是我自己本身也是有任务，我要去采购一些啊，比较好的比较优质的，并且也是利润率比较高的一些商品，这是我的工作，在这个过程中，我会有一个采购的申请，那这个时候就会发现，采购经理，也不是说全都通过，不符合标准啊，可能质量安全，有问题或者是，商品利润率不高，风险也比较大，就返回给你。采购申请不通过，采购人员接着去做采购的准备了，我就可以去准备一下，这个这个事儿已经敲定可以去做，但是呢，我还是要去做准备一下，那么我要去跟供应商沟通一下，是能够便宜多少成本多少，然后周期是什么样子的，并且双方达成了一致意见，签订合同，签订合同的比方说我先草拟一份活动，我要给到我们的一个做一个审核，比方说这个商品是否是安全的，就搞定的事情，审批，品质管理，要是不行，然后有一些问题你要去修改一下，再去协商一下，看能不能搞定，然后采购，发货仓库产品质量，然后给到财务，把这个事儿给到财务财务人员，供应商进行一个打款收款，这样才是一个相对完整的采购流程采购流程的这个事情里面，咱们要去做几个关键的事情，你一定要先知道这家公司的核心业务是什么？那这个时候通过一个简单的流程图。但是这其中呢，有一些复杂的模块啊，我们只是说把这个东西一个模块化的方式把它给梳理出来，但是不做展开，因为你想吧，如果真的是这样的话，根本就完全没法看，就是说像这种是这种物流节点，最后画出来的东西是一个上万个啊，这个是没有办法去阅读的，没有办法去不断的去拆解，但是我们可以通过一张图核心内容，
采购业务规则表：
第2个，这是他的一个决策模型，决策模型，然后，所有的这种业务都可以把它梳理，成为一个比较清晰的图的方式，来去表达这个业务的流程图和人员之间的一个关系，接着采购这一个业务中，各个不同的人要去做的事，那么这个时候我可能是跟采购啊，采购人员采购经历，参观人员，有可能在这个过程中，举个例子，采购员的话，是不是他会做一个采购的申请，采购经理收到采购员的申请，要去审批采购人员是否收到采购同意或拒绝的通知，汇聚出发，管理部收到合同，并且需要去进行一个审批的操作，建立采购单的时候，供应商要去发货，仓库的话会进行一个，就是一个约束条件，真是发货的商品的入库单是否一致，如果不一致或者是直接退货直接拒收，要不要进行进行一个操作？
生鲜电商-基地管理：
基地管理，财务系统系统进行一个这个基地进行一个大款或者说有的，因为这种有的这种对接的话他是不一样的，有的可能采购直接去对接就可以了，有的呢，可能是我要先经过财务系统进行一个预付款的一个处理对不对啊？我要先付一笔定金，可能系统产品的准备，我要去做什么定义的一个检测是否符合，通过这种物流系统，仓储管理系统，第2个，因为我是一个生产基地，如果是一个生产基地的话，生产今年产量今年的需求量增加了1000，但是我没有办法进行一个供应，所以说我要做好一个市场的提前量，市场的一个预测，或者是明年的一个计划，那我也要去做明年的种植养殖的一个排期生产，短则几个月，长则几年。育苗才能够提供一个产品。
生鲜电商-供应链：
供应链和物流对于生鲜电商来说都是很重要的东西。
可配置功能：要是没有这种定制化的功能，用不了，那么就要给他们可以配置的定制化需求。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>在日常的产品工作中，我们经常遇到某个用户不分缘由地提出“要做一个xx功能”，如果我们没有经过深思熟悉的需求分析，就投入开发，最终一定会“打不着狐狸，反惹得一身骚”。如何“逼疯”一个产品经理？告诉他用户又提需求了。难道所有的需求我们都要照单全收吗？这时候，需求分析就很重要了。本文作者将从三个方面告诉你如何进行需求分析，希望对你有帮助。
众所周知，对于产品经理来说，需求分析是其最基本的工作，同时也是其最重要的工作。掌握需求分析是其不可或缺的能力之一。关于需求分析的介绍、方法、经验在各大产品网站遍布，五花八门，纷繁复杂。不管是Kano模型还是马斯洛需求理论，抑或是五要素法或Y方法论，都是基于理论的需求思考框架和分析方法。如何把握、分析需求，还需要我们在真实的产品环境中“真看真思真体验”。
本文我们从产品经理的本职工作出发，唠唠如何做好用户需求？简单总结：就是“细辨、深问、多掂量”。
一、辨其形：识别用户需求
1. 什么是用户需求
所谓需求，在我看来就是指特定的场景下，特定的“用户”，面对特定的问题，且可以成功解决。
而用户需求就是用户从自身角度提出的需求，往往是用户在使用某一产品或服务过程中遇到的问题，并从自己的经验和想法中提出的自己对产品功能的期望和解决方案。
举例说明：晚上睡觉前，你感觉特别饿，你可以打开手机点个必胜客，30分钟后就可以饱餐一顿，当你吃饱喝足后，你的需求就解决了。
再比如，中秋佳节独在异乡，你深情触发，回忆起小时候的美好时光，特别向往再回到那快乐的童年，但是目前无论什么科技都无法做到，那这就只是一个长期待解决的问题，而不是一个需求。
因此，我们定义需求的基本结构为：用户+场景+问题+可解决。需求不是独立存在的，它是依附于用户+场景一起存在的，且一定是可以实现的。
2. 什么是需求分析
需求分析即是从用户提出的需求开始，挖掘出用户内心真正的目标，并转化成产品需求（解决方案/产品功能）的这一过程。
这个过程的重点在于：
- 确认用户问题
- 找到解决路径
举例说明：还是刚刚那个深夜饿着肚子的你，你希望可以解决裹腹之欲，舒舒服服的睡觉。只发现问题，没有解决问题等于“无“，我们还要找到解决路径，如：在线点份炸鸡；或者楼下超市买个面包。如此，这才是一个完整的需求分析。
3. 拒绝“伪需求”
工作中，我们经常听到就是以伪需求之名堂而皇之的拒绝需求。先不论需求是否被接受，且是以真伪进行区分就已经站错了方向。正如阿基诺所说“世界上本没有绝对的垃圾只有放错位置的资源”一样，在产品的世界中，没有绝对的真伪需求，只有未被识别的问题或未能发现的痛点。
对于伪需求的定义，往往是因为：
- 用户没有说清楚
- 用户说清楚了，而你却没有明白
- 用户只是在提出一个解决方案而非一个需求
需求分析是基于用户、场景，层层发现需求本源的过程，只有准确的识别需求，才能挖掘出用户的本质目标，给后续的产品设计提供合理的方案。
二、问其心：挖掘需求本质
用户需求是用户基于自身角度所提出的，是最表层的需求，通常情况下，用户在提出需求时总会自觉或不自觉地对需求进行加工，并构建基于他们理想或期望基础上的产品功能指向。在功能指向的背后，暗藏着一个个潜在的用户动机，这才是用户真正希望解决的问题。
当我们拿到这些构建于不同需求方自身经验之上的用户需求时，不能直接开始考虑“怎么做”，而必须先搞明白“为什么要做”，了解用户真正的目的和动机，只有弄清楚why，才能进一步思考how，否则在不明确需求的前提下谈解决方案，就是在浪费资源。
了解“为什么做”，首先就需要思考内在的目标，并以此拆解需求。
需求的目标就是用户为什么要做这个，好处是什么，这是用户使用该产品/功能的驱动力来源。
需求的构成包括用户、场景、问题、路径四个方面，下面将从这几个方面，围绕用户的本质目标详细拆解以挖掘需求的更多动机。
1. 用户
用户方面：谁提出了这个需求？这个需求满足的是不是我们的目标用户？这类用户有什么属性特征？是重度用户还是一般用户？
需知，需求来源众多，但提出需求的人并不一定是需求用户，任何一个产品都是有目标用户的，我们要根据产品服务的对象，确定核心用户是谁。
举例：比如通过复贷订单数可以初步判断是否是我们的核心目标用户；通过复贷额度可以判断该用户大概的信用层级等。
2. 场景
场景方面：用户的使用场景是怎样的？这个场景是否高频出现？这个场景是否和我们目前的场景相契合？
场景包含时间、地点、人物、事件等。场景不同，用户的目的就可能不同。需知，场景越真实，用户的需求也就越真实。
而场景的高频说明了这个需求大概率是高频的，自然也就决定了你的产品表现。
3. 问题
问题方面：就是在当前场景下，用户遇到了什么问题？问题的本质是什么？
对于问题，我们需要多听、多看、多体验，听取用户真实的反馈、观察用户真实的操作、体验当前场景下的真实使用感受，从而发现表层以下本质的问题。
4. 路径
路径方面：就是为了解决用户的这个问题，我们提供哪些解决方案？当前用户的解决方案是什么？
基于用户提出的问题，他目前的解决方案是如何做的？对比用户当前的解决方案，新的路径是否带来了方案的提高、体验的优化、是否解决了用户的问题？梳理出用户的基本操作流程、和功能页面。
三、量其用：掂量需求，砍掉无用的“枝杈”
1. 掂量价值
一个需求/产品的价值包括用户价值与商业价值。
用户价值，即需求解决了用户什么问题，给用户带来了什么好处，满足了用户的什么期望。
参考俞军老师对于用户价值的评估：用户价值=（新体验-旧体验）-换用成本。
我们很容易发现为什么WPS做了很多细节的创新，占有率一直比不上Office？为什么马桶MT做了一系列优化体验，实现了用户以匿名限时群聊，却还是无法替代微信？
过高的迁移成本使得有些新的产品尽管带来了新的体验，但却无法占领用户心智，无法替代已有产品。
用户价值的评估需要基于：需求的广度、频率、迫切度，即需求覆盖的用户量是否够大？发生频率是否够高？需求是否足够迫切？
在其他条件不变的情况下，用户量越大，发生频率越高，需求的用户价值越大。因此我们要优先关注并满足用户量大、发生频率高的需求。
商业价值，即满足用户需求后能否带来产品用户粘性的提高、用户的活跃和市场份额的增加，并给公司带来什么样的利益。
俞军老师同样对产品的商业价值做出了评估：商业价值=用户意愿支付的价格-成本。
如此，我们可以理解为什么大部分的O2O平台无法成功，由于获客成本过高，一切的繁荣都是平台补贴带来的虚假泡沫。
商业价值是基于用户价值而产生，需求的价值以用户为中心，只有解决了用户的问题才能实现用户价值，只有实现了用户价值才能给公司带来更多的商业价值。
因此，市场的竞争归根结底是用户的竞争，只有服务好用户价值，才能带来反哺性的商业价值。但是只考虑用户价值也是行不通的，如果只做对用户有用而无商业价值的需求，企业注定长久生存。
在用户与商业价值中找到平衡，为用户解决问题的同时也能给公司创造持续的商业价值，才是需求分析的更高境界。
2. 掂量成本与可行性
我们知道一个产品的商业价值取决于用户意愿支付的价格与产品成本的差值，而用户价值产生了商业价值，因此用户需求的最终落地实现，决定了我们需要关注需求的实现成本，还要以及考虑需求的可行性。
需求的实现成本包括人力、时间、资源、运营等因素，体现为开发、运营、市场、沟通等成本。
需求的可行性是指技术上、经济上、业务流程上是否做或不做这个需求。
如果一个需求，开发难度较高、见效却缓慢，或者低频且小众，即使我们克服了技术问题，打通了业务链条，实现了该需求，最后也是对于公司资源的极大浪费。
3. 掂量功能
掂量功能就是对需求或功能的评估分析，根据挖掘出的用户需求本质和找到的解决方案，进行优先级筛选和相关性评估，找到最终的落地路径。
评估分析的本质可以看成是一次次在需求中的“劈砍”。每个阶段的需求分析中，你都会面对一大堆需求，而最有效的管理机制就是学会“劈砍需求”，大道至简，做产品/需求并不是靠数量叠加，最重要的是要找出不同阶段中产品最核心的需求。
学会正确的砍掉需求，要做到：
- 判断产品核心价值，是否贴合，即是否满足了用户的核心价值？
- 判断需求关联性，是否整合，即是否将不同的具有关联性的需求整合一体？
- 判断需求优先级，是否契合，即需求优先级的排列是否同需求当前的价值大小相一致？
如果一个需求无法满足用户的核心价值，又与核心需求关联性较低，在资源有限的条件下，当优先砍去。
古有明训：“上医治国，中医治人，下医治病”，放到需求分析当中，我认为上层需求做人性、中层需求做产品、下层需求做功能，需求说到底是对人性的理解和分析，只要我们可以持续的辨别其形、问询本质，并做出关键的评估，如此就一定可以做好需求分析。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>许多做产品经理的小伙伴应该都遇到过这种情况：团队努力了好久的需求已经交付开发了，却又被要求要变更，而且变更还不止一次要改原型、改文档，并导致研发、设计和测试跟着改动，造成同事的不满吐槽，自己也成为众矢之的。本文作者详细分析了产品经理如何更好地完成需求梳理。
其实，我们可以通过一些办法，尽量避免一些需求变更的。
一个优秀的产品经理，更应该具备输出靠谱需求和减少需求变更的基本素养和能力。那今天我们就和大家分享一下，减少需求变更的一些办法。
二、明确用户、场景和需求
我们要知道，哪怕是同样的用户群体，在不同的场景也会产生不同的需求。
所以一定要结合用户、场景和需求这三个方面去进行需求分析和产品设计。
如果我们没有对用户、场景和需求进行深入思考、没有明确用户真正需要的是什么、不了解实际的使用情况、以及产品存在哪些问题，就去输出需求，那么我们很可能抓不到用户的核心痛点，所设计的产品或功能缺乏理论依据，导致无法满足用户需求。
如果连你自己都不清楚为什么这么设计产品，也不清楚要帮用户解决什么问题，那么你的方案就可能在评审会中被领导、开发或测试质疑，并可能导致方案的修改和需求变更。
建议：不要只把自己当做产品经理，还要学会换位思考，站在用户的角度去看问题。分析需求和设计产品的时候，要深入了解自己的用户，并分析他们的行为和特征，也要考虑产品在不同场景下的使用问题。
一定要清楚我们设计的产品要解决哪些用户的问题，产品能解决什么问题，在什么场景下解决问题。
只有明确了这些问题，我们才能更精确的提出用户所需要的需求，产品才更能经得起推敲和考验，需求变更的问题自然就会减少了。
二、充分理解客户需求
我们都知道，很多To B产品的需求是直接来自客户的。但我们往往会发现，客户有时候自己也不知道自己想要什么。
那我们在不够充分了解的情况下就去开发产品，后面就很可能要变更需求。
如果我们没有深入了解客户的这些需求，就可能在后续的实际使用中出现问题，然后发生需求变更。
建议：在和客户沟通需求时，要去进行用户画像。去调查目标群体有哪些特征和行为，比如年龄、地区、所属行业、使用的设备类型、使用产品的习惯等，都是要充分了解的内容，这样去了解目标群体的情况就会比较全面，能对用户有一个比较清晰的认知。此外还要考虑客户可能存在的需求，找到用户真正的诉求。再针对我们了解到的情况，和客户进行深入沟通，了解用户的其他想法，验证并调整我们之前提出的想法。
在投入开发前，为了减少错误，可以先给客户提供产品的原型Demo试用，然后根据客户的体验效果和客户的意见去进行调整，在确定产品能满足客户需求，并且帮助客户解决实际问题之后再投入研发，从而减少用户的需求变更。
三、梳理出清晰的业务流程
业务流程的设计是产品设计的核心。有些产品的业务流程涉及比较多，比如会有多个角色参与，流程中环节比较多，相对比较复杂。
举个例子：电商的退换货流程中就包括买家和客服沟通，把商品退寄给商家，商家确认收到商品后财务开始走退款流程。
这其中还包括系统运作等，环节多、角色也多，是比较复杂的。
如果事前没有将流程梳理清晰，没有考虑到可能发生的情况，那么在复杂的业务流程中，就可能会出现异常，也许是逻辑有错误也许是需求被遗漏。
比如：如果电商客服没有跟买家沟通好退货要填的信息，那么买家可能就是无效退货，又或者没有更改换货信息，买家就不能及时收到更换后的货品。退换货中间环节出现问题，将会给多方造成麻烦，浪费时间也浪费人力，还可能造成经济损失。
如果没有明确哪个环节应该做什么，没有各司其职，发生了遗漏，自然也就导致需求需要变更了。
建议：明确产品核心业务流程，了解清楚流程中出现的角色以及角色之间的关系。将清晰的主线流程梳理出来，流程从哪里开始，到哪里结束，中间包含哪些环节，每个环节每个角色的工作是什么，运作顺序是什么等都要梳理清楚。流程清楚了，谁在哪里该干什么都明确了，自然就减少了出错的可能。
再对每一个流程节点进行反复推敲，考虑可能会出现的问题，尤其重点考虑异常流程，因为我们可能会忽略掉一些异常情况。
比如：买家下单后填错收货信息怎么办、没有及时收货导致商品被返回去了怎么办、商品在途中丢失了怎么办、商品已经寄出去了买家想退换货又怎么处理等，这些问题都是产品经理在设计流程的时候要多加考虑的问题。
做好了异常问题的应对解决方案，需求变更也就减少了。
四、充分理解客户需求
产品经理在做产品的过程中，还要和不同的平台进行对接，这其中也许包括公司内部不同部门之间的平台，以及外部的第三方平台。
如果产品经理不够了解对接平台所能提供的能力，就可能在对接过程中出现问题，造成需求变更。
因为缺少了解，那么设计出来的产品可能在平台上没办法使用它的一些功能。
如果再遇上开发时间紧张，那就很可能要修改设计方案，导致需求被迫变更。如果产品经理在设计产品之前没有详细了解对接平台能提供的服务，就可能设计出一些平台没办法使用的产品功能。
这就需要变更需求，或者修改设计方案了。
建议：当产品需要对接不同的平台时，产品经理应该在设计开发产品之前了解清楚对方的平台，包括对方平台有哪些功能，有哪些限制，以及可以提供哪些能力等。这些可以和开发或者对方的负责人沟通清楚，又或者找到平台的API文档来阅读。
如果发现对方能提供的服务没办法满足我们的需求，就要提前与平台沟通，采取相应的措施。
比如：对方在平台上开发新功能来接受我们产品的功能，又或者我们在开发产品前修改设计方案等，开发前沟通好了，后面自然就减少了需求变更的问题。
五、规范需求变更
产品经理应该做好开发过程中需求变更过程的管控，将开发过程中发生的需求变更记录下来，记住，是详细记录每一次需求变更，这样做是为了保证每次需求变更都是有效明确且可控的。
而且做好记录也方便过后总结分析需求变更的原因，提供减少需求变更的事实依据。
建议：可以制作出一份需求变更申请表，上面的内容可以包括：需求变更申请人、执行人、需要变更的模块、原来的需求、变更后的需求以及变更的原因等内容，后续还可以补充执行时间、完成时间以及完成效果等，总之应该尽量详细。
申请人填写了需求变更申请表之后，产品经理不应该独自决定是否同意变更，还需要项目团队的相关人员对需求做变更评估，分析需求变更的紧急重要程度、变更难度、开发量、所需时间、是否影响产品上线等因素，也就是综合分析变更成本有多大，综合评估之后，再决定是否有变更需求的必要，这样的流程走下来，就可以减少无效变更需求的可能，确保每次需求变更都是有效明确的。
产品经理遇到需求变更的问题是非常常见的，我们只有不断总结之前变更需求的原因，不断学习前人的经验，才能减少以后犯错误的可能，尽量避免需求变更。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>权衡，这个词贯穿了产品经理的职业生涯。每逢遇到了做决策的时候我们总说“价值导向”，但当这个词所涉及的组织和角色几何式上升，各方的着眼点及利益点都不同，我们应该满足谁的需求，资源又该向谁倾斜呢？
在B端产品的链路中，规模越大，组织和角色也越多。对于权衡，是很好的实践案例。
在全心投入B端产品的这半年，在这方面也有了些更深的认识，本文将以B端产品设计为例阐述对权衡的理解，希望能给大家一些帮助。
01 什么是B端产品？
B端产品，其使用对象是企业或者组织，用于提升效率、效果等某一特定领域的问题。对比C端产品，其受众不再是个体而是一类群体，并且与业务的连结也更为紧密。
B端产品的产生主要源于企业的规模化，组织结构增多、分工也愈加明细。链路的加长却使线下运行的成本逐渐增高，无法使边际成本真正地降低。
将业务简化、线上化、自助化做到降本增效，也正是B端产品的作用。
另一方面则是由于市场成熟，业务模式的趋同。同一片红海不会只有一艘轮船，无论是为了保持先发优势还是想后发制人，很关键的一点在于运营的效率。
效率的提升，能让我们更高效的管理、更敏捷的试错，从而更迅速的寻找优秀的业务模式。
02 如何进行B端产品设计？
2-1、梳理业务现状，确立产品定位
产品经理需要有很强的角色转换能力，对于B端产品而言，也称之为业务感。
设计B端产品需要将自身代入业务流程的每一环，对业务的现状进行调研以及梳理。
调研的主要目标如下：
- 业务是如何运作的？
- 运作过程存在什么样的问题?
- 哪些问题已经被解决了，是谁在解决？
- 目前已解决的问题是否符合该业务部门、实施部门的规划以及预期？
- 未解决部分不解决的原因是什么？
- 适不适合由你的团队来解决？
- 投入和产出是否匹配？
设计B端产品，大多会改变旧有的业务运作模式，可能是运作环境、运作流程亦或承载团队。过程中会面临无数的抉择，我们需要慎重考量变更的收益能否抹平变更的成本。
在调研时应覆盖链路不同环节的角色，不能只偏重于业务部门，还应考虑协作部门。其次不应只调研一线执行人员，还应调研负责人的预期。
在调研清晰后才能确立产品的定位，它能面向什么角色提供什么支持。产品毕竟是权衡后产物，只为自身创造的价值不能称之为价值。
2-2、优化并确定业务流程
在上一步骤，通过调研企业中各部门、系统的业务流程，经过分析、评审确定了其中不合理的环节，下一步则是优化并确定核心流程。
跨职能流程图的一轴为部门及角色，另一轴多为阶段，下图是以用户运营系统为例绘制的跨职能流程图：
绘制业务流程目的是表达业务的流向，表现业务部门的业务关系以及作业顺序，描述链路中起点、操作以及终点。
至于使用什么工具、横纵的规范、设计的细节其实并不是特别重要。
2-3、根据产品使用角色进行需求分析
B端的产品的需求，基本都来自于真实的业务场景，换言之，这些需求都是具有实现价值的。
但也正因为是真实的业务，所以需求会牵涉许多部门、角色。链路的加长，会使“要不要做？什么时候做？怎么做？做到什么程度？”这类问题复杂了无数倍。
在这一方面笔者的做法是通过梳理系统角色，从角色出发来权衡需求。
与平台相关的角色，可以粗略的划分为决策者、直接使用者、间接使用者。
其具有以下特点：
在进行权衡时，价值导向是第一位的，但由于不同角色需求的产出价值是波动的，所以并未在上图中表现。
在需求分析时，我们应根据其产出的收益决定资源的倾向、产品设计的深度。其次则是根据角色的代表、使用的场景、关注重心决定产品设计的侧重点。
1）决策者
决策者的主要代表是业务负责人、平台负责人、协作负责人，他们是决定是否使用这个平台的人。虽说价值产出会抖动，但决策者的需求优先级大多在第一顺位。
其关注的重心是边界以及收益，边界是指业务流向是否正确、人力损耗是否减少，收益则是否正向、是否达到预期。
直接和间接使用者，更侧重于局部的价值，而决策者则更侧重于全局，在产品设计上我们须考虑的是决策者的全局视图。
2）直接使用者
直接使用者首要的代表是业务运营，他们是产品发展的中坚力量。
其对产品的依赖性越高，产品创造价值的可能性才越大，业务运营的需求优先级略低于决策者，但大多数情况高于其他的角色。
在需求分析上，由于业务运营的需求零散且差异性高，我们需要提炼业务的共性，牺牲较为定制化的逻辑，对平台而言，全局效率的提升会比个别业务的体验更为重要。
在上图中，还包含了平台的研发、测试以及运营。这是因为只有支撑人员的效率提升，才有更多的资源能投入到业务需求以及非功能性需求的建设之中。
在需求分析及资源倾斜时至少要保证30%的资源分配给于非功能性需求，否则暂时性的繁荣迟早会被故障击破。
当业务支持和产品建设形成良性循环，能用和好用兼备，业务运营乃至决策者的观感才会不断提升。
3）间接使用者
这一角色，多为与平台业务某一环节所关联的研发、测试成员。其关注重点是，做什么以及怎么做。
前者是边界，后者则是接入或使用的流程和规范，在这里则不赘述了。
2-4、沉淀业务需求，封装标准化服务
B端产品的本份是降本增效以及建立规范，而建立规范又来源于“降本增效”的沉淀。
什么时候应该考虑标准化呢？在观测时间线足够长的前提下，应符合以下的条件：
- 系统建设足够完善
- 业务模式足够成熟
- 标准化的收益能超出变更的成本
如果标准化的需求被拒绝，不妨在深入思考需求背景是否符合上述的条件。
关于标准化的细节可以查看此前关于《前端配置化系统的设计思路》，这次想谈谈标准化可能陷入的误区：认为解耦一定能提升效率，更爱设计组件而非插件。
对于迅速变化的业务系统，插件更能够提升效率，组件却可能增加枷锁。判断是否插件的标准是：是否独立可用，插件可以灵活组装、随时舍弃的，组件却是相互衔接且密不可分。
电脑主机上的USB接口，只要硬件符合接入标准，无论你是U盘、硬盘还是手机都可以与之通讯。而组件则如同电脑的主机，运作需要有电源，将数字信号转换为模拟信号则需要显卡。
但无论哪种思路，始终还是为了快速响应业务，如果标准服务反而拘束了业务的发挥空间，影响了C端用户的操作体验，这就本末倒置了。
2-5、效果追踪与资源再分配
效果追踪，是权衡的重要工具，其作用是监测产品稳定性以及评估业务价值。
前者是执行效果，后者则是运营效果，这两个数据的提升，都能帮助各个团队建立信心。
执行效果，指在一定时间范围内执行的任务数量、速度、成功率、错误率等，更偏向产品的风险控制，如果执行效果不达标，前进一步却退三步，支持再多的业务也没有意义。
而运营效果则是B端产品价值的体现，虽说B端产品的价值之一是降本增效，但当效率面向不同的业务模式、运营人员，会让量化变的很困难。而另一方面，提升效率也不一定会提升效果。
运营效果的追踪，一方面能够使运营闭环，另一方面则是为了资源的再分配。
如果将企业比作一辆汽车，C端业务更多的是在踩油门，而B端支撑则更多的要考虑踩刹车。提升效率不仅是简化链路、优化流程，还包含停止投入。
追踪业务效果，可以让我们知道业务的优劣对比，帮助我们决定资源倾向。
写在最后
最后谈谈个人心态的变化吧，得益于B端的确定性更高，让我能够有信心、耐心，愿意看的更长远些。
以前的我喜欢追求产品设计上的难度，不喜欢做简单的需求，甚至还会对业务同学不耐烦。现在则不再在意难度，只在意有没有用，也许有时做的事情并不“高级”，但我却能够坚定的往前走。
产品的路很枯燥也很漫长，“做好的产品，不是做好的产品经理。”这句话与大家共勉。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>