企业官网建设流程全解析

简介：《B端产品经理必修课：从业务逻辑到产品构建全攻略》是一份面向B端产品经理的系统学习资料，聚焦从业务逻辑到产品构建的完整路径，适合刚入行或希望进阶的产品经理，也适合想从C端转做B端的从业者。全攻略以单个PDF文档交付，约10.54MB，内容编排完整、目录清晰，便于按章节查阅，目前已有3156人学习下载。内容全面覆盖B端产品经理的工作流与技能树，按规划、设计、研发、发布、监控五个阶段拆解，穿插市场与用户调研、需求蛋模型、D×V×F＞R需求分析、登机模式原型设计、公交模型需求管理等实用方法。书中以HR、OA、ERP等典型系统为例，帮助读者理解B端与C端在使用者、提供者和需求来源上的差异，并建立以商业逻辑为导向的产品思维。第三部分专门讲解产品经理的自我管理、沟通技能与自我成长，包括工作方法、沟通技能及绊倒成长的六条绳索等话题，可帮助读者构建从理论到实践的产品管理框架，提升在真实业务中的落地与推动能力。

1. B端产品经理的必修课：业务逻辑没吃透，产品构建就是空中楼阁

手里拿着一摞需求清单，开发排队等着你宣讲，客户却在新系统上线第一天退回 Excel 表格——这是不少 B 端产品经理的真实处境。做过几个 B 端项目的人都会有同感：B 端产品经理真正做的不是把需求列表变成页面，而是把客户说不清、看不出、藏在日常操作里的业务逻辑，翻译成一套可运行的产品构建方案。这份必修课式的全攻略，主线非常聚焦：怎么拆业务流程，怎么把需求翻译成功能架构，怎么在验收和上线前把坑填平。它适合刚转岗 B 端的 C 端产品经理，也适合做了两三年却总在被动接需求、天天帮开发擦屁股的同行，以及要跟 B 端产品打交道的开发、测试和实施顾问。

2. 业务逻辑拆解：用流程、角色、规则三层把客户业务看清楚

我做 B 端产品这些年最深的体会是：业务逻辑拆得不够透，后面所有环节都在还债。需求评审答不上来、开发做到一半返工、客户验收时才发现流程对不上，根源大多不在执行层，而在最开始没把业务逻辑看清。常见做法是拆三层：先画流程，再定角色，最后写规则。三层都完整了，任何一条需求都能找到它的业务位置。

2.1 流程层：先画主干，再补分支和异常

业务流程是 B 端产品的地基。一个采购模块，主干就是提交采购申请、部门负责人审批、财务复核、采购员下单、收货、入库、对账付款。把这条主干从起点到终点写出来，每个环节回答四个问题：这一步在业务上做什么、进去之前需要什么、做完之后产生什么、做这一步的是谁。

记录每个环节时建议记五个字段：环节名称、输入单据、输出单据、处理角色、时限要求。例如「部门负责人审批」这个环节，输入是采购申请单，输出是审批意见和审批后的申请单，处理角色是部门负责人，时限要求是一个工作日。时限这个字段容易被忽略，但恰恰是 B 端产品里「超时提醒」「待办催办」这类功能的需求来源，不写清楚，开发阶段就会来来回回确认。

主干画完只完成了一半。真正让开发阶段耗时的是分支和异常：审批被驳回后怎么办、申请的金额超了预算怎么办、提交完能不能撤回。我的习惯是每个环节强制问三个问题：做不完怎么办、不同意怎么办、做错了怎么办。把这三个问题的答案补到流程层，客户实际跑业务的时候才不会卡在半路。

2.2 角色层：谁在什么时候做什么事，决定权限和功能边界

B 端系统里的「角色」不等同于岗位名称。同样是「仓库主管」，这家公司管入库验收，那家公司管库存调拨，职责完全不同。所以角色要按「在系统里承担的一组操作」来定义，而不是按客户给的岗位列表照搬。

梳理角色的方法是回到流程层，每个环节问：谁发起、谁审批、谁执行，再补一个问题——谁需要看到结果。后一个问题经常被丢掉，但它直接决定数据权限。普通的业务员看得到自己名下的订单，部门负责人要看得到整个部门的订单，高管要看到全公司的汇总，这是三种完全不同的数据范围，必须在角色层说清楚。

