B端项目组件化思考：流程篇
副标题[/!--empirenews.page--]
入行以来，侧重点都是偏向前端即所谓的C端，较少触及后台项目，细细数来不过三四个而已。最近再次从0到1完成了一个后台项目，感触颇多。 借总结复盘之机，分享一些自己的体会。不管是流于表面也好，或是对你帮助自然更佳，一同共勉前行。
一、项目背景产品定位：满足内部孵化项目后台管理、统计分析需求，代号为PGD后台管理系统。 目标用户：母公司的品质合作商、已经合作的渠道商、孵化项目的运营人员。 痛点：重要的用户数据、交易数据、商品数据部署在第三方平台，且分布分散，无法形成有效的管理和统计分析。 产品目标：通过线上、可视化平台进而降低操作门槛、合作限制，减少核心资源的投入和依赖，从而有效提升平台的渠道商入驻率和商品的质量。最终，形成平台性的影响力和品牌效应。 二、项目生命周期
（可点击放大） 如上图所示，后台项目产品的流程与前端项目相比而言，有些节点还是存在差异的。 一般而言，可以分为六个阶段：
（可点击放大） 三、阶段拆解分述3.1 启动：产品需求挖掘
（可点击放大） 产品需求挖掘，如果从岗位划分来说是产品经理的职责范畴。可是作为体验设计师，你如果不参与这个过程，在某种程度上，后续在理解业务深度上是有可能存在偏差的。 所以，建议相关用户体验设计师在产品需求初立，即加入讨论。当然，这个恐怕需要结合不同公司，不同合作团队来看哈，有些产品不一定乐意体验设计师提前介入。 3.1.1 目标用户分析
不管是B端产品，还是C端产品，都离不开客群用户。 KCL项目的用户群体，其实有些不同。如上图所示，分为三大群体：所在内部孵化平台运营人员、入驻渠道商及渠道商下属的门店相关人员。不同群体又涉及不同的利益相关者，这就需要在进行目标用户分析的时候，注意不同用户需求问题的收集，并设置不同的登记编号。 3.1.2 用户目标分析
改版或者旧版架构关系如上图所示，平台对于服务商下属的门店没有影响和控制力，门店出现服务差评或者用户投诉的时候，只可以通过门店的上层服务商进行处理，这种情况极大的影响了平台品牌传播。 因而，项目平台希望新版后台项目可以加强对于商品、门店、商户的影响和控制力，避免因为入驻商户或门店的服务，影响到平台自身的品牌建设。
改版用户目标 3.2 启动：功能需求挖掘
功能需求挖掘的核心，在于需求的管理和排序管理。 当然，对于明确目标用户同样重要。目标用户客群，是筛选需求层级的标准因素之一。 因为与C端不同，B端的决策者、购买者、使用者通常不会是同一波人，并且价值优先级为决策层>管理层>执行层。故在权衡决策产品时，不仅需要从多层级来进行综合平衡，需要更加关注对决策层和管理层的价值。决策层，可能是业务方的boss们，也可能是上级主管层。 而我们获取需求的方式，一般主要分为业务需求、技术需求和功能迭代优化需求。业务需求又分为内部需求和外部需求。例如所在KCL项目来说，我们除内部KCL业务场景的需求，还有母公司分配过来的需求。 技术需求的基数一般比较小，这种需求主要存在于外部需求情况下会产生技术类需求，一般都是由业务需求产生技术类需求。各种需求汇集成需求池，对于需求的优先级排序就显得极为重要。 3.3 执行：规划、立项、评审
其实这个阶段，我暂时未参与。上图中关于立项的细节，主要是通过一高级产品朋友获知。 关于规划立项这个，据说一些大厂有的是由产品来推动，有的是由高级体验来推动立项。立项通过后，需要负责人协调各个部门资源去推动立项的细节，上线之后的指标会直接影响最终的考核。 话题跑远了，关于立项这个环节，依不同公司和项目团队自定，非必要环节。但每次发起需求时，也需要明确产品的价值，如何去衡量收益，是否与项目、公司目标有关联，是否一致。 这个对于接下来的需求排序和交互方案设计，有着重要的参考依据价值。 3.3 执行：需求、设计、评审、测试
3.3.1 需求评审 由上一个阶段筛选初步需求优先级之后，需要进行需求评审。 需求评审的参与方，一般包含业务方、产品经理、用户体验设计师、视觉设计师（非必须）、研发（此阶段可不参加）。之后，依据确立当前版本的迭代规划，开始交互方案设计。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
