5W字讲透：初阶B端产品经理工具包（下）建议收藏

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

在职场上，如果有一些工具能让我们顺手使用，工作效率会高很多。本文作者汇总整理了一份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.定期回顾改进状态，规定好回顾时间，回顾后续改进项的状态如何？是在准备？进行中？还是完成？

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

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