一个采购场景的角色清单可以长这样：

权限设计必须前置到这个阶段，而不是等开发后期再加一个权限管理模块。菜单、按钮、数据范围都从这张表推导出来。漏掉「谁需要看到结果」里的任何一个角色，上线的第一周大概率就会出现越权投诉。

2.3 规则层：把客户的「如果……就……」写成系统能懂的规则

业务规则是客户嘴里最常出现、也最容易被模糊带过的东西。常见的规则有四类：判断规则（满足什么条件走哪个分支）、状态流转规则（什么情况下单据从 A 状态变到 B 状态）、计算规则（价格、折扣、费用怎么算）、校验规则（字段是否必填、是否唯一、格式是否合法）。

访谈的时候，把客户说的「如果」「一般」「特殊」「有时候」全部记下来，回去整理成规则清单。比如采购审批里会出现这么几条：

难点在追问。客户说「金额大的单要领导审批」，这句话没法直接落地，要追问到：金额大于多少、按含税还是不含税金额判断、超过之后是否需要更高级别的领导、审批被驳回之后是否可以修改重提。每一层追问出来的结论，都是一个真实需求点。

提示：客户第一次给的规则通常都是简化版。把例外情况逐条问出来，比开发阶段猜着做要省十倍返工成本。

2.4 把三层结果落成需求清单：一个可以直接用的字段模板

流程、角色、规则三层都梳理完，下一步是合成一份需求清单。做法是按流程环节编号，在每个环节下挂上涉及的角色和规则，生成一条条需求项。

需求清单的每个字段都有明确用途：

优先级怎么定也有讲究：和业务卡点直接相关、不做这条流程就跑不通的，定 P0；提升效率的定 P1；锦上添花的定 P2。B 端项目里常见的错误是把「客户催得急」当成 P0，结果上线后核心流程反而没跑通。

这份需求清单是后续功能架构、PRD、测试用例的共同起点。它一定要拿回给客户的业务负责人确认签字，逐条过一遍。做过定制项目的都懂，这步是 B 端产品的后悔药机制——白纸黑字确认过的东西，后期需求变更时才说得清楚。

3. 从业务逻辑到功能架构：需求翻译成产品方案的具体做法

需求清单有了之后，最容易犯的错是直接开工。跳过功能架构设计，页面之间会越来越割裂，开发做到一半发现两个模块数据对不上，再回去翻需求文档已经晚了。我一般先做三件事：定对象、切场景、做字段级设计。做完这三件事，功能架构和页面原型自然就浮出来了。

3.1 先识别核心业务对象和状态机：功能架构的骨架

B 端系统里大量功能都在处理同一类东西：单据、订单、工单、合同、客户、商品、库存记录。这些就是业务对象。产品构建的第一步是把对象找出来，然后给每个对象设计状态机——它在整个生命周期里有哪些状态、什么动作触发它从一个状态变到另一个状态、每个状态下谁能操作。

以工单为例，状态机可以简化成一张表：

状态机不设计好的后果很具体：列表页的筛选条件不知道该放哪些状态、某个按钮在什么状态下显示无法判断、审批流和业务流各走各的。开发问「这个状态下能不能编辑」，如果产品经理要现想，说明状态机还没建全。B 端和 C 端一个明显差别就在这里——C 端用户的状态路径可以很随意，B 端每个状态转移都对应一条业务规则。

3.2 按业务场景组织功能模块：别按菜单组织功能

功能模块划分最常见也最隐蔽的误区，是照着客户的菜单结构或照着竞品菜单画功能边界。结果「客户管理」塞了所有跟客户沾边的功能，「订单管理」里又出现一个客户信息修改入口，两边字段还不一致。

正确做法是按业务场景组织功能。处理退货是一个场景，它跨退货登记、审批、货物退回、退款确认四个环节，涉及客服、仓库、财务三个角色。产品设计上要把这几个功能连成一条完整的操作链，而不是分别塞进「售后管理」和「财务管理」两个割裂的模块。

操作的顺序大致是四步：把需求清单按业务场景分组，相同角色、相同业务目标的分到一组；每个场景画一遍跨角色协作流程；场景内列出功能点，包括新建、查看、编辑、审批、导出、提醒、撤回；最后产出场景和功能点的映射表。映射表长这样：

