企业官网建设流程全解析

简介：面向希望入门或进阶B端产品经理的从业者，这份电子文档系统梳理了从业务逻辑到产品构建的完整路径。开篇先厘清B端产品经理的定位、工作流程与技能树，借助精益思想搭建底层认知；随后按单个产品管理流程拆解为规划、设计、研发、发布、监控五个阶段，每一阶段均有对应的方法与工具，例如市场与用户调研方法、需求蛋模型、需求优先级判断公式、公交模型需求池管理、信息架构设计、三种精度的原型展示、登机模式输出产品需求文档、产品发布方案、数据指标制定等；第三部分则聚焦产品经理的自我管理，涵盖工作方法、沟通技能以及六条阻碍成长的“绳索”，帮助读者规避常见职业瓶颈，逐步形成自己的产品思维。整份资料以单个PDF文件打包，大小约10.54MB，目录结构清晰、层层递进，既适合产品新人从零建立整体框架，也适合在职B端产品经理对照自查、补充方法论。目前已有三千余人浏览学习，是一份兼具体系性与落地性的B端产品学习材料。

1. B端产品经理最该补的一课：从业务逻辑推导产品构建

B端产品经理半路出家居多，见过太多同事拿到需求就打开画板工具，页面画得像模像样，评审会上却被业务方一句“这不对，我们不是这么干的”问住。问题通常不在原型，而在原型之前那一段：业务逻辑没有梳理成系统能看懂的结构。《B端产品经理必修课：从业务逻辑到产品构建全攻略》踩的正是这条主线——先回答业务怎么运转，再回答系统怎么支撑。适合从 C 端转 B 端的产品经理、刚接手复杂业务系统的新人，以及被复杂组织架构反复折腾的交付型 PM。看完能形成的核心能力是：拿到任何业务诉求，都按固定套路拆成流程、角色、数据和页面，而不是靠感觉画图。

2. 业务调研与流程建模：把口头业务变成系统看得懂的边界

2.1 业务调研做到什么程度算到位：干系人、跟岗记录与名词表

B 端产品构建的第一步不是画图，是搞清楚业务方嘴上说的流程和实际跑的流程差多远。越是成熟业务，口头描述和工作流之间的偏差越大，这个偏差通常是后期需求变更的主要来源。

我一般会把调研拆成四个动作，每个动作留一份物证。第一步列干系人清单，不只找业务负责人，还要找执行层的人。多数情况下，一线操作员才是系统每天的使用者，他们嘴里的流程和负责人嘴里的流程往往两个样。决策人给方向，执行人给细节，两者不一致不是坏事，这个差异本身就是调研产出。第二步做跟岗记录，花半天到一天坐在业务旁边看人家干活，记下每个动作、每张表单、每个异常，尤其要记那些“靠脑子记、没落文字”的规则，比如哪个字段空着也行、哪个流程能跳过，这些是流程图里最容易漏掉的隐形分支。

第三步收资料，把现有 Excel、纸质单据、旧系统截图、操作手册全部收来。不管之后系统用什么形态构建，这些资料里的数据项就是未来数据字典的来源。第四步做名词确认，把业务方用到的所有术语整理成一张名词表，写清谁在用、在什么场景下用、指什么。这一步看着基础，实际上能避免后期“退货”和“退回”在 PRD 里各说各话的尴尬。调研对象不同，关注点和产出也不同，建议按角色分开记录。

提示：B 端调研的交付物不是访谈纪要，而是三样能推导出系统边界的东西——干系人清单、跟岗记录、业务名词表。缺一样，后面构建出来的产品大概率带伤上线。

2.2 画跨职能流程图：让业务逻辑在研发和业务面前不再各说各话

业务逻辑最可靠的载体是跨职能流程图，也叫泳道图。泳道的划分维度是角色，不是部门。常见错误是拿组织架构图当泳道图，画出来的结果是业务方看不懂、研发也不敢问。

我画业务流程图按五步走。第一步定泳道，把上一轮调研得到的干系人清单按“业务职责”合并成角色，比如“申请发起人”“审批人”“财务复核人”。第二步拉主流程，从触发事件开始，一路画到终点。触发事件要写具体，比如“客户提交退货申请”，而不是含糊的“客户有需求”。第三步补分支和异常，审核不通过怎么退、数据缺失怎么补、超时未处理谁来催，这些分支在业务方脑子里有，在纸上通常没有，需要逐个问出来。第四步标注系统动作和人工动作，哪些节点必须由系统自动判断，哪些必须人来干预，这一步决定后续权限和自动化程度。第五步拿流程图回访业务方，请他们对着图讲一遍，讲不顺的地方就是逻辑断点。

这里有个关键原则：业务流程图里只出现业务节点，不出现页面元素。“填写申请单”是业务节点，“在列表页点新增按钮再弹窗录入”是实现细节，两者不应混在一张图里。流程图上出现“点击”“跳转”“按钮”这些词，说明流程还没画完，实现细节已经提前混进来了。

