在职场上，如果有一些工具能让我们顺手使用，工作效率会高很多。本文作者汇总整理了一份B端产品的工具包，并以案例穿插其中，可以帮助大家更好掌握文中列举的这些工具。

这篇文章仅包含6、7、8、9、10节哦，由于单篇文章不宜过长，已分为上、中、下三篇，前序章节请查看本账号，欢迎收藏、评论或转发给有需求的小伙伴~

六、产品实施工具

6.1 实施规划工具：行事历

为什么已经有了项目计划，我们在实施环节还要另外创建行事历？

项目计划规划了关键任务的起止时间，行事历细化了关键任务，追溯到一个个子项的筹备及完成情况。

行事历是项目计划的补充，在最终项目文档汇总时，行事历可以以附件的形式附在项目计划。

那么如何撰写行事历?

以某仓库管理系统（WMS）项目的行事历为例：

STEP1：根据项目计划，提取与实施相关的关键任务。

• 确认硬件情况（2024/10/08-2024/10/12）。
• 软件功能确认（2024/10/08-2024/10/12）。
• 基础信息整理（正式&测试环境）（2024/10/08-2024/10/12）。
• 基础信息录入（测试）环境（2024/10/14-2024/10/20）。
• 基础信息录入（正式）环境（2024/10/20-2024/10/20）。
• 关键用户培训（2024/10/14-2024/10/20）。
• 用户UAT测试（2024/10/14-2024/10/20）。
• 现场准备（2024/10/21-2024/11/01）。

STEP2：根据提取到的与实施相关的关键任务，进一步细化子任务，写明责任方、责任人、支持人员（系统人员）、开始日期完成日期、状态、备注。

以确认硬件情况（2024/10/08-2024/10/12）为例，它的子任务有确认网络设备、确认扫描投入、确认网络连通性，以此类推。

STEP3：重复步骤，汇总所有与实施相关的子任务，即可得到下述行事历：

表格 20某仓库管理系统WMS实施阶段行事历

6.2 实施落地工具：基础数据收集表

为什么B端产品经理需要熟悉制作基础数据收集表？

因为它可以有效帮助提升和用户/客户地沟通效率。基础数据收集表，可以在下述节点帮助我们推进工作：

• 在测试阶段获取基础数据，帮助系统测试进行回归测试
• 在实施阶段快速完成基础数据收集与验证

那么怎么制作基础数据收集表？

以某仓库管理系统（WMS）项目的数据收集表为例：

STEP1：根据系统情况，列明所有需要收集的基础信息

表格 21某仓库管理系统WMS基础信息清单

STEP2：将上述信息粘贴到Excel中,作为目录页，增加具体的基础信息明细sheet。

图片 67增加具体的基础信息明细sheet

STEP3：然后就目录页的“信息类型”列的字段增补超链接，关联到“本文档中的位置”。

图片 68增补超链接

重复STEP3的操作，我们就完成了基础信息收集表的创建。

在与客户/用户的沟通中，可以以EXCEL作为基础数据讨论的依据，提升沟通效率。此外，通过对这个数据的分析，便于我们发现项目字段超长、特殊字符等情况。

6.3 实施培训工具：操作手册

B端产品经理为什么要重视操作手册？

操作手册桥接着开发测试阶段和实施阶段，是实施培训的基础。

此外，根据对9个WMS、OMS项目为期一年的追踪复盘，40%的运维问题最终会被归类为培训问题。物流作为一个人员流动性高的行业，需要频繁的新员工的培训，如果物流系统操作手册不够细致清晰，将显著增加运维人员的工作压力。

那么操作手册应该如何撰写?

STEP1：首先需要明确培训手册的受众

以WMS为例，不是所有的用户，都有WMS的全部权限；也不是所有的用户，都需要知晓WMS的具体操作。所以在撰写培训手册之前，要考虑好是面向谁写的操作手册。

在常规地划分中，我们可以按照项目划分版本，例如：XX系统操作手册_XX项目版_V1_20241203；我们也可以按照受众划分，例如：XX系统操作手册_Vendor版_V1_20241203；我们还有可能按照最终用途划分，例如：XX系统操作手册_售前版_V1_20241203。

