Categories
程式開發

團隊在高速擴張中的能力構建與質量保證


快速的人員擴張對我們來說是個幸福的煩惱,是一把雙刃劍:一方面要的人多了可以帶來更多的收入,但是另一方面,如何招人,如何培養人,如何避免新人出質量問題?如果質量問題頻繁發生,很可能丟失我們和客戶已經建立起來的信任。

ThoughtWorks合作的一個海外運輸行業客戶,希望在2019新財年,從原來的一個不到20人的小研發團隊在未來3個月內擴張到60多人,希望更快速的交付更多新功能,希望構建完善的人才梯隊,避免因為快速擴張而引髮質量問題、線上事故。

團隊在高速擴張中的能力構建與質量保證 1

圖:某團隊人員擴張曲線

總結來說,這個案例會系統化的介紹整個過程中的問題、挑戰和所收穫的經驗和教訓,包括如下三點:

  • 如何縮短新人的成熟時間、加快交付速率的同時保證質量、避免線上事故?
  • 如何構建良性團隊氛圍,減少知識的稀釋,形成合適的人才梯隊?
  • 如何從手把手的知識傳遞,變為自組織自學習團隊?

最終構一個安全有效的團隊快速擴張體系。

經過3個多月的努力,我們最終做到了客戶的要求,通過分析統計可以看到,2018年1月到6月嚴重的線上事故有4起,在新人員快速增長的下半年,7月到12月有5起,2019年上半年1月到6月1起,7月之後到現在還沒有發生,結果是好的,但是過程是曲折的。

團隊在高速擴張中的能力構建與質量保證 2

圖:線上事故統計分析

在這樣的背景和挑戰下,團隊是怎麼做到的呢? 總結來說主要包括下面四個方面:

團隊在高速擴張中的能力構建與質量保證 3

圖:案例核心要點

  • 快速人員成長
  • 線上事故回顧-報憂文化
  • 人才梯隊構建
  • 社區&自學習團隊

快速人員成長

在討論快速人員成長之前,讓我們回顧一下常規的新人成長方式,一般情況下我們會為新人指派一名有經驗的“師傅”,作為他/她的Onboarding夥伴,他們一起Pair結對編程,在日常工作中交換知識,學習並成長。新人的Onboarding速度,理解知識的速度,取決於師傅的技能,如果師傅擅長帶新人,則Onboarding掌握項目技能的時間大大縮短。

這非常類似於美國南北戰爭中槍支的製造過程。它依賴於工匠,有時製成的槍看起來不錯,但精準度卻很差,很難擊中目標,或者該槍看起來一般但精準度度很高,容易擊中目標,但是也有可能外觀和精準度都很差。因此,槍支的精準度和製造時間取決於工匠的手藝,這種情況與Onboarding過程中的“師傅”非常相似。眾所周知,在那場美國南北戰爭中,北方贏得了內戰,原因之一是他們開發了一種新的槍支生產方法,用標準化的零件來組裝槍支。

團隊在高速擴張中的能力構建與質量保證 4

圖:美國南北戰爭的槍支

在團隊開始人員成長的過程中,我們也在思考並實踐,是否可以從原來老帶新,依靠師傅手藝的方式,轉變成流程化的快速成長過程?加速新人成熟過程,並保證帶出來的人一定是項目可用的呢?

快速人員成長,團隊主要做了下面四個活動,以構建一個有規可循的新人快速成長流程:

  • CraftSkill Map,梳理完整的技術能力圖譜,可視化人員需要掌握的能力。
  • 制定Onboarding流程,各個階段的Homework家庭作業和檢查點。
  • 一致期望,新成員狀態看板,紅黃綠三狀態跟踪人員狀態,儘早發現風險並採取措。
  • Case by Case 針對性培訓,量身定制、認知轉變、技能轉換。