如果业务单据生命周期复杂，我还会补一张状态机图。把“待提交、审批中、已通过、已驳回、已撤销”这些状态画成圆圈，状态之间连线上标动作。状态图的价值在于它是定义按钮权限的依据——什么状态下谁能操作什么，比翻 PRD 快得多。

2.3 角色权限建模：RBAC 是 B 端产品构建的第一块地基

权限模型是 B 端产品构建里最容易被低估的部分。常规做法是 RBAC，用户挂角色、角色挂权限，但真正落地时会发现，三层权限必须分开设计，混在一起必出事故。

第一层是菜单权限，决定用户能看到哪些页面；第二层是操作权限，决定用户能对记录做哪些动作，比如新增、提交、审核、撤回；第三层是数据权限，决定用户能看到哪些范围的数据，比如只能看自己创建的、还是能看本部门的、还是能看全公司的。很多系统只做了前两层，数据权限在原型阶段就漏了，上线后会发现销售能看见所有人的客户，财务能看到所有部门的预算，这种事故几乎没法用配置补救。

角色不要按职位表抄，要按业务职责拆。同一个职位的人在不同场景下可能承担不同职责，比如“审批人”这个角色可以同时落在部门经理、财务专员、运营主管身上，而数据权限决定他们分别能审批哪个范围内的单子。职责拆完后，输出一张角色权限矩阵。

权限矩阵产出后一定要找业务方逐角色确认，尤其要问一句“这个角色离职了谁来接”。回答不上来，说明角色拆得不够干净。这一步确认完，再去画原型，每个页面的可操作性就已经注定了。

3. 从业务逻辑到产品构建：信息架构、原型与 PRD 的三个落地动作

3.1 信息架构：把流程节点逐一落成功能清单与菜单层级

流程图稳定后，产品构建才算正式开始。我的做法是把流程图里的每个业务节点提取成一个功能点，列成功能清单，字段则从前期整理的业务名词表直接平移过来。这样一页页对应下来，信息架构就有据可依，而不是拍脑袋定菜单。

信息架构我会按四步做。第一步，从流程图提取功能清单，业务节点的数量决定功能模块的体量，流程图上画了“提交申请”却没提取出“申请记录列表页”，说明提取不完整。第二步，按任务组织菜单，不要按组织架构组织菜单。财务部的人进来不想先看到“财务部”三个字，他想看到“待我审批”“我已审批”“全部单据”。第三步，做页面流转，从入口到完成，用户最少点几下能走完一条完整业务路径。第四步，对缺失功能打标记，凡是流程图上存在但功能清单里没有的节点，全部标红，交付前逐个解释去向。

菜单层级常见两种组织方式：按对象组织，比如订单、客户、合同，适合数据之间相互独立、查询频繁的系统；按任务组织，比如待办、审批、报表，适合流程驱动、每天打开系统就是为了处理事务的系统。如果两者冲突，我一般优先按任务组织，因为 B 端用户的核心诉求是“尽快干完今天的活”，而不是“浏览全貌”。

3.2 原型画到什么程度能评审：低保真、异常态与页面流转

原型阶段最常见的翻车是把精力花在视觉上。B 端原型评审要解决的是业务逻辑对不对，不是好不好看。我坚持用低保真线框图评审，原因有两个：一是画得快，改得快，业务方看到高保真图容易误以为系统已经做完了，注意力会被按钮颜色带偏；二是评审重点应放在字段、流程和权限上，线框图恰好把这些暴露得很直接。

每个页面我至少画三个状态。空态，用户刚进入页面时看到什么，很多产品只画了有数据的样子，导致空态上线时丑得离谱；默认态，正常数据下的展示形式；异常态，数据缺失、加载失败、无权限时怎么办。再把页面流转图补上，每个页面标注入口来源和出口去向，入口不止一个时逐个画清楚。

还需要把权限判断画进原型。哪个字段对哪个角色只读、哪个按钮对哪个角色隐藏，我在原型上直接标出来。这样做的好处是，研发不会在开发中反复来问“这个按钮普通用户看得见吗”，测试也能照着原型搭权限用例。原型上必须补充但经常遗漏的信息有三类：字段来源、校验规则、越权提示文案。

3.3 PRD 按验收标准写：功能详述、数据字典与权限矩阵

PRD 的读者有三类人：研发要知道做什么，测试要知道验什么，业务方要知道最终拿到什么。所以我把 PRD 的结构固定成八段：背景与目标、范围与边界、功能详述、数据字典、异常流、权限矩阵、埋点与统计、修订记录。范围与边界要写上本版做什么、不做什么，这页是对付需求蔓延的主要武器。

功能详述我按统一模板写，每条功能包含功能名称、触发条件、前置条件、正常流程、异常流程、字段要求、验收标准。验收标准必须写成可测试的句子，比如“提交退货申请后，审批人实时收到待办消息”，而不是“审批人能看到申请”。可测试的标准是测试写用例的直接输入，也是 UAT 时和业务方逐条对表的依据。

