지금 로그인 入行这些年，我大部分精力都扑在 C 端产品上，也就是大家常说的前端体验和用户侧那摊事儿。后台项目碰得不多，满打满算也就三四个。最近刚好完整跟完一个从零到一的后台系统，感触挺深，趁热打铁做一次复盘，主要从流程的角度聊聊，一个 B 端后台项目在推进过程中有哪些容易踩坑、值得留意的地方。不一定多深刻，但如果能帮你省一步弯路，也不算白写。
这个项目定位是 PGD 后台管理系统，核心用途就两个：满足内部日常的后台管理，同时支撑孵化项目的统计分析。目标用户分成几类，包括母公司的质量合作伙伴、合作渠道，以及孵化项目里的运营人员。之前最大的痛点，是用户数据、交易数据、商品数据全都散落在不同的第三方平台上，东一块西一块，根本没法做有效的管理和分析。所以产品目标很明确——通过一个线上化、可视化的平台，降低运营门槛和合作限制，减少对核心资源的依赖和投入，最终把渠道入驻率和商品质量拉上去，慢慢形成平台自己的影响力和品牌效应。
B 端后台项目的流程，和常见的 C 端前端项目差异不小。整体走下来，我把它大致归纳成六个阶段：启动阶段，先做产品需求挖掘，搞清楚为什么要做、要解决什么问题；接着是功能需求挖掘，把模糊的方向转化成具体的功能点；再到实施准备，开始规划、立项和评审，拉着各方把边界和资源敲定下来；执行前期，做需求细化、方案设计、评审和测试准备；执行中期，开发、测试、验收，战线拉得最长，也最容易出状况；最后是结束阶段，发布上线，做数据监控，再复盘总结，把迭代需求整理出来，为下一轮做准备。和 C 端项目比起来，后台项目在需求挖掘和功能取舍上要前置很多，而且“决策者”和“使用者”往往不是同一拨人，这一点对后续设计的影响很大。
如果单看岗位职责，产品需求挖掘应该是产品经理的主场。但作为一个稍微有些经验的设计师，我觉得完全不参与这个阶段的话，后面做出来的东西在深度上很容易打折扣。因为你不知道需求是怎么来的，当时讨论过哪些取舍和妥协，后面就很难做出真正贴合业务的设计。所以我比较建议，相关的用户体验设计师在产品需求刚启动的时候就加入讨论。当然，这得看公司和团队的具体情况，有些产品经理可能不太愿意设计在这个阶段介入太多，觉得会拖慢节奏或者干扰判断，这也完全可以理解。
说到目标用户分析，B 端和 C 端一样，绕不开对“人”的理解。这个项目的用户群其实挺有意思，分成三层：内部孵化平台的运营人员、入驻的渠道提供商，以及渠道商下属的门店相关人员。不同群体背后牵扯的利益相关者完全不同，收集需求的时候就得特别注意区分，不能混在一起。比如，运营人员更关心管理效率和数据看板，渠道商在意的是接入门槛和分成规则，而门店人员可能只看操作顺不顺手。所以在系统里，也要对应设置不同的注册账号和权限体系，这一点在前期就得想清楚。至于用户目标分析，举个例子，当时平台对服务商下属的门店其实是没什么约束力的。一旦门店出现差评或用户投诉，只能靠上一层的服务商去处理，平台自己插不上手，这对品牌传播影响很大。因此，新后台项目的一个重要目标，就是加强对商品、门店和商家的管控能力，不能让个别商家的服务问题持续伤害平台本身的品牌建设。这个目标一旦明确，后面很多功能设计的方向就清晰了。
功能需求挖掘这个阶段，核心就两件事：需求管理和优先级排序。当然，前面说的目标用户分析也很关键，因为用户群本身就是筛选需求层级的一个标准。和 C 端不一样的是，B 端产品里的决策者、买单人和实际使用者，往往不是同一拨人。决策层更看重的是价值优先级，比如能不能省钱、能不能提效、能不能降低风险，而不是单纯的操作体验好不好。所以，在梳理功能需求的时候，就得时刻想清楚这个需求到底是为谁提的，它在当前阶段对整个业务的价值权重有多高，然后才能排出一个合理的优先级。不然很容易陷入“每个功能都重要，最后什么都做不好”的困境。
整个项目跟下来，我最大的感受就是，做 B 端后台不能只盯着界面和交互，得往上游走，去理解业务逻辑、利益关系和决策链条。流程上的每个阶段都有它不可替代的价值，跳过了或者做得不扎实，后面迟早要还的。