在职场上，如果有一些工具能让我们顺手使用，工作效率会高很多。本文作者汇总整理了一份B端产品的工具包，并以案例穿插其中，可以帮助大家更好掌握文中列举的这些工具。
这篇文章仅包含6、7、8、9、10节哦，由于单篇文章不宜过长，已分为上、中、下三篇，前序章节请查看本账号，欢迎收藏、评论或转发给有需求的小伙伴~
为什么已经有了项目计划，我们在实施环节还要另外创建行事历？
项目计划规划了关键任务的起止时间，行事历细化了关键任务，追溯到一个个子项的筹备及完成情况。
行事历是项目计划的补充，在最终项目文档汇总时，行事历可以以附件的形式附在项目计划。
那么如何撰写行事历?
以某仓库管理系统（WMS）项目的行事历为例：
STEP1：根据项目计划，提取与实施相关的关键任务。
STEP2：根据提取到的与实施相关的关键任务，进一步细化子任务，写明责任方、责任人、支持人员（系统人员）、开始日期完成日期、状态、备注。
以确认硬件情况（2024/10/08-2024/10/12）为例，它的子任务有确认网络设备、确认扫描投入、确认网络连通性，以此类推。
STEP3：重复步骤，汇总所有与实施相关的子任务，即可得到下述行事历：
表格 20某仓库管理系统WMS实施阶段行事历
为什么B端产品经理需要熟悉制作基础数据收集表？
因为它可以有效帮助提升和用户/客户地沟通效率。基础数据收集表，可以在下述节点帮助我们推进工作：
那么怎么制作基础数据收集表？
以某仓库管理系统（WMS）项目的数据收集表为例：
STEP1：根据系统情况，列明所有需要收集的基础信息
表格 21某仓库管理系统WMS基础信息清单
STEP2：将上述信息粘贴到Excel中,作为目录页，增加具体的基础信息明细sheet。
图片 67增加具体的基础信息明细sheet
STEP3：然后就目录页的“信息类型”列的字段增补超链接，关联到“本文档中的位置”。
图片 68增补超链接
重复STEP3的操作，我们就完成了基础信息收集表的创建。
在与客户/用户的沟通中，可以以EXCEL作为基础数据讨论的依据，提升沟通效率。此外，通过对这个数据的分析，便于我们发现项目字段超长、特殊字符等情况。
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的货主信息维护操作指引为例：
货主数据字典：
表格 23某项目货主数据填写指引
STEP4：插入合适的功能页面配图，圈出需要操作的按钮，以STEP1、STEP2……的次序引导用户一步步完成操作。
STEP5：如果是面向操作工/司机/供应商的培训，建议可以将上述内容视频化，方便上述同事从移动端查看。
以上，重复上述操作，我们就能完成操作手册的撰写。
B端产品经理为什么要重视培训计划？
首先，需要强调的是，“培训计划”是软件实施流程合规的重要归档信息，在审计环节，会由审计人员查验，如果我们的系统想要获得认证，同样有可能被抽检到培训计划（含培训记录）。
其次，“培训计划”帮助产品经理有序的规划培训内容、明确培训对象、确定培训时间，提升培训事宜的沟通效率。
最后，“培训计划”中囊括的培训记录，结合培训后上报的运维问题，能够帮助我们复盘培训效果。
那么培训计划应该如何撰写?
STEP1：列明培训计划需要包含的内容标题。
常见的培训计划，需要包含序号、所属业务流程、相关资料、培训日期、培训人/答疑人、培训对象、培训/答疑目标。
表格24 B端产品培训计划模板建议
STEP2：按照不同的业务流程，完善培训计划描述。
表格25 某项目培训部分计划
STEP3：重复STEP2的操作，直至完成培训计划初稿。
表格 26 某WMS项目培训计划
STEP4：与业务沟通敲定培训日期、培训对象。
STEP5：在进行培训时，做好培训签到记录，附在培训计划，做好归档，在项目审计时会用到。
表格27 培训签到表模板样例
STEP6：在培训完成后，可以由业务侧管理人员筹备UAT（用户参与测试）。
产品经理此时需要就业务在UAT中提到的问题进行答疑，可以用“UAT问题追溯表”承接此阶段的系统问题及发版情况。
表格28 UAT问题追溯表
B端产品经理为什么要重视培训验收考试？
培训验收考试，能帮助我们及时发现用户对系统的理解不当之处，提高用户对培训的重视程度，减少实施环节的问题。
怎么设计培训验收考试？
在培训验收考试里可以设置主观题和客观题两类题目。
主观题可以重点考察用户的实操、用户对运维流程的理解：
表格29 培训验收考试主观题举例
客观题可以重点考察用户对系统流程的理解：
表格30 培训要收考试客观题举例
为什么B端产品经理要重视版本记录？
首先，需要强调的是，版本记录是发版流程合规的归档信息，在审计环节，会由审计人员查验，如果我们的系统想要获得认证，同样有可能被抽检到版本记录。
其次，版本记录了产品的发展历程，是可以与团队提升沟通效率的工具。
最后，版本记录能够帮我们追溯版本变化，在遇到运维问题时，可以帮助我们及时确定影响范围，做好应对准备。
那么怎么进行版本记录呢？
STEP1：列明版本记录需要包含的内容标题。
表格31 版本记录包含的内容举例
STEP2：在前序文档的基础上，在发版完成后更新新版本信息。
表格32 版本记录举例
B端产品经理为什么要重视上线通知?
上线通知是进行用户期望管理的主要工具，我们通过上线通知告知关键用户、关联系统新版本信息，能够有效降低发版对用户体验的影响。
如何进行上线通知?
STEP1：列明需要通知到的人，包含上下游关联系统和系统关键用户。邮件发送下述用户，并抄送产研团队。
表格33 上线通知用户范围模板
STEP2：列明本次发版是否影响使用，以及具体的发版时间。
例如：本次发版需要停站，预计在凌晨2：00-3：00完成发版，发版期间用户将无法登录系统。
STEP3：列明此发版的内容有哪些，注意，发版内容一定要以动词开头，语句简明（让业务方能够理解）。
表格34 发版内容举例模板
STEP4：添加问候语，留下产品团队的联系方式。
例如：Bestorder团队衷心祝愿各位工作顺利，如在发版后有任何疑问，请随时联系我们（邮箱：xxxxx@xxx.com）。
以上，我们就完成了一次发版通知。
B端产品经理为什么要重视上线检查清单？
正如我在这本书提到的其他清单一样，上线检查清单的基础功能是避免我们遗漏。不同于其他清单，上线检查清单的还直接作用于产品质量提升，通过上线检查清单，能够帮助我们及时发现BUG，减小影响范围。
需要强调一点，并不是所有的问题都可以在测试环境显现，不能把生产BUG全部归因到测试人员没有认真测试，或单纯的Coding问题。作为一个团队，产品和运维有责任参与到上线后的系统检查，提升产品质量。
如何进行上线检查?
STEP1：撰写上线检查清单。
如果是从0开始准备检查清单，可以请测试帮助，拿到测试的测试用例，在此基础上，区分主业务流程与本次发版内容，整理常态化检查清单和本次检查内容。
表格35 上线检查清单模板
STEP2：如果是24h作业的系统，一定要在发版后立即进行检查。
按照检查清单，等待生产环境出现对应场景的单据，如果有异常，则及时向开发进行反馈（具体层级可以参考11.2问题复盘），确认上线检查清单所有事项都被妥善关闭后，上线检查才能结束。
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》这本书。
B端产品经理为什么要重视问题复盘？
复盘是一种重要的工具，可以帮助产品经理从故障中总结经验教训，为后续思考产品设计提供参考。
如何进行问题复盘？
图片70 问题复盘流程
STEP1：在故障发生后的两天内，进行问题回顾。
完整的记录下故障的发生、发现、原因定位、决策、处理、预案执行、回滚、故障解决等的关键人与关键时间点。
STEP2：利用5W1H分析问题产生的Rootcause。
图片71 根因分析
STEP3：通过总结，进行故障定性、故障定责及总结本次故障带来的经验教训。
在进行故障定性时，要评估对业务带来的影响（可以用SQL提取影响单据的范围），确认损失及范围。
这样做的好处有：
STEP4：通过行动，落实故障的处理。
通过SMART法则，提出改进项目：
仅仅提出改进项目是不够的，接着我们要追溯改进项目：
1.首先，要明确相关改进项的负责人。
负责人可以有多个，但主要负责人有且只能有一个。即这个人需要对这个改进项的落地全权负责。当然，这个负责人的指定也需要在权责对等的基础之上。
2.定期回顾改进状态，规定好回顾时间，回顾后续改进项的状态如何？是在准备？进行中？还是完成？
在完成了改进项后，需要进行改项的关闭。
以上，我们就完成了问题的复盘。
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.
作者：再次拥抱富婆，公众号：富婆物流系统笔记
本文由 @再次拥抱富婆 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。