STEP2：在每次更新前，先维护好更新版本号，方便溯源

表格 22 操作手册版本更新示例

STEP3：在具体模块的操作指引前，需要列明每个功能的应用场景及限制。

举例：在此项目中，所有的物料主数据都从SAP同步，SKU管理中的编辑及新增权限需要在权限控制中移除。

STEP4：列明访问路径及变更方式，如果是基础数据，则需要为用户列明哪些字段是必填字段，哪些是非必填字段。

以某WMS的货主信息维护操作指引为例：

• 访问路径：全局基础数据-货主
• 新增方式：WEB界面新增

货主数据字典：

表格 23某项目货主数据填写指引

STEP4：插入合适的功能页面配图，圈出需要操作的按钮，以STEP1、STEP2……的次序引导用户一步步完成操作。

STEP5：如果是面向操作工/司机/供应商的培训，建议可以将上述内容视频化，方便上述同事从移动端查看。

以上，重复上述操作，我们就能完成操作手册的撰写。

6.4 实施培训工具：培训计划

B端产品经理为什么要重视培训计划？

首先，需要强调的是，“培训计划”是软件实施流程合规的重要归档信息，在审计环节，会由审计人员查验，如果我们的系统想要获得认证，同样有可能被抽检到培训计划（含培训记录）。

其次，“培训计划”帮助产品经理有序的规划培训内容、明确培训对象、确定培训时间，提升培训事宜的沟通效率。

最后，“培训计划”中囊括的培训记录，结合培训后上报的运维问题，能够帮助我们复盘培训效果。

那么培训计划应该如何撰写?

STEP1：列明培训计划需要包含的内容标题。

常见的培训计划，需要包含序号、所属业务流程、相关资料、培训日期、培训人/答疑人、培训对象、培训/答疑目标。

表格24 B端产品培训计划模板建议

STEP2：按照不同的业务流程，完善培训计划描述。

表格25 某项目培训部分计划

STEP3：重复STEP2的操作，直至完成培训计划初稿。

表格 26 某WMS项目培训计划

STEP4：与业务沟通敲定培训日期、培训对象。

STEP5：在进行培训时，做好培训签到记录，附在培训计划，做好归档，在项目审计时会用到。

表格27 培训签到表模板样例

STEP6：在培训完成后，可以由业务侧管理人员筹备UAT（用户参与测试）。

产品经理此时需要就业务在UAT中提到的问题进行答疑，可以用“UAT问题追溯表”承接此阶段的系统问题及发版情况。

表格28 UAT问题追溯表

6.5 实施培训验收工具：培训验收考试

B端产品经理为什么要重视培训验收考试？

培训验收考试，能帮助我们及时发现用户对系统的理解不当之处，提高用户对培训的重视程度，减少实施环节的问题。

怎么设计培训验收考试？

在培训验收考试里可以设置主观题和客观题两类题目。

主观题可以重点考察用户的实操、用户对运维流程的理解：

表格29 培训验收考试主观题举例

客观题可以重点考察用户对系统流程的理解：

表格30 培训要收考试客观题举例

七、产品交付阶段工具

7.1 上线管理工具：版本记录

为什么B端产品经理要重视版本记录？

首先，需要强调的是，版本记录是发版流程合规的归档信息，在审计环节，会由审计人员查验，如果我们的系统想要获得认证，同样有可能被抽检到版本记录。

其次，版本记录了产品的发展历程，是可以与团队提升沟通效率的工具。

最后，版本记录能够帮我们追溯版本变化，在遇到运维问题时，可以帮助我们及时确定影响范围，做好应对准备。

那么怎么进行版本记录呢？

STEP1：列明版本记录需要包含的内容标题。

表格31 版本记录包含的内容举例

STEP2：在前序文档的基础上，在发版完成后更新新版本信息。

表格32 版本记录举例

7.2 上线管理工具：上线通知

B端产品经理为什么要重视上线通知?