按场景组织功能的好处是需求变更时影响面很好判断。客户提出改审批流，只需要评估这一个场景链条上的功能，不需要把所有模块重新捋一遍。这个优势在定制项目里尤其明显。

3.3 字段级设计：把业务规则落到每个输入项

B 端页面大量是表单和列表，字段是业务规则最细的颗粒度。很多团队原型画得飞快，但每个字段的来源、校验、默认值、是否必填、是否可编辑都说不清楚，到了开发阶段就是一轮又一轮确认。

字段设计建议在原型阶段就做一张表，每个字段过一遍六件事：来源、校验规则、默认值、是否必填、是否可编辑、可见性。以「审批人」这个字段为例：

来源决定了开发实现方式：用户填的直接做输入框，系统算的做自动带出逻辑，上游单据带出的做关联读取，外部接口同步的做对接。如果这些不写清楚，开发只能自己猜，猜错的结果就是返工。字段设计黑匣子一样不透明，产品和客户之间就会变成互相甩锅。

3.4 MVP 边界怎么切：不是砍功能，是切一条完整业务闭环

B 端 MVP 常被误解成「先挑简单的功能做」，结果上线以后业务根本跑不通。比如采购模块只做了申请和审批，没有下单和入库，客户录完审批通过的申请单，接下来不知道去哪操作——这就是半截流程，说不上是 MVP。

正确的切法，是切一条最小但完整的业务闭环。采购模块可以先只做申请、审批、下单、收货、入库这一条主线，把对账、付款、供应商评估放二期。但审批不能砍掉，砍掉审批这条闭环就断了，业务上站不住。判断标准是：这条闭环能不能真实解决一类业务问题。能，就是 MVP；不能，就是功能堆砌。

优先级评估的常用字段是业务价值、使用频率、实现成本、风险四项。业务价值看它是不是业务卡点，使用频率看业务人员每天会不会用到，成本看开发量，风险看数据准确性和流程稳定性。按这四项打分，P0 的定义是「不做这条闭环跑不通」，而不是「客户在合同里写了」。标准产品线和定制项目切法不同，但「闭环先通」的原则两边都一样。

4. 产品构建落地：从 PRD、需求澄清到验收上线的完整流程

设计方案定了之后，后面是最耗精力的一段：把方案变成 PRD，把 PRD 讲给开发和测试，然后盯验收直到上线。这一段最怕的不是功能多，而是信息在传递中变形。B 端需求链条长、角色多，任何一个环节理解偏差，都会在客户现场被放大成事故。

4.1 把业务规则写成 PRD：结构、判定表和异常清单

B 端 PRD 的结构一般包含八块：业务背景、业务流程图、功能需求、字段规则、状态流转、权限要求、异常处理、埋点需求。业务背景这块很多人不写，觉得开发不需要知道。实际开发和测试理解了业务目标，才有办法判断「这么改是不是合理」，否则所有问题都回来问产品。

规则密集的地方，建议用判定表来写，比大段文字好懂得多。采购审批的判定表是这样：

判定表可以精确表达「多个条件同时成立」的复杂规则，开发只需要照着表格翻译成 if-else，歧义空间很小。与此搭配的是异常处理清单：每个功能点列出异常情况、系统行为、提示文案。比如提交申请时网络超时，系统要自动保存草稿并提示「申请已暂存，请重新提交」。开发阶段跳过的每一条异常，都会变成验收现场的一个 bug。

埋点需求也是 PRD 里该写的一块，B 端埋点不是统计页面浏览，而是统计业务节点事件，比如「审批通过」「申请被驳回」「库存预警触发」。这些数据是后面做业务价值验证的唯一依据，等上线后才补就来不及了。

4.2 需求宣讲与澄清会：把功能清单过成业务场景

需求宣讲最常见的错误是逐条念功能清单，「这里做一个列表，这里做一个详情，这里加个导出按钮」，开发听完一头雾水。正确的打开方式是按业务场景讲：角色 A 在什么情况下要做一件什么事，中间可能遇到什么分支，系统如何响应。让开发理解业务，比让他们记住功能更管用。