CraftSkill Map,項目能力圖譜。當一個新成員在加入項目的時候常常會問這個項目是乾什麼的?需要解決什麼問題?使用了那些技術棧?我該怎麼開始?所以非常有必要給新人一個可視化的能力圖譜,讓新人在一開始就對項目有一個全局的認識,做到我知道我還有很多不知道的內容。根據我們的實踐,我們把能力圖譜中知識點進行了分類: 紅色是主要大類,如: Back-End,Front-End,Business 等。淺綠色是大類下的小類,這些內容是Class room training, 是可以通過準備學習資料、比如: wiki page、homework,讓新人先自學,然後再根據問題來解答,以此進行學習。比如語言特性: Linq, Async/Await, Nulable Type 等。這好比製造槍管的過程,可以方便快速的流程話,人工干預少,驗收方便,槍管直不直,機器自動化一量就好,Class room training 裡的Homework unit test通過了就是通過了,沒通過就是沒通過。還有一類標記為粉紅色的內容是 Pair and day to day training,是需要有人協助在工作過程中進行知識導入和結對編程的,靠自學和問題解答效率不高,比如SOLID原則,Design Pattern等。這好比製造槍的撞針,需要初步組裝,師傅干預,幫助校驗和矯正。可以把能力圖譜打印出來貼在團隊的工作區域可以讓每位成員都可以看到。實踐證明團隊裡Class room training 比例越高,能節約的人工成本越高。

團隊在高速擴張中的能力構建與質量保證 5

圖:能力圖譜 第一版

CraftSkill Map 根據團隊不斷的運轉和實踐也在不斷的演進和迭代,下面這一版更加細化的梳理了項目需要的各項能力,更加直觀可視化的展示了項目需要的能力。

團隊在高速擴張中的能力構建與質量保證 6

圖:能力圖譜 第二版

除了能力圖譜,為團隊梳理一個完整的 Onboarding 流程,也非常重要,給新人一個清晰的Onboarding旅程。讓他/她進入項目的第一時刻就明白接下來的每個步驟都要做什麼。如下圖最左邊是新人加入項目的那天,最右邊是新人完成Onboarding,成為ProjectReady 的成員。他可以勝任項目的工作,根據任務評估,在中等時間花費下(不會太長時間,也不會太短),完成項目里中等難度的任務。比如一個中等難度的任務,團隊的評估是3個StoryPoints,大概花費3天時間,新人ProjectReady,可以獨立工作,領取這個任務,在3天內完成。

新人Onboarding的第一天會先和項目負責人,會談半個小時,新人了解項目大體情況和背景,項目了解新人的期望和訴求,如果項目有安全需求比如PCI,PII等要求,需要第一時間告知新人,開始學習並遵守。

第二站新人和項目的技術負責人進行半小時的會談,新人了解項目的技術棧和Highlevel架構設計,項目了解新人的技術背景,進行技術基礎和匹配度評估,並初步設定Onboarding的大致時間,一般是2周到4週,並指定新人的buddy(夥伴)。

Team組建的大小一般是1 pizza team 或者2 pizza team大小,人數不多一般是7到8人,在午飯的時候定1到2份pizza大家就能吃飽了。新人加入Team後,會在Team中找一位有經驗的人作為新人的buddy(夥伴),會在整個Onboarding過程中,在日常工作中提供需要的支持和幫助。

新人首先學習項目的業務和技術,一段時間後會把Team裡的這6到7個人召集起來,開一個45分鐘的Training showcase,新人介紹自己所學習的內容,Team成員幫助查缺補漏,整個環節是一個非常有效的回顧過程,幫助新人理解掌握知識。

之後根據項目情況,側重學習Front-End、Back-End或者QA的領域知識和技能,學習一段時間後,一樣也會做一次Training showcase。最後新人來到DevOps部分的學習,學習Path to production,明白自己的代碼提交後,是怎麼完成到Production的,如果出問題了怎麼Debug,怎麼修復上線。最後新人在buddy的支持下,領取任務,逐步開始獨立工作。

當新人成熟後,進行一段時間的開發交付工作後,對自己Onboarding階段側重的技術棧熟悉並精通後(比如: Front-End、Back-End或者QA),一般3個月或者6個月以後,就可以開始考慮讓有潛力和有興趣的團隊成員開始輪換到新的技術領域,比如Back-End換到Front-End等,以便打造全功能團隊。

團隊在高速擴張中的能力構建與質量保證 7

圖:入職流程