上线通知是进行用户期望管理的主要工具，我们通过上线通知告知关键用户、关联系统新版本信息，能够有效降低发版对用户体验的影响。

如何进行上线通知?

STEP1：列明需要通知到的人，包含上下游关联系统和系统关键用户。邮件发送下述用户，并抄送产研团队。

表格33 上线通知用户范围模板

STEP2：列明本次发版是否影响使用，以及具体的发版时间。

例如：本次发版需要停站，预计在凌晨2：00-3：00完成发版，发版期间用户将无法登录系统。

STEP3：列明此发版的内容有哪些，注意，发版内容一定要以动词开头，语句简明（让业务方能够理解）。

表格34 发版内容举例模板

STEP4：添加问候语，留下产品团队的联系方式。

例如：Bestorder团队衷心祝愿各位工作顺利，如在发版后有任何疑问，请随时联系我们（邮箱：xxxxx@xxx.com）。

以上，我们就完成了一次发版通知。

7.3 上线管理工具：上线检查清单（Checklist）

B端产品经理为什么要重视上线检查清单？

正如我在这本书提到的其他清单一样，上线检查清单的基础功能是避免我们遗漏。不同于其他清单，上线检查清单的还直接作用于产品质量提升，通过上线检查清单，能够帮助我们及时发现BUG，减小影响范围。

需要强调一点，并不是所有的问题都可以在测试环境显现，不能把生产BUG全部归因到测试人员没有认真测试，或单纯的Coding问题。作为一个团队，产品和运维有责任参与到上线后的系统检查，提升产品质量。

如何进行上线检查?

STEP1：撰写上线检查清单。

如果是从0开始准备检查清单，可以请测试帮助，拿到测试的测试用例，在此基础上，区分主业务流程与本次发版内容，整理常态化检查清单和本次检查内容。

表格35 上线检查清单模板

STEP2：如果是24h作业的系统，一定要在发版后立即进行检查。

按照检查清单，等待生产环境出现对应场景的单据，如果有异常，则及时向开发进行反馈（具体层级可以参考11.2问题复盘），确认上线检查清单所有事项都被妥善关闭后，上线检查才能结束。

八、售后运维阶段工具

8.1 问题定位工具：SQL

B端产品经理为什么要重视SQL?

SQL能够帮助产品通过数据分析和优化产品设计、定位和确认受影响的数据范围。

使用SQL的注意事项:

1）数据操纵语言（DML）分类如下，常规产品侧不需要用到SELECT外的其他语句。为了避免误操作删库跑路，在向数据库管理员（DBA）申请账号的时候，可以申请只有查询权限的账号

表格36 常规数据操纵语言分类

2）市面上存在多种数据库管理系统（Mysql、PostgreSQL、Microsoft SQL Server、Oracle Database等），在不同的管理系统中，SQL的语法是有差别的，在学习前，需要先明确学习的SQL类型

3）SQL对大小写不敏感

4）在写SQL的时候要注意语句的性能，尽量不要执行慢查询。在语句执行前，可以用EXPLAIN命令分析SQL查询的执行计划，显示查询的详细信息，包括是否使用了索引、表的连接顺序等

举例：EXPLAIN SELECT * FROM table_name WHERE condition;

产品经理常用的SELECT语句如下：

SQL JOIN是我们最常用的联表查询语句，如果不熟悉各种JOIN，可以多看下面的图：

图片69 不同的JOIN图解

这本书仅仅列举了常规需要用的到SELECT相关的语句，如果想精进，推荐可以看看《高性能Mysql》这本书。

8.2 问题分析工具：问题复盘（Postmortem Analysis）

B端产品经理为什么要重视问题复盘？

复盘是一种重要的工具，可以帮助产品经理从故障中总结经验教训，为后续思考产品设计提供参考。

如何进行问题复盘？

图片70 问题复盘流程

STEP1：在故障发生后的两天内，进行问题回顾。

完整的记录下故障的发生、发现、原因定位、决策、处理、预案执行、回滚、故障解决等的关键人与关键时间点。

STEP2：利用5W1H分析问题产生的Rootcause。