宣讲之前，产品经理先自查五个问题：数据从哪来，是用户填、系统算还是上游单据带出；权限怎么控，谁能看谁能审批；异常怎么处理，驳回、撤回、超时、作废分别怎么走；状态怎么流转，每个状态之间的触发动作是什么；改了这个功能，哪些列表、报表、提醒会受影响。这五个问题在宣讲前答不上来，宣讲现场大概率会被问住。

澄清会上开发和测试问得最多的是三类问题：边界问题，比如金额阈值是否含税、是否包含等于；并发问题，两个人同时编辑同一张单据怎么办；数据问题，初始化和历史数据怎么处理。每次宣讲完都要输出一份需求澄清记录，把存疑点、决定结论、待确认项和负责人写清楚。存疑项不解决，就等于把解释权交给开发自由发挥，客户验收时必然翻车。

4.3 验收测试：用端到端业务用例，而不是功能点用例

经常出现的情况是：测试用例全部通过，客户一跑真实业务就卡住。原因在于测试用例按功能模块设计，没人从头到尾把一条业务走完。B 端验收必须构建端到端业务用例，一条用例覆盖一个完整场景，前置数据写清楚，操作步骤从起点走到终点。

采购审批场景的端到端用例可以长这样：

这类用例要产品和测试一起设计，前置数据如果不写清楚，执行时全靠现场编，边界情况覆盖不到。验收阶段特别容易漏掉的三件事是：权限边界，不同角色看到的按钮和数据不一样；数据一致性，列表汇总金额和明细对不上；异常路径，流程断点没人走通过。

4.4 上线前检查清单：数据、权限、接口、回滚

上线前最后把关，列一张检查清单逐项打勾。基础数据初始化，部门、岗位、用户、客户、供应商、商品档案这些字典数据全不全；权限配置，按权限矩阵逐个角色检查菜单和按钮；流程配置，审批链、通知规则、超时规则有没有按实际业务设置；外部接口，ERP、财务系统、短信通道有没有联调通过；历史数据迁移，单据状态、金额、流水号连续性是否核对一致；回滚方案，数据回滚脚本、功能开关、灰度范围有没有准备好。

里面最容易出丑的是权限配置和历史数据迁移。权限配置不是上线前花半天就能完成的，经常一个用户少配了角色、一个按钮没有勾选，客户在验收现场就下不来台。历史数据迁移的重点是金额和状态，迁移完要出一张汇总表，新旧系统金额对平、状态分布对得上，再谈上线。

灰度策略也值得提一句：先让一个部门或一个区域跑一两周，跑顺了再全量放开。B 端灰度不是单纯的技术概念，本质是业务风险控制。把最难的客户留到最后，把最容易配合的先跑通，比一次性全量上线稳妥得多。

5. B端产品构建避坑指南：5个让项目反复返工的真实问题

这部分写的是一些反复出现的返工根源，每条按现象、原因、解决三部分说清。没有哪条是玄学，都是可以在前期堵住的洞。列出来的五条覆盖了从需求到上线的全周期，总有一条会让做过 B 端的同行觉得眼熟。

5.1 现象：客户说要什么就做什么，做完发现根本不是客户要的

需求阶段客户提「要一个库存预警报表」，团队做完报表，客户追问「那能不能在库存不足时自动生成采购建议」。这时才明白，客户真正想要的是少缺货，报表只是他自己想出来的解决方案。这是 B 端需求最常见的形态：客户给的是方案，不是问题。

原因在于产品经理当了需求翻译，把客户口述的设想当成了最原始输入。解决的办法是收到需求先问三层：这个问题现在是怎么解决的，不解决会造成什么损失，希望改善到什么程度。像「库存预警」这类需求，一定多追问一句「预警之后希望系统帮你做什么」，问到这里，真正的产品构建方向才会浮现出来。需求清单确认时也要和客户逐条过，明确写清本期做哪些、不做哪些。

5.2 现象：流程图看着完整，一上线就卡在分支

审批流程设计得很顺，客户用了两天发现驳回之后重新提交的单据不知道去哪了，申请人撤回的申请没有通知审批人，业务当场停摆。原因很典型：梳理流程时只画了主干路径，异常分支在需求阶段被忽略，开发自然按主子路径实现。

