B端产品经理，你会做需求分析吗？

　　笔者从B端产品和C端产品在产品设计上的差异性出发，结合案例，对B端产品如何进行需求分析和设计进行了探讨。
　　随着云计算、AI、教育、智能制造和产业互联网的兴起，这些新技术、新方案首先从B端企业开始渗透，因此市场上对B端产品经理的岗位需求大增。
　　但目前行业内对产品需求的方法论，大部分是针对C端产品的，所以本篇文章的主题来谈谈如何对B端产品进行需求分析和设计。
　　既然要谈“B端产品”的需求分析，那么首先我们要搞清楚一个问题：B端产品和C端产品在产品设计的本质差异性在哪里？
　　C端产品设计的逻辑在于“轻流程、重体验”，以抖音这种短视频工具为例，只有2个简单的流程：发布视频和观看视频。
　　并且把观看视频的流程简化到了极致没有流程，在强大的推荐算法机制下，用户无需思考要观看什么，只需要向下滑屏，就可以实现不中断的沉浸式观看体验。
　　所以C端产品侧重的是用户的感受和体验，在产品设计时，精心对页面和交互进行打磨，大到优化版面结构，小到改变一个按钮的大小、颜色及位置，都可能会极大影响用户的行为，对产品的运营数据产生深刻的影响。
　　而B端产品呢？其产品设计的逻辑是“重流程规则、轻体验”，一个母婴电商公司的老板，购买一套电商ERP系统的目的是什么呢？
　　是让员工操作的体验更舒服、更放松？一定不是！
　　他在意的是怎么把手忙脚乱、错误百出的客服从20个人降到2个人，从而降低紧张的资金压力；他在意的是怎么把拣货流流程由人拿着单子满仓库跑，改为流水线式自动化作业，从而降低出错率；他在意的是把财务从每个月末抱着一堆单据通宵做账解脱出来，改为系统自动对账，从而让企业的财务数据清晰、透明，为经营决策提供准确、可信的依据。
　　所以，B端产品最终的目的是通过互联网IT技术对企业业务流程进行重构、优化、从而降低成本、提高效率。
　　从上面可以看出，C端产品经理像是一个感性的匠人，在产品设计时，带入同理心、想象力、简化用户心智，在产品设计时精心打磨用户感受和体验。
　　而B端产品经理更像是一个理性而严谨的“业务专家”，他们具备强大的系统性逻辑思维，富有理性的对企业业务进行全面梳理和诊断，并给出合理有效的解决方案。
　　由于B端产品业务流程复杂、功能庞大、用户角色众多，所以对B端产品经理的需求分析能力，提出了很高的要求。
　　但我在实际工作中发现，目前互联网公司对复杂B端产品具有完整驾驭能力的并不多见，甚至包括工作5年10年以上的产品经理，输出的产品规划文档，常常给人以“只见树木，不见森林”的印象。
　　真正具有复杂B端产品需求分析能力的是资深的程序员、架构师、但他们写出来的东西、技术术语过多、复杂、晦涩难懂。
　　既然B端产品业务流程复杂、功能庞大、用户角色众多，那么它一定是一个“系统性的工作”，必然得有一套“系统性的方法论”来去支撑B端产品的业务需求分析。
　　以肯尼迪发起的“阿波罗”登月工程为例，耗资数百亿美金，历时11年，动员了整个的国家力量。
　　这种“系统性的工程”，你不能上来就讨论登月舱结构，火箭推力设计的细节问题。你得有“工程性思想”去支撑，把问题分解3大步骤：“双子座计划”、绕月、登月，再层层分解，逐步细化，论证，才有可能完成这种系统性任务。
　　那么B端产品需求分析和设计，有哪些“系统性思想”来支撑呢？
　　一、确保理解背景
　　这是很多新手产品会犯的一个致命错误。例如和客户交流完后，客户需要一个ERP产品，结果发现，客户需要的只是一个订单打印小工具。
　　所以客户眼中的”ERP”，一定不是你眼中的”ERP”。
　　任何一个B端产品和解决方案，一定是在某个特定的阶段满足企业的某种价值，这种价值可以很小，也可以放的很大，这是一种平衡和取舍，所以产品经理一定要搞清楚这个产品需求产生的背景是什么？
　　你的客户目前是什么现状？组织的复杂度？使用你的产品是为了解决什么问题？是业务转型的问题，还是流程改革和优化的问题？
　　另外从某种程度上来讲，企业经营也是管理者个人意志的体现，boss对产品或解决方案的诉求是为了达成什么样的目的？你确保了你理解他的诉求？
　　对背景的理解和解读，一定是你产品文档的开篇部分。
　　二、搞清经营模式
　　在理解背景的基础上，我们需要搞清楚企业的经营模式，经营模式决定了产品分析和设计的框架。
　　很多产品没有把业务理解清楚的根本点在于，没有充分理解企业的经营模式，经营模式理解不清楚，会出现严重的系统设计偏差。
　　特别是一些复杂的平台级产品，例如钢铁B2B交易平台，涉及到行业生态上下游厂商、大大小小的贸易商、终端客户、仓储公司、物流公司、金融企业等众多的参与方，每个参与方又有不同的职能部门需要在平台作业。
　　很难想象没有搞清楚经营模式，产品需求分析和设计如何进行。
　　但搞清楚经营模式，也不是非常困难。任何再复杂的业态，一定有一条主干经营流程，这条主干流程简单的来说，就是以下几个问题？
　　卖什么？怎么卖？挣什么钱？
　　买什么：这个企业经营什么产品或服务？有多少种？差异性在哪里？
　　怎么卖：产品或服务的销售流程是什么样的？是通过互联网，还是通过线下渠道？如果是，这些渠道怎么管理？当前存在哪些问题
　　挣什么钱：企业是如何盈利的？是靠销售产品或服务吗？还是羊毛出在猪身上，狗来买单？
　　一旦你把这条主线梳理清楚，就可以清晰的知道企业的经营模型，有哪些供应商、客户、合作伙伴等各种参与方，为接下来的需求分析，打下坚实的基础。
　　经营模式可以用一张图表来说明，它是你产品设计的蓝图。通常需要用不同的线条把信息流、物流、资金流标识清楚，来搞清楚企业是如何运作的。
　　下图说明了一个家电售后平台的经营模式运作图。
　　三、析出业务角色
　　到这里，才真正从商业分析部分进入到产品分析和设计部分。
　　如何把需求从商业概念转化为产品分析和设计概念，我目前看到最具有系统性的是UML，其设计思想，贯穿了从需求分析到系统设计的整个过程。
　　但UML本身是软件工程的产物，概念繁多：图、依赖、泛化等各种概念。本身太过于庞大、复杂、笨重，并且难以学习。
　　不过其“系统性工程”思想可以值得我们借鉴学习。
　　为什么，产品分析和设计的第一步是分析出业务角色？而不是画流程图（这是很多人的做法）
　　因为业务角色是产品需求的源头，所有的产品需求一定来自于全部业务角色需求的集合，B端产品的复杂度决定了必须从业务角色分析着手，才不会出现遗漏和偏差。
　　并且B端产品越复杂、业务参与方越多、你会发现这种分析越有价值。
　　在上一步搞清楚经营模式的基础上，会会对该经营模式涉及到的所有业务角色有了个完整的了解，接下来的工作，就是把业务角色分离出来。
　　下图说明了一个B2B平台的业务角色图。
　　四、推导出业务用例
　　有了业务角色后，我们可以推导出业务用例（也即业务角色需求）。
　　UML的业务用例图，最大的好处是用一张图可以把整个系统的需求以全局的方式，生动、完整、清晰的表达出来。
　　有了这种图，我们可以很方便的和业务、开发、测试方便的去沟通需求，对系统需求有个整体的认识。
　　推导出业务用例的过程，我们可以通过以核心业务角色为重点，交叉验证思维来快速构建整个业务用例。
　　例如下图的B2B交易平台，我们只需要以该平台最重要的业务角色采购商为切入点，再来交叉验证：采购商需要采购下单，必然需要供应商发布商品、供应商发布商品必然需要平台监管人员去审核和管理这样基本可以搞清楚各种业务角色80的需求。
　　五、细化出业务流程
　　再接下来，我们需要把重要的业务需求，细化为业务流程。
　　业务流程可以用UML的活动图来展示，在toB复杂的业务场景中，我们往往使用的是跨泳道流程图，例如一个取消订单的业务流程，涉及到ERP、客服、财务不同的业务角色。
　　这样在构建业务流程的过程中，我们对系统设计如何实现，也有了一个完整的概念。
　　另外，业务流程图的最最要的一个原则是线条不能交叉，无论流程如何复杂，保证线条不要交叉，很多新手犯的错误，就是把流程图画的纵横交织像一个蜘蛛网，非常难以看懂。
　　六、绘制可视化页面原型
　　至此，我们通过对业务角色分析、不同角色的业务需求分析，核心业务需求的业务流程确认，我们实现了从商业概念到业务概念的建立。
　　接下来，我们需要把上述业务需求转化为产品系统的设计，这是一个更加细致的工作，我们最熟悉的Axure工具就正式上场了。
　　当然从“抽象的业务需求”到“具象的系统需求”，也存在一个巨大的鸿沟，这个需要参考同类产品的设计思想，从中吸取精华，并结合互联网设计，做一定程度的创新。
　　例如，采购商反馈说，通过购物车下单太麻烦了，需要一个“批量下单”功能，你单凭想象是难理解这个需求的。
　　最好的办法是到用户的工作现场，观察和感受下他平时工作是如何处理订单的。
　　等你到了现场，你会发现和2C用户的下单场景截然不同：用户的桌面是堆积如山的文档、忙碌的电话接入，长达几页的订单要等待录入
　　你会发现B端产品设计的首要目的是快速、准确、无误的帮助用户提高工作效率，节约用户的时间，其他都是耍流氓。
　　所以你需要去大量观摩和学习一些B端成熟软件的设计逻辑，再结合一些移动端的特性，例如GPS定位、拍照识别、语音，去构思一些创新的设计，可以帮助用户大大提高工作效率。
　　七、其他补充
　　产品设计过程中，非常重要的一点是，明确业务规则。
　　在一个项目团队中，由于背景、工作经验、领悟能力各不相同，如果业务规则不明确，同一个概念，每个人的理解不同，会造成鸡同鸭讲，争执不下，浪费大量时间。
　　所以一些核心、重点、复杂的业务规则，产品经理需要举出详实的例子来，把各种情况一一枚举出来，并进行阐述。
　　例如在互联网交易平台，涉及到商品、SPU、SKU这3个概念，产品经理可能对这些概念很熟，但业务方、开发人员不一定对这些概念很清楚。
　　如果在页面上只是简单的描述为“点击此按钮，将此SKU加入购物车”，会引发大量的困惑和争议，我看到过一个产品经理的需求会，为此争执和讨论了半个小时。
　　理想的做法，把这些重要的概念和规则，用数据实例呈现出来，并指出他们之间的结构关系，这样在讲解业务时，确保所有人的理解是一致的。
　　再例如互联网交易平台的交易流程，包括各种正向流程、逆向退换货流程所有的单据状态，这些单据状态互相交叉，互相影响。他们是系统设计的骨架和脉络，如果不定义清楚他们之间的互动关系，会造成严重的混乱和缺陷。
　　总结
　　整体上来说，分为三个过程，商业分析业务分析系统设计。
　　商业分析：1。确保理解背景2。搞清经营模式
　　业务分析：3。析出业务角色4。推导出业务用例5。细化业务流程
　　系统设计：6。绘制页面原型7。明确业务规则