有了Onboarding的流程,還需要流程的里程碑和執行時間。讓流程執行的更有序和有效。根據我們的實踐,我們為0-3年工作經驗稍微少的新同事,制定了4週左右的Onboaring週期。每一周都有明確的里程碑。超過3年比較資深的同事,制定了2週左右的Onboarding週期,同樣每一周也都有明確的里程碑。不論是否資深,他們最終要達到的ProjectReady是一樣的,都可以領取任務,保質保量,獨立完成工作。

團隊在高速擴張中的能力構建與質量保證 8

圖:入職里程碑

新人開始Onboarding後首先會拿到一個所有資料的索引頁,所有資料都可以通過這個頁面找到,並鏈接到詳細內容頁,比如下圖詳細的業務介紹。在最開始的時候我們採用wiki文檔,讓新人通過閱讀wiki文檔了解業務,我們思考能不能再快一點,再高效一點。後來採用了視頻的方式,每個業務錄製背景介紹和系統演示視頻,每個大業務有3到4段視頻,每個視頻50分鐘左右,大家可以通過視頻更快速的了解業務。還能不能再快一點呢?後來我們又錄製了 podcast,純音頻的業務介紹,大家可以在上班或者下班回家的路上帶上耳機就可以學習業務知識了。下圖是Onboarding裡業務部分的Class room training資料。

團隊在高速擴張中的能力構建與質量保證 9

圖:業務學習資料

除了上面說的,視頻的資料。我們也準備了Homework家庭作業,Homework是Class room training 裡最重要的部分,如下圖,最右邊是為學習C#準備的,是一組Unit test,新人通過完成這些Unit test來學習C#。有時候新人進入項目,我們可能會給他/她一本書,讓他/她看書來學習。我們發現這種方法效率比較低,有沒有更快的方法呢?後來發現Unit test是一個非常好的途徑,把知識點全部轉化成Unit test,我們總共做了40多個Unit test覆蓋的常規的語言特性,比如:字符串的處理、浮點數的處理、文件的處理等。新人只要有一些編程經驗和常規面向對象的認知,即便之前沒接觸過C#,比如之前是擅長Java技術,通過完成Unit test,他/她也可以非常快的從當前的語言轉換到項目所需要的語言。根據我們的發現,這比讓他/他看書學習的效率要高很多,最快的用了4個小時就熟悉了C#語言。除了學習語言的Unit test,我們還有前端的學習資料:React Todo List作業,使用React Redux 做一個Todo List 的 WebApp,通過這個練習,新人可以很快的上手React框架。還有中間這一塊是Website開發知識,我們準備了一個在線書店的Website開發作業,新人可以通過完成這個Website,學習路由怎麼做、Session怎麼處理、Web request的整個生命週期,等等Website開發所需要的常規知識。

團隊在高速擴張中的能力構建與質量保證 10

圖:技術學習資料

除了常規知識的Homework。我們還定制了一套基於項目的Homework,由於項目的技術棧是基於一個SOA服務的,所有的數據查詢、提交、存儲操作都不需要直接對數據庫進行訪問,而需要通過調用這個SOA服務所提供的DSL來實現。為了讓新人學習理解這一套SOA服務和DSL。我們真對性的準備了一套Homework,這套Homework在項目實際代碼倉庫下的一個分支裡,根據項目的一個真實功能而改編。新人通過在這個分支上工作,完成這個功能來學習這套SOA服務框架和DSL。當新人Checkout到這個分支,可以看到左邊是這個Homework的背景介紹和所需要學習的知識點。右邊的是我們已經準備了12個Homework需要寫代碼的地方,每個地方有詳細的註釋,比如圖裡這個例子,新人需要在這裡加一個ViewModel,把數據從request接進來,根據註釋和學習資料進行學習,當完成學習後,掌握ViewModel這個知識點。我們總共設計了12個點,搜索#homework,就可以找到這12個點,學習並完成這12個點後,就基本可以掌握最常規的80% 的知識點了,至此新人完全可以開始獨立在這個框架下工作了。

團隊在高速擴張中的能力構建與質量保證 11

圖:項目框架學習資料

新人狀態看板,由於同一時間上新人的數量比較大,我們希望減低上新人的風險,希望每位新人最終經過兩周到四周後,都能達到ProjectReady的程度。所以我們採用了新人狀態看板來監控每個新人的狀態。

