本页目录

B端产品从接手到上线的关键执行动作

接手新B端项目时先画业务全景图

拿到项目后，不要急着画原型。用一周时间做三件事：

画出完整业务流程图。 从客户的业务起点开始，沿着数据流和审批流走到终点。覆盖主流程和至少三条关键异常分支。找业务方确认流程图的准确性。

判断点：流程图里是否包含了所有参与角色、所有系统交接点、所有审批节点。如果遗漏了任何一项，需求阶段就会出漏洞。

完成标准：业务方看完流程图后能说"对，我们就是这么干的"。如果业务方看完后还在补充你没画到的环节，说明走查不够深入。

写需求文档时，先明确核心数据实体和它们之间的关系。一个仓储系统至少需要定义：商品、库位、入库单、出库单、盘点单这几个实体，以及它们之间的关联规则。

判断点：看你的需求文档里，数据模型和页面描述的比例。如果80%篇幅都在描述页面交互，20%在写数据逻辑——比例需要反过来。B端产品的复杂度藏在数据关系里，不在页面上。

完成标准：开发团队拿到需求文档后，不需要反复来问"这个字段从哪里来""这两个表什么关系"。如果这类问题频繁出现，说明数据模型没写透。

不要等产品成熟了再补权限体系。在架构设计阶段就确定三件事：组织架构模型（公司—部门—岗位的层级关系）、角色权限矩阵（每个角色能看什么、能改什么、能批什么）、数据隔离规则（部门之间的数据是否可见）。

判断点：你的权限模型是否能回答这个问题——"一个部门经理能不能看到隔壁部门上个月的销售数据？"如果答案是"看情况"或"还没想好"，说明权限模型不够具体。

完成标准：权限矩阵可以直接交给开发做技术方案，不需要再做翻译。矩阵里每一格都有明确的"允许/禁止/条件允许"标注。

B端产品上线前的验证方式和C端不同。不是逐个页面检查功能是否正常，而是按业务场景从头到尾跑一遍完整流程。

准备三到五个真实业务场景，覆盖正常流程和异常流程。找业务方的实际操作人员来跑，而不是测试团队自己跑。记录每一个操作卡点和数据不一致的地方。

判断点：走查时如果发现业务人员的操作顺序和你设计的不一样，大概率是你的流程设计没有贴合实际工作习惯。

完成标准：业务人员能用真实数据跑通主流程和至少两条异常流程，中间不需要找产品经理解释"这里应该怎么操作"。

接到大客户的定制需求时，不要直接排进迭代计划。先做一轮需求真实性验证。

和需求发起人确认：提出需求的人是否有决策权？这个需求是个人偏好还是组织级业务问题？如果对接人换了，下一任会不会继续需要这个功能？

判断点：如果需求只能由当前对接人解释清楚，其他同事都说不出为什么需要——这个需求的组织持续性存疑。

完成标准：需求背后的业务问题可以被至少两个不同角色的人独立描述出来。满足这个条件，定制需求才值得排期。