图片71 根因分析

• WHO：确定受到影响的客户是谁？受影响的系统使用者是谁？
• WHEN：确定用户何时会遇到这个问题？
• WHERE：确定在什么业务流程中产生这个问题？
• WHAT：确定产生了什么样的问题？是什么原因导致的？
• HOW：确定怎么样才能解决这个问题？如何决策？如何实施?

STEP3：通过总结，进行故障定性、故障定责及总结本次故障带来的经验教训。

在进行故障定性时，要评估对业务带来的影响（可以用SQL提取影响单据的范围），确认损失及范围。

这样做的好处有：

• 1.通过故障定性，我们可以划分不同的问题的等级（如P0/P1/P2/P3/P4等级），可以更加有序、科学的进行运维资源的分派。
• 2.通过故障定性，我们可以跳出故障本身，抽象的看待同级别或者不同级别的故障差异与共性，可以更加系统性的规划解决普世问题。
• 3.通过故障定性，我们可以识别故障处理中是否有可以优化的点，例如通过同级别故障处理手册规范故障通知、解决流程，以缩短问题处理时间。

STEP4：通过行动，落实故障的处理。

通过SMART法则，提出改进项目：

• Specific（具体）：目标需要明确具体，清晰地指出我们需要改进、优化的单项、指标是什么。
• Measurable（可衡量）：目标应该是可以量化的，明确的制定验收标准是什么？
• Achievable（可达成）：目标应该是现实的，考虑到资源和能力，避免出现一些假大空、无法落地的改进。
• Relevant（相关性）：目标应与个人或组织的长远愿景和目标保持一致，尽可能避免出现孤立的改进。
• Time-bound（时限性）：目标应该有明确的截止日期或时间框架，这个时间建议最长不要超过三个月，避免改进流于形式。

仅仅提出改进项目是不够的，接着我们要追溯改进项目：

1.首先，要明确相关改进项的负责人。

负责人可以有多个，但主要负责人有且只能有一个。即这个人需要对这个改进项的落地全权负责。当然，这个负责人的指定也需要在权责对等的基础之上。

2.定期回顾改进状态，规定好回顾时间，回顾后续改进项的状态如何？是在准备？进行中？还是完成？

在完成了改进项后，需要进行改项的关闭。

以上，我们就完成了问题的复盘。

8.3 运维需求工具：用户俱乐部（USER CLUB）

B端产品经理为什么要重视用户俱乐部（USER CLUB）？

USER CLUB提供了一个窗口，让用户可以直接反馈用户体验。

不同于分散的提出问题，USER CLUB同时邀请了所有的产品相关业务，可以就某些争议性的问题，进行跨部门的直接确认及业务优先级反馈，产品经理可以根据用户反馈进行产品优化。

怎么组织USER CLUB？

STEP1：确定系统的关键用户。

和业务部门确认，由业务部门指定对接系统的人员。

STEP2：会前收集关键用户的所有需求。

可以套用4.1的需求清单，请关键用户提前维护其需求，必填字段如下：

表格37 关键用户需求填写表

STEP3：会中组织关键用户反馈其需求。

为了避免占用所有人太长时间，可以先讲需要跨部门的需求，在业务讲解需要后，及时的反馈此需求对于其他业务职能的影响，并引导业务给出需求的优先级，避免会后扯皮。

STEP4：会后及时将需求进度更新反馈给提出的用户。

会后及时与开发测试评估，反馈业务需求的预计完成日期及预计发版版本，在发版前组织用户UAT，在发版后通知业务进行验收。

术语表:

参考文献：

[1] 国际物流与货运代理从入门到精通 物流管理[M]. 国际物流与货运代理从入门到精通 物流管理, 2020.

[2] 王伟. 电商产品经理：基于人,货,场,内容的产品设计攻略[M]. 电商产品经理：基于人、货、场、内容的产品设计攻略, 2019.

[3] 梅芊, 黄丹, 卢艺. 基于MBSE的民用飞机功能架构设计方法[J]. 北京航空航天大学学报, 2019, 045(005): 1042-1051.