前面提過,我們會為每一個新人指派一名Buddy(夥伴),Buddy會和新人工作在一個team裡。 Buddy一般會選工作經驗比較久,在項目裡時間比較長的老人。 Buddy會為新人提供在Onboarding過程中所有的幫助和支持。

在開始大規模上新人的時候,每週會在周三和周五的時候把所有Buddy都叫到一個會議室裡。 Buddy需要更新自己所帶新人的狀態,是紅、黃、還是綠?綠的含義是:自己所帶的這個新人,從當前的實踐來看,按照預期到ProjectReady是沒有風險的。黃的含義是:有一定風險,需要針對性的製定一些Action行動,降低或消除這個風險,讓新人最終能在規定的時間內ProductReady。紅色的含義是:所帶的這個新人可能已經out of the control,風險已經不在自己能力的控制範圍內了,可能需要公司的People team或者HR team一同介入,了解一下這個人當前的狀態,是否需要一些外界的幫助?一起制定接下來的幫助或者行動Action,或者根據他/她的意願進行調換,可能到別的更適合的項目去。

團隊在高速擴張中的能力構建與質量保證 12

圖:新人狀態看板

經驗教訓,經過這三個月到六個月的大規模上新人的時期,我們回顧了一下在這個過程中的經驗教訓:

  • 總共加入55位新成員,4位未通過Onboarding流程,被淘汰。有人沒有通過Onboarding流程被淘汰。被換到別的項目,或沒有過試用期離開公司。我們覺得55新成員,4位未通過,這是一個比較正常的比例。
  • 新成員明確知道 “Project Ready” 到底需要什麼,完成賦能,開始獨立交付工作。在新人進入項目的那一天,我們就幫他/她介紹了項目,說明了下面的Onboarding流程,什麼是ProjectReady,同時也為他/她指定了一路同行的Buddy。以便更好的明確ProjectRead,保質保量完成Onboarding的整個旅程,最終開始獨立工作。
  • 自組織,自驅動,自迭代的 Onboarding 賦能過程。我們的 CraftSkill Map,Homework,等都是在Onboarding的過程中不斷地迭代,不斷地改進行成的。
  • 形成人員快速成長標準流程,加速新成員成長。再回到當初的那個問題。是否可以從原來老帶新,依靠師傅手藝的方式,轉變成流程化的快速成才過程?加速新人成熟過程?經過前面的不斷摸索,我們基本上找到了一個流程,能解放一部分老人帶新人所花費的時間。

我們抽取了一些數據,想分析一下,看看這個Onboarding流程,到底有沒有加速新人上項目時間?如下圖左邊,我們抽取了相似背景的新人,比如都是三年左右工作經驗,都在Onboarding過程中是黃色,出現風險的。或者都是五年左右工作經驗,Onboading過程是綠色,沒有風險的。統計數據如下圖右邊,可以看到Onboarding流程,縮短了新人上項目的時間。但是我們也發現了一個有意思的情況,新人的工作經驗大於七年的這幾位新成員,Onboarding流程基本沒怎麼加速,和一對一,老人帶新人的方式,沒有什麼提升,上項目的時間都非常快。主要是一些工作經驗少的人,Onboarding流程可以加速他們上項目,到ProjectReady的時間。也就是說,新人的資歷越淺Onboarding流程所起到的作用會越大一些。

團隊在高速擴張中的能力構建與質量保證 13

圖:入職情況分析總結

現在我們也還在不斷的優化這個Onboarding流程,讓它更快,在小於四周的時間內完成。

線上事故回顧-報憂文化

線上事故回顧-報憂文化,也是團隊在高速擴張中的能力構建與質量保證的一個非常重要的部分。報憂文化其實是我們從Google學到的。 Google有一個專門講報憂文化的網頁。就是下面截圖的內容。 Postmortem culture。直接翻譯成中文是驗屍文化。 Learning from failure 從失敗中進行學習。 The cost of failure is a education。失敗的代價也是一次教學。我們將其轉換為自己的“Good news and bad news”文化。項目的負責人在跟大家開全員大會的時候,很多時候只說好消息,比如說:我們又贏得了新的客戶,銷售額又增長了。但是很少說不好的消息。 Google的實踐是,對失敗(線上事故)學習(驗屍)並在全員大會的時候公開給大家,不是只說好消息,同時也說不好都消息,比如:我們的某個服務又宕機了1小時,損失了多少收入,供大家學習和反思,避免再次發生。