解决的办法是回到流程层，每个环节强制回答三个问题：做不完怎么办、不同意怎么办、做错了怎么办。把答案沉淀成异常场景清单写进 PRD。最常被漏掉的异常分支是：审批退回后修改再提交、单据撤回、超时自动转交、金额修改后重新审批、库存回冲。把这些分支一次性问清楚，比开发到一半再补要省得多。

5.3 现象：权限上线后越权，核心数据被不该看到的人看到

上线后普通业务员能查到全公司的客户电话，另一个角色没有导出按钮又投诉没法干活。原因和前面说的一样：权限设计没有和业务逻辑绑定，团队把权限当成「开发后期加一个管理功能」，角色的数据范围从来没有在需求阶段定义清楚。

解决的办法是在角色层梳理阶段就输出权限矩阵：横向是功能操作，查看、新增、编辑、删除、审批、导出；纵向是角色；交叉格子里填可见性和操作权限。再加一列数据范围，写清是本人、本部门还是全部。上线前用两三个角色账号实测一轮，专门检查「不该看到的看不到」。这一步谁都能做，但每次项目里都有人跳过。

5.4 现象：需求变更不断，开发和测试在崩溃边缘

项目中期客户每周提新想法，产品经理照单全收，开发和测试排期被打乱，最后需求文档和线上实现完全对不上。原因不是客户难缠，而是没有建立需求变更评估机制，任何新想法都被当成必做需求直接塞进当前迭代。

解决的办法是变更统一走评估流程：变更描述、影响范围、工作量预估、对本轮上线的影响，产品经理、开发负责人、客户代表三方确认后决定放本轮还是下一轮。标准只有一条——只有阻断业务跑通的问题才放本轮，大部分是优化，放到下个迭代。所有变更留痕，防止验收时扯皮。定制项目和标准产品线都适用，不然每个客户插一杠子，产品线就散了。

5.5 现象：功能全部上线了，客户却说「还不如用 Excel」

功能点全部验收通过，客户用了一个月后反馈太慢、录入麻烦、要反复切换页面，最终回到 Excel。原因在于只关注了功能实现，没关注业务负担。系统比线下流程多了很多强制必填字段，页面跳转深，操作步骤多，业务人员的感受是「系统在给我找事」。

解决的办法是在需求阶段就量化业务指标基线：录入一单需要多少步、多少分钟，每月出错几单，对账要花几天。上线后对比这些数据，而不是对比功能完成率。B 端产品构建有一条底线：不能给业务人员增加额外负担。凡是让业务更慢、更繁琐的功能，哪怕完成了，也在积累弃用风险。上线一两周后回现场看业务人员怎么操作，绕过系统、先写在纸上再录进去的行为，都是下一轮迭代最真实的需求输入。

6. 进阶用法：用业务指标验证产品构建的闭环

6.1 上线后先看业务指标，而不是只看功能完成率

功能上线只是起点。每个核心业务场景选一两个可量化的指标，上线前记录基线，上线后按周对比。采购申请到审批完成的平均时长、库存预警触发到补货完成的天数、月度对账差错率，都是可以对比的指标。找一张表格把业务场景、指标名称、上线前基线、上线后第二周的数据、是否达标五列写出来，哪个指标没达标，就回查是哪个环节停留时间过长。大多数情况下问题出在权限配置错误、流程节点设置不合理这些看似细节的地方。这一步把产品构建从「功能上线」推进到「业务闭环真正跑通」。

6.2 回业务现场看「绕过操作」，那是下一次迭代的地图

上线后两周，找个下午站在业务人员旁边看他们怎么操作。重点观察三件事：哪些步骤他们没走系统、哪些数据先记在纸上再录进去、哪些页面他们用浏览器收藏夹替代了菜单。这些「绕过行为」不是用户不配合，而是产品构建没有贴合真实业务节奏。客户嘴上说的需求会美化，手上的操作不会说谎。

我做 B 端产品这些年，最后悔的就是早期把「上线」当终点，功能交付完就不再去现场了。后来养成一个习惯：每个版本上线两周后，必须回业务现场坐一两个小时，只看，不解释，不推销。那些被绕过的操作、被吐槽的流程，比任何访谈都真实。这个习惯帮我避掉了无数次下一轮返工，也希望这套从业务逻辑到产品构建的方法，能帮你少走几个来回。希望帮到你。

本文还有配套的精品资源，点击获取