为什么要开展业务串讲？

知识星球有同学问了这样一个问题：质量团队组织业务串讲，如何开展？如何梳理和演讲业务需求？

很少见的一个好问题，也是很多测试团队忽视的点。但恰恰是业务串讲，其背后蕴含着深刻的逻辑，同时对测试团队拥有巨大的好处。

在招聘环节，在其他条件类似的情况下，企业往往更青睐于那些有类似业务背景从业履历的候选人，为什么呢？因为有类似的业务背景和从业履历，入职后可以更快的熟悉当前公司和团队所负责的业务需求，可以更快的参与到实际工作中，成为开箱即用的即战力。

从团队管理的角度来说，团队的组织模型往往是金字塔或者纺锤型，有人离职也有新人进来。老人往往对团队的工作流程和业务需求比较熟悉，对潜在的风险也较为熟稔。而新人无论之前是否有对应的业务背景，刚入职总是需要一定时间来熟悉和适应团队的工作流程及业务需求。

如果团队没有知识库和业务沉淀，那在老人离职和新人入职这个交接阶段，就容易出现 gap，进而导致新人落地速度更慢且存在空白区域。这个空白区域，可能是对应业务模块的关联业务细节，可能是过往的协作方式，也可能是潜在风险，更可能是需要跟进却被忽略的。无论哪一点，都可能会成为后续工作开展的不良因素。

这就是为什么要开展业务串讲的原因，特别是对于测试团队来说，这点更为重要。

如何开展业务串讲呢？从个人经验来说，一般从如下几个方面进行：

首先，定时由团队的老员工在团队内部就自己负责部分的业务需求/技术项目展开分享，其他同学特别是刚加入团队不久的新同学参加，对团队整体要面对的业务需求/技术项目有一个快速了解。

其次，新人入职后制定落地计划，比如入职一个月后负责完成一个版本迭代中某块需求的测试工作。然后就自己负责部分进行总结分享，其他同学负责完善补充，并给出后续的提升建议。

最后，定时(时间可以稍微长点)组织跨部门、跨业务线的串讲，包括各自负责的业务需求、工作协作流程、技术实践项目等内容。邀请和自己所在团队有直接协作关系或者上下游的兄弟团队参与，沟通有无，降低各自工作范围边界的风险，进一步加强对彼此的了解。

其实业务串讲的本质是一个信息传递和同步的过程，虽然说测试岗位是一个技术岗位，但技术只是胜任一个岗位的基本要求，要很好的完成工作任务，其实更重要的是协作配合，以及对各种工作信息的传递和处理。

分享一些业务串讲行之有效的实践方式，供大家参考。

• 团队内部小规模串讲，思维导图的方式即可，不用太正式，清晰明了即可。

• 复杂和长链路的业务串讲或者技术项目，建议通过流程图/甘特图/思维导图等形式，并配上对应的文字说明。

• 业务串讲的产出内容，建议通过在线文档或者其他方式，进一步梳理完善，以知识库的形式进行沉淀，便于新入职的新人更快落地，也便于其他协作团队和兄弟部门有需要时可以参考。

构建知识库的方式和工具很多，各种在线 wiki，开源或者商用的都有，比如：PingCode Wiki、飞书文档、Confluence。

构建知识库时，有几点需要注意：首先是权限管理；其次是梳理沉淀的习惯需要持续，最好流程化；最后一点是，不要陷入形式主义。