團隊在高速擴張中的能力構建與質量保證 14

圖:報憂文化

我們在自己的項目上也總結了線上事故回顧模板。例如下圖,回顧總結事故的Summary、Impact、 Rout cause、Trigger、Resolution、Detection、Action items 後續行動,通過這些行動以便阻止這類事故的再次發生,或者緩解這類事故發生的機率。 Lessons and Learned 事故的教訓,在整個事故中做的好的,做的不好的?在這次事故中比較幸運的事情,最後是整個事故的時間軸。每個線上事故都會這樣總結,並分享給全項目組。

團隊在高速擴張中的能力構建與質量保證 15

圖:線上事故回顧模板

線上事故回顧-報憂文化,總結有下面幾方面的好處。

  • Lessons and Learned、Timeline、增強Log、後續Actions、實施效果。
  • 提升功能測試覆蓋率,增強質量保障。
  • One Team 線上事故實戰經驗分享,增進團隊融合。

如下圖,經過三個月到六個月的努力,我們最終做到了客戶的要求,通過分析統計可以看到,2018年1月到6月嚴重的線上事故有4起,在人員快速增長的下半年,7月到12月有5起,2019年上半年1月到6月1起,7月之後到現在還沒有發生。

團隊在高速擴張中的能力構建與質量保證 16

圖:線上事故統計分析

同時這也是現在業界比較流行的度量團隊效能的一個維度,從2019 DevOps 4 Matrix 來看 Change failure rate 和線上事故的發生率非常一致,也是一個很好的度量團隊效能的維度。即便是沒有在大規模上新人的時期,也可以實踐一下線上事故回顧-報憂文化,度量並改進一下項目的Change failure rate.

團隊在高速擴張中的能力構建與質量保證 17

圖:DevOps 4個關鍵指標

人才梯隊構建

為了防止項目新人過多所帶來的文化稀釋,知識稀釋。人才梯隊建設是非常有必要的。才梯度構建主要包括下面三個方面:

  • 可視化人才梯隊看板。 PM/TL、SecondTire、KeyContributor、Others、Risk
  • 每季度基於Facts的Review,進行梯隊調整。
  • 梳理人員提升Actions、幫助團隊成員提升。

團隊在高速擴張中的能力構建與質量保證 18

圖:人才梯度看板

如上圖人才看板。人才看板,把團隊裡的人分為了五個階段:PM/TL、SecondTire、KeyContributor、Others、Risk。 PM/TL:項目負責人/技術負責人。 SecondTire: 很有潛力成為項目負責人/技術負責人的第二梯隊。 KeyContributor:項目主要貢獻者。 Others:一般人員。 Risk:有風險人員。同時每個階段裡再分為:Well done 完全準備好了,找機會隨時進入下一個階段。 Medium 中等,還需要鍛煉。 Medium Rate 剛剛進入這個階段,還需要不少鍛煉。

我們分為主要的五個維度進行打分和度量,以評估團隊成員現在所處哪個階段。這五個維度是? Contribution、Customer focus、Skill、Impact、Develop Others. 由於我們項目的工作性質,工作內容。我們定義了這五個維度,當然你可以根據你的項目,你的工作,按照你的需求,來定義適合你項目所需要和關注的維度(可參考StrengthsFinder 2.0來設計你自己需要關注的維度) 。

每個季度,我們會根據每位成員在項目裡所做的工作,發生的事實,按照這五個維度進行打分,區分團隊成員所在的階段和分維度打分只是一個方法,最重要的目標是幫助團隊成員提升,讓他/她們發展自己,遇到更好的自己。所以對於review回顧最重要的是提出改善意見,希望團隊成員不斷的在人才看板上向前移動,最後成為項目的主要負責人/技術負責人,可以自己去開啟並負責一個新項目。

社區&自學習團隊

