知識星球有同學問了這樣一個問題：質量團隊組織業務串講，如何開展？如何梳理和演講業務需求？
很少見的一個好問題，也是很多測試團隊忽視的點。但恰恰是業務串講，其背後蘊含着深刻的邏輯，同時對測試團隊擁有巨大的好處。
在招聘環節，在其他條件類似的情況下，企業往往更青睞於那些有類似業務背景從業履歷的候選人，爲什麼呢？
因爲有類似的業務背景和從業履歷，入職後可以更快的熟悉當前公司和團隊所負責的業務需求，可以更快的參與到實際工作中，成爲開箱即用的即戰力。
從團隊管理的角度來說，團隊的組織模型往往是金字塔或者紡錘型，有人離職也有新人進來。老人往往對團隊的工作流程和業務需求比較熟悉，對潛在的風險也較爲熟稔。
而新人無論之前是否有對應的業務背景，剛入職總是需要一定時間來熟悉和適應團隊的工作流程及業務需求。
如果團隊沒有知識庫和業務沉澱，那在老人離職和新人入職這個交接階段，就容易出現gap，進而導致新人落地速度更慢且存在空白區域。
這個空白區域，可能是對應業務模塊的關聯業務細節，可能是過往的協作方式，也可能是潛在風險，更可能是需要跟進卻被忽略的。無論哪一點，都可能會成爲後續工作開展的不良因素。
這就是爲什麼要開展業務串講的原因，特別是對於測試團隊來說，這點更爲重要。
如何開展業務串講呢？從個人經驗來說，一般從如下幾個方面進行：
首先，定時由團隊的老員工在團隊內部就自己負責部分的業務需求/技術項目展開分享，其他同學特別是剛加入團隊不久的新同學參加，對團隊整體要面對的業務需求/技術項目有一個快速瞭解。
其次，新人入職後製定落地計劃，比如入職一個月後負責完成一個版本迭代中某塊需求的測試工作。然後就自己負責部分進行總結分享，其他同學負責完善補充，並給出後續的提升建議。
最後，定時(時間可以稍微長點)組織跨部門、跨業務線的串講，包括各自負責的業務需求、工作協作流程、技術實踐項目等內容。
邀請和自己所在團隊有直接協作關係或者上下游的兄弟團隊參與，溝通有無，降低各自工作範圍邊界的風險，進一步加強對彼此的瞭解。
其實業務串講的本質是一個信息傳遞和同步的過程，雖然說測試崗位是一個技術崗位，但技術只是勝任一個崗位的基本要求，要很好的完成工作任務，其實更重要的是協作配合，以及對各種工作信息的傳遞和處理。
分享一些業務串講行之有效的實踐方式，供大家參考。
- 團隊內部小規模串講，思維導圖的方式即可，不用太正式，清晰明瞭即可。
- 複雜和長鏈路的業務串講或者技術項目，建議通過流程圖/甘特圖/思維導圖等形式，並配上對應的文字說明。
- 業務串講的產出內容，建議通過在線文檔或者其他方式，進一步梳理完善，以知識庫的形式進行沉澱，便於新入職的新人更快落地，也便於其他協作團隊和兄弟部門有需要時可以參考。
構建知識庫的方式和工具很多，各種在線wiki，開源或者商用的都有，比如：PingCode Wiki、飛書文檔、Confluence。
構建知識庫時，有幾點需要注意：首先是權限管理；其次是梳理沉澱的習慣需要持續，最好流程化；最後一點是，不要陷入形式主義。