這是鼎叔的第一百零七篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本公眾號《敏捷測試轉型》，星標收藏，大量原創思考文章陸續推出。本人新書《無測試組織 - 測試團隊的敏捷轉型》已出版（機械工業出版社），https://item.jd.com/14105386.html。
研發度量和 QA
研發的度量，不應該是基於績效處罰，阻礙創新，而是應該幫助團隊自我改進，這需要各個關鍵角色的自發推動和積極支援。本專輯會先從傳統度量的侷限性開始剖析，重點闡述如何基於敏捷設計度量指標，讓過程改進（質量管理）的工作更加適應敏捷研發，並藉助敏捷度量體系高效推動團隊的健康運作。
在傳統技術行業，質量管理是一個專業的獨立角色，它代表管理層，起到了重要的過程量化和紀律督促作用。但是在敏捷研發時代，專職的質量管理人員，經常走到了研發效能的對立面，儘管做得很辛苦，但頻頻被吐槽，缺乏成就感。
一線質量管理者，在很多公司簡稱為過程改進工程師（PI）,也有很多公司稱之為 PQA（質量保障工程師）。然而還有很多企業把測試工程師也統一稱為 QA， 本文內容中 QA 特指不進行測試技術實施的過程改進人員（或質量管理人員）。質量管理工程師和測試技術工程師，本質上都屬於質量角色，甚至可能是同一個團隊來負責的。
先從 QA 的鬱悶說起
在研發規模比較龐大的組織中，專職 QA 通常承擔了下列重要工作內容：
向技術高管彙報當期主要質量風險、質量資料趨勢、質量改進措施的進展。
針對線上事故組織回溯，落實整改措施。宣導事故定級或紀律審計措施，公佈獎懲結果。
年度質量規劃，確認質量改進專題和落地到業務的責任人，確認考核指標，組織相應主題培訓或部門宣導。
推動質量過程關鍵指標的量化和定期晾曬，對於告警資料提醒處理。
鼎叔曾經長時間從事過 QA 工作以及 QA 組的組建，也和行業中各知名公司的 QA 有過深入交流。在敏捷轉型大潮下，感覺 QA 的職業發展道路是容易迷失的，從業者普遍缺乏價值成就感，想招到一個滿意的懂敏捷的 QA 非常困難。
具體表現在以下幾個困惑：
1. QA 到底向誰負責？
QA 應該對技術高管負責，還是對一線團隊負責？
很多情況下，QA 被高管招聘進來，老闆的期望是 QA 能夠透過研發效率和質量資料的分析，及時暴露一線團隊的風險短板，找到可以立即改進的切入點。同時能夠建立上行下效的質量規範，定期自省。
但是，QA 的日常工作模式是和一線成員溝通，甚至深入到團隊的關鍵會議中，分析問題案例並向上彙報。
一線團隊出於本能是不希望暴露失誤被高管批評的。而 QA 因人力非常有限（因為不承擔具體技術實現工作，團隊預算通常很少），不能緊跟一線專案，不太可能提前給出具體的預警建議，幫助團隊儘早規避風險。與此同時，QA 因為要提取考核資料和保障彙報材料的準確性，還會讓一線團隊投入一定的人力支援。
時間一長，一線團隊對 QA 的負面看法就會愈發明顯，他們不能從支援工作中受益，還容易被高管批評（有時甚至是被背鍋），因此對 QA 的支援和評價就會逐步走低。
另一個維度，如果 QA 把主要精力投入到團隊協同支援上，重視團隊感受，那在高管眼裡，可能就形成 “質量規劃和呈現能力不足”、“不能暴露尖銳問題” 的看法。
2. QA 的成果是促進了敏捷，還是阻礙了敏捷？
QA 各項推動成果最終會固化下來，透過監控指標體系、規範流程梳理、內部審計等方式，所謂 “沒有規矩，不能成方圓”。成果越宏大，度量管理成本越高。
團隊會因此產生什麼變化麼？是真正降低了運營風險，還是研發氛圍更保守，交付更低速了？
很多時候，員工評價是後者，運營事故還是會不斷頻發，但是團隊為了質量規範達標，投入了相當多的 “額外精力”。
以我經歷的一個敏捷專案轉型為例，某研發團隊自發啟動敏捷變革（包含專業的 DevOps 平臺建設），高管提出 QA 能加入協助，於是 QA 組就主導輸出了一系列的效能度量標準要求（非常龐大的指標體系，超過 50 項度量要求），強力推動該研發團隊去落實。這本身就違反了敏捷原則，敏捷轉型應該是團隊自組織的，內驅改進現有問題，讓交付更順暢，讓自己更爽，而不是為了向高管彙報龐雜的標準化成果。這種規則強加式的安排，很容易引發研發團隊的反感，最終影響轉型目標的達成。
3. QA 的工作，是否可以由自動化平臺替代？
強調技術驅動的團隊，希望所有的過程質量和可預警的風險，都能夠透過工具平臺自動化的呈現和推動，這樣效率確實是很高的。但是 QA 在策劃和彙報的質量體系各個要素，不一定都能自動化的獲取，原因是有些要素需要主觀綜合判斷，而有些要素需要人工錄入後設資料，為了達成向上彙報的要求，研發需要投入相當的人員精力，以滿足質量分析的 “準確”。
在這個越來越強調自動化質量治理的時代，QA 人員對自身職業發展也產生了擔憂。研發人員自主完善質量監控自動化，顯然是更高效的，不需要諮詢所謂 “質量督導” 角色，除非，QA 人員有非常深厚的軟體工程量化能力。
4. QA 為啥經常成為流程中尷尬的二傳手角色？
團隊很容易預設 QA 是規範流程的協調製定者和守護者，所以一旦引入了新的流程環節，就習慣把 QA 納入流程把關環節。QA 莫名其妙成為了流程中的審批者，卻起不了特別價值。
實際上，QA 人數通常非常少，不可能深入到每個專案的研發測試過程中，不具備對具體需求的質量風險判斷力。強行放入一個把關角色反而會成為流程的瓶頸，導致拖沓。
優秀 QA 應該能制定出能夠充分防範風險，同時讓成本儘量低（簡潔）的共識流程，同時自己要能脫離其中，參與到下一類急需改進的任務。
所以，鼎叔認為優秀的 QA 應該成長為一個專家教練角色，而非流程角色。TA 應該敏銳識別可改進的地方，藉助資料分析和大家的反饋，明確能夠馬上改進的 TOP N 措施，一旦措施落實（形成團隊習慣）後，QA 應該抽身而退，瞄準下一個目標。
團隊為什麼討厭被度量
理解了團隊為什麼討厭被度量，也就理解了 QA 工作的難處。
老闆要求產研度量，本意肯定是提高交付效能，提升公司的市場競爭力，無可厚非。當 QA 和敏捷專家吭哧吭哧丟擲一個度量方案，總會收穫一些質疑聲。深入剖析這些質疑聲，我們就能知道 QA 在工作推進中要特別小心什麼。
質疑一：各個團隊看到了度量資料，很容易內捲起來，有何意義？
未來我們還會具體解讀，敏捷實踐中如何避免內卷。
發生低價值的內卷場景，往往因為管理者只看純指標，不看背後的具體做法。指標為什麼提升，以及是否保持提升，比 “提升了多少” 更有意義！
所以，度量不能唯結果論。QA 更多的精力要用來關注原因、可持續性、可複製性。
質疑二：一線 leader 懶政怎麼辦，把指標壓力傳遞給員工。
首先，之前文章聊聊研發效能建設的痛點說過，效能度量不要關聯績效！不要關聯績效！
只要關聯績效，或者暗示會影響績效，員工的動作就會變形。
對於容易引起這種誤解的指標，建議 leader 先自行分析，核實原因，再和員工對齊靠譜的改進手段。
當團隊對該指標已經形成日常的健康應對習慣，再完全透明化不遲。
質疑三：你拿出的度量指標和措施報告，對我們團隊真的適用麼？
這個質疑也是人之常情，度量指標有可能來自其他公司，甚至其他行業，是否一定適用於當下呢？
這也很考驗 QA 的分階段落地能力。
理論上來說，研發效能痛點是高度相似的，不同公司的研發痛點相似度遠遠大於業務痛點相似度。所以，大機率上，好的措施也是跨公司通用的。
但是員工的工程水平、工作壓力、信任度、興奮度不同，QA 推進方案時也不能一刀切。應該聚焦大家最痛的指標，最願意接納的幾個措施（不超過 3 個）來行動。
當 QA 組織輸出第一份正式度量報告時，尤其要小心核實，有些指標可能是誤報，如工具統計口徑沒有對齊，欄位填寫規則沒有對齊，或者團隊發生了眾所周知的特殊情況。
就算指標資料沒錯，我們分析原因和改進建議也不能想當然，最好和當事人訪談，確認下真實的原因（GO-SEE）。充分考慮業務差異、團隊差異帶來的指標差距。
如果初期釋出的報告和員工感知大相徑庭，會給後面的工作帶來負面影響。
質疑四：研發過程中，填寫各種質效相關欄位很煩躁。
本質上，這是研發管理平臺的產品流程設計（易用性）問題，需要專業思考和跨角色碰撞，後面有機會詳細展開。
這裡簡單說一句：讓一線團隊先理解背後的原因，再在日常活動中順手填寫或自動填寫預設值，欄位設計應該遵循金字塔原理，簡潔、正交、不重疊不遺漏。透過使用者可用性調研，儘可能做到填寫成本最低。
傳統質量觀 VS 敏捷質量觀
在敏捷研發時代，QA 同學會有這麼多的鬱悶和自我懷疑，本質上還是因為質量組織和質量觀發生了顯著的變化。
傳統行業的質量管理源自 20 世紀初的泰勒科學管理理論，在當年這是提高生產效率的有效手段。它強調管理者事先做好計劃，建立明確的量化的工作規範，開創了精細化管理的先河。傳統行業會把質量控制作為一個獨立於業務生產的關鍵部門，它和生產及銷售同等重要，質量部門把計劃和執行分離，對執行動作不規範的部門及人員進行偏懲罰性的糾正，因此質量人員普遍讓人感覺缺乏建設性，“和生產人員不是一夥的”。
與之對應，敏捷研發的質量觀，推崇的是精益生產的質量管理模式，借鑑豐田公司的 TPS（豐田生產製度）精髓，其本質是：沒有單獨的質量組織，整個組織就是質量組織。每個人都要為整個生產線負責，一旦發生問題就要 “拉繩” 把流水線停下來，檢查質量問題，立即改進。軟體持續交付流水線就是參考這種模式。
嚴格管控規範的傳統質量管理，對比敏捷精益的質量管理模式，體現在軟體研發的質量文化上，體現在過程改進工程師的工作導向上，會有什麼鮮明的不同呢？
後面我們詳細聊聊。