社區,自學習,是激活團隊氛圍,形成良性知識分享土壤的有效實踐。社區&自學習團隊,主要包括對內對外下面兩點:

  • 內部形成技術Chapter, 構建規律的技術分享活動。
  • 外部打開眼界,關注行業,融入社區,從參與者到講師、激活團隊氛圍、形成良性循環。

團隊在高速擴張中的能力構建與質量保證 19

圖:ING’s New Agile Organizational Model Has No Fixed Structure—It Constantly Evolves. (Source ING)

上圖是現在比較流行的一個項目團隊的組織結構圖。這個豎向的,黃色的Squad,其實就是我們的1 pizza team, 一個全功能團隊。多個這種全功能型團隊就組成了整個項目團隊,就是這裡畫的Tribe。 Chapter是這個橫的藍色的框框。我們需要構建這樣的Chapter。比如說一個項目上,所有的前端人員組成一個Chapter,所有的後端人員組成一個Chapter,所有的QA人員組成一個Chapter。讓各個Chapter內部進行分享。比如在後端Chapter裡一起分享項目在後端上有哪些可以一起改進的東西/技術債,有哪些通用的東西,可能是某個team已經踩了坑,完全可以把經驗分享給別的team。我們的項目是有一個固定的時間,每週二、週三下午4點到5點,一個小時,每週兩次,大家報名議題,來進行分享。前端是每天有半小時一起的code diff,所有前端一起進行交流。 QA也是每周有碰頭和分享。與此同時,項目上Onboarding的後端、前端、QA的Homework也是由各個Chapter來牽頭迭代改進的。

除了關注項目內所發生的事情,同時我們也應打開眼界,關注行業裡都發生了什麼,需要融入社區,這是一個非常好的激活團隊的辦法,希望團隊藉此形成一個良性的知識分享循環。參加外部的社區,學習外部不同的技術和經驗,同時帶回到項目中來,結合項目的工作,找到一個合適的地方去使用這些新技術,同時結合業務需求,形成有商業價值的功能。我們希望產生這樣的化學效果,比如前端同事去參加外部活動,發現AMP、PWA其實可以結合項目上的一些需求,做一些東西來更好的服務用戶。比如後端同事去參加社區活動,發現了一些新的性能調優的思路和工具,帶回到項目來優化性能。 QA同事參加社區活動,發現契約測試對項目是有幫助的,開始在一些測試方法上進行改進。

團隊在高速擴張中的能力構建與質量保證 20

圖:活躍的社區

因為參與社區,有同事被Google作為社區優秀講師,邀請到美國現場參加一年一度的Google I/O。我也被邀請參加了Google GDG社區組織者東北亞峰會,一同討論如何構建更好的社區。參加社區的同事反饋說:有人從不喜歡社交social交談,變得更加自信和善談。有人開始喜歡上寫Blog做知識分享了。有人從聽別人講,嘗試自己開始內部小範圍講Session,然後到社區大範圍演講。

回顧-投入產出

  • 不斷完善的Onboarding流程,順利完成了團隊的高速、高質量擴張,避免了風險,提升了效率。
  • 總計加入55位新成員,4位未通過Onboarding流程,被淘汰。
  • 從1對1的老帶新的方式,演變為自組織自驅動體系,大大節約了時間成本。
  • 構建人才梯隊,防止知識稀釋,並沒有因為團隊快速擴張,而產生額外的線上事故。

回顧-啟示

最後,希望在這個議題裡,可以有讓大家有Take away帶回去的東西。我總結了三點:

  • 當需要快速完成新成員能力構建的時候?可以採用CraftSkill Map,Onboarding 流程,新人狀態看板。
  • 當需要係統化的進行人才梯隊構建,防止知識稀釋的時候?可以採用人才看板,報憂文。
  • 當需要激活團隊氛圍,形成良性知識分享土壤的時候?可以採用內部Chapter賦能,外部打開眼界,加入社區。

作者介紹

張思楚,ThoughtWorks Technical Principal

本文轉載自公眾號ThoughtWorks洞見(ID:TW-Insights)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MjM5MjY3OTgwMA==&mid=2652467973&idx=1&sn=716003ae82af562d3a6451d0ac805034&chksm=bd4f41128a38c8043c05e8cef74218c6aceedb00f3adc335982bff16eeab48201165d01c2618&scene=27#wechat_redirect