数据字典用表格，研发和测试看到的不再是页面上的英文字段名，而是同一个字段在系统里叫什么、界面里叫什么、从哪来。

异常流单独建一张表，每条异常写清触发场景、当前状态、系统响应、提示文案。比如“审批驳回后，申请单状态变为待修改，原审批意见展示给发起人，发起人修改后可重新提交，审批流程重新开始”。这块写全了，开发有据可依，测试也能按表造数据。PRD 完成后我习惯再请业务方通读一遍，任何一条字段有歧义就回到业务名词表修改，而不是直接改 PRD，保证名词表成为唯一事实来源。

4. B 端产品构建避坑五点：需求失真、权限失控与 PRD 漏写

4.1 伪需求：业务方说“要个报表”，实际要的是“减少对账工时”

现象：业务方提需求“加一张对账报表”，研发做了，上线后发现没人看。原因：报表不是真实诉求，真实诉求是月底对账要花两天，想缩短工时。解决：需求阶段先追问“这个报表给谁看、看完做什么动作、现在这件事花多少时间”。如果看完有明确动作，就把动作做成闭环操作；如果只是“看一下”，下季度再说。

4.2 流程图画成页面跳转：业务逻辑里混入实现细节

现象：业务流程图里出现“点击按钮跳转下一页”，评审时业务方盯着“按钮”两个字看了半天，不知道对应自己哪个动作。原因：画图的人把业务逻辑和系统实现混在一起了。解决：流程图只画状态变化和角色职责，所有页面相关的东西挪到原型阶段。检查标准一句话：把图里的所有名词读一遍，如果出现了“页面、按钮、弹窗、跳转”，就删掉重画。

4.3 权限模型照搬组织架构：一个角色跨多部门时全线失控

现象：按部门设角色，结果一个人同时归属销售部和运营部，系统里他有两个账号，数据来回倒。原因：把职位和组织架构当成了权限设计依据。解决：角色按业务职责拆，数据权限单独圈范围。一个用户可有多个角色，但系统会话里只挂一套权限组合，不要让他切来切去。权限矩阵交付时务必请业务方确认“这个角色离职后谁来接”。

4.4 PRD 只写正常路径：异常分支在上线第一周集中爆发

现象：系统上线第一周，工单全是“审核驳回后状态卡住”“撤回后审批人还能打开”。原因：PRD 里每个功能只写了正常通过流程，异常流程一笔没写，研发按最顺畅的路径开发，测试也没用例可造。解决：功能详述里强制要求列出至少三条异常路径：被驳回、被撤回、超时未处理。每条写清系统响应和页面提示，测试才有东西可验。

4.5 业务方口头确认就当验收通过：评审记录不留物证

现象：评审会上业务方全程点头，上线后业务方说“这不是我要的”，产品经理有苦说不出。原因：口头确认没有留下任何可追溯的物证。解决：每轮评审给出书面评审记录，列清本轮确认的功能点、遗留问题、待确认项；业务方逐条签字或回邮件确认。每一版 PRD 更新都保留修订记录，标注“从 v1.2 到 v1.3 改了哪三条”，避免扯皮。

注意：这五条坑的共性在于节奏太快，流程还没立住就赶着画页面。B 端产品构建是慢工细活，前段调研和后段验收占的时间，通常比中间画原型的时间更长。

5. 上线前用业务闭环做验收：验证产品构建完整性的四个检查项

5.1 四张核对表：一笔业务、一个字段、一个角色、一个异常

上线前的 UAT，我习惯用四张核对表代替“把页面点一遍”。第一张是业务闭环表，找一条真实的业务记录，从创建到归档走完整流程，记录每个节点在系统里是否有对应操作或状态。走不通的地方，就是流程漏了的证明。第二张是字段反向核对表，从数据字典里随机抽字段，反查页面里是否出现、是否必填、校验是否生效、来源是否正确。第三张是权限实配表，按权限矩阵分配测试账号，逐账号验证菜单、操作、数据三层权限。第四张是异常流执行表，把 PRD 异常流表逐条执行，包括驳回后重提、超时自动关闭、重复提交拦截。

5.2 验收会怎么开：让业务方按检查表逐条确认

我的习惯是验收会不带演示模式，直接给业务方测试账号和四张检查表，让他们按自己的业务路径走一遍。会上只记录“通过、不通过、阻塞”，不做需求变更讨论。每轮验收出书面结论，不通过项列明对应的操作路径、期望行为和实际行为。两轮验收仍然有阻塞项的，回到流程图重新走查，而不是在页面上打补丁。

这套业务闭环验收方法，来自一次带伤上线的教训。当时只验证了页面都能打开，没有跑完整笔业务闭环，结果上线第一周数据对不上账，最后发现是“提交、审核、归档”三个节点之间，有一个状态在 PRD 里漏写了。打那以后，每次上线前我都先跑通一笔真实业务，再谈功能细节。把流程图形状跑成闭环，产品构建才真正有了底线，希望这些经验帮到你。

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