Categories
程式開發

每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下)


AfterShip 自 2012 年成立以來,每年業務都可實現 100% 的複合增長。對於這家公司來說,組建團隊是一件更重要的事情,並且尤為重視工程師團隊文化的建設,他們推崇團隊文化多元化及相互包容性,並要求團隊每個人都要懂產品以及客戶。

因此對於 AfterShip 來說,做好新員工培訓成為了一場重要的“戰役”。今天,AfterShip CTO & TGO 鯤鵬會會員洪小軍,及其 AfterShip 的廖國添將分享每年營收翻倍的全球化 SaaS 公司 AfterShip 是如何體系化地做新員工培訓的經驗。

快速發展階段的公司尋求快速、靈活和實用,AfterShip 新員工培訓從啟動到正式開始培訓,前後總共是 2 週時間,期望分享一下在這個過程中的思考和實踐。

為了幫助大家更好地了解培訓主線,我們將培訓整體內容分為了 6 個環節:

  • Day1:了解公司當前具體情況;
  • Day2:效率工具實戰;
  • Day3:基於 Scrum 的敏捷開發實踐;
  • Day4:項目實戰 – 系統設計;
  • Day5:項目實戰 – 流程和開發;
  • Day6:項目實戰 – 系統發布。

昨日,我們已經將《每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(上)》發布,錯過的小伙伴趕緊點擊鏈接閱讀吧。今天,我們來講述下篇的內容。以下,Enjoy:

Day3:基於 Scrum 的敏捷開發實踐

這個環節的關鍵目標是:

  • 理解基於 Scrum 的完整開發流程;
  • 理解公司和團隊的 OKR;
  • 理解產品需求和清楚如何進一步做分析。

這個環節由產品經理主導,產品經理將會為此針對性的設計業務需求,並寫成產品 PRD 文檔。

在開始環節,產品經理將與參會者一起探討產品需求,產品需求的探討是整個研發生命週期中非常關鍵的環節,AfterShip 提倡大家在深入理解產品需求後才繼續下一步的工作。

每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下) 1

AfterShip 的項目中採用 SCRUM 的方式運轉,兩週一個 Sprint 迭代周期,每個迭代周期會有以下幾個關鍵環節:

1、需求池管理:AfterShip 使用 Jira 做項目和任務管理,產品經理將業務需求按照 Story 的方式寫到 Jira Backlog 中,形成產品的需求池。任何人也可以在任何時候將需要做的事項寫入到 backlog 中,包括但不限於產品需求建議、客戶建議、Bug、技術改進事項等;

2、Grooming 會議:確定這個 Sprint 的交付目標,從 Backlog 中選取相應的 Story,按照適合的粒度拆解 Story,同時進一步分析評估工作量,當前 AfterShip 基於 Planitpoker 來做點數評估;

3、每日早會:每個團隊會有 10-15 分鐘的早會,每個人基於 Jira Board 簡要介紹上一個工作日所做事項,會議的重點是集中探討項目運轉過程中碰到的問題。 AfterShip 要求每個事項都要寫到 Jira 中,包括每個事項的進展情況需要及時 Comment,養成這樣的做事方式,也很利於跨區域的團隊溝通協作。前一段時間因為疫情的原因,公司全員遠程辦公,從結果來看,整體溝通成本不會差異太多;

4、Sprint Review:每個 Sprint 完成後,會召集所有相關的同事做一次 Sprint Review,包括技術支持團隊和售前團隊。 Sprint Review 主要演示過去一個 Sprint 中所做的事項,大家也可以提一些改進建議;

5、OKR Review:公司採用 OKR 的方式,每個 Sprint Review 的同時也會簡要對一下 OKR,以確定目標完成情況及其是否有碰到問題,確保整體朝著預定方向運轉。如果有發現目標變化,也會儘早識別並及時調整;

6、Retrospectives:Sprint Review 結束後項目組人員留下來做 Retrospectives。 AfterShip 使用 Funretro 來做這項工作,團隊的每個人會寫出過去一個 Sprint 中做得好及其需要改進的事項,包括團隊、項目及其任何方面。完成之後將進入投票環節,每個人有 6 個選票,最終選擇 2-3 個關鍵事項作為下一個 Sprint 要重點解決的,並寫成 Jira Ticket 來跟進確保目標達成。

在新員工培訓的這個環節中,產品經理會帶著大家來完整體驗這個過程,包括相關工具的使用演示。

每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下) 2

Day4:項目實戰 – 系統設計

這個環節的關鍵目標是:

  • 如何做整體性的設計;
  • 如何做 API 和 DB 設計。

AfterShip 有定義統一的系統架構設計模板,期望新開發的系統默認基於這個模板來做系統整體設計,在設計完成後會將先做一次設計方案 Review,確保在業務和技術目標上達成共識。

每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下) 3

AfterShip 對於系統部署的層次結構也有清晰的定義,附上一個簡化的版本:

每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下) 4

API 設計方面,AfterShip 在 API 設計上會有很明確的要求,需要很好的遵循 Restful 設計風格,並且語義定義上要足夠的清晰。

原因也很簡單,公司有可能隨時開放 API 給客戶使用,包括 API 也需要嚴格保持前後版本的兼容性,所以穩定的、語義清晰的 Restful 風格 API 尤其重要。

為此,公司也定義了專門和詳細的 API 設計 Guideline 供設計時參考和借鑒。 AfterShip 採用 Stoplight 來做 API 的管理,通過 Stoplight 也能做到更加高效的協作和溝通。

在這個環節裡,更多會去體現公司所提倡的產品和設計先行的理念,也會盡可能多的提供各方面的模板和 Guideline 去幫助大家去做好這項工作。

每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下) 5

Day5:項目實戰 – 流程和開發

這個環節的關鍵目標是:

  • 如何保證在研發流程上的更高效率;
  • 如何保證更高的質量;
  • 如何開發一款面向全球客戶的產品。

在開始這部分工作之前,每個人會先準備好一個 Demo 項目,能基於公司現有技術體系之上跑起來的 Demo 項目。

AfterShip 沒有設置單獨的測試崗位,但是也期望保持很高質量的系統交付,對於很多新人來說這是一道坎。要達到這樣的效果,需要在代碼規範、Code Review、單元測試和集成測試方面做細做好,基於此公司在 TDD 和 BDD 方面也做了大量的實踐和應用。

代碼分支管理和部署環境管理,同樣也是作為新人很關注的議題。 AfterShip 從環境層面來看,分成開發環境、測試環境、Release 環境、預上線環境和線上環境,通過不同域名的方式來區​​分不同的環境,這在內部溝通和協作方面也有明顯的好處。

開發一款面向全球客戶的產品,有很多事項需要特別注意,比如多語言、多時區和多貨幣等;在安全隱私保護方面,面向歐美國家需要研究清楚GDPR 和CCPA,包括AfterShip 已經通過的ISO 27001等的認證體系,也都需要嚴格遵循。

在這個環節中,重點期望大家能清楚有什麼潛在的注意事項及其痛點,包括了解相應的最佳實踐。

Day6:項目實戰 – 系統發布

這個環節的關鍵目標是:

  • 學習掌握發布流程及發布原則;
  • 學習掌握監控告警機制;
  • 學習掌握故障處理原則及流程。

AfterShip 使用一系列 SaaS 服務來快速搭建自動化的監控體系:

  • 使用 New Relic 作為 APM 和分佈式 Trace 系統;
  • 使用 Pingdom 做系統運行狀況的監測;
  • 使用 PagerDuty 做報警;
  • 使用 Grafana 在部分場景裡做報表展示和監控;
  • 使用 Statuspage.io 發布系統故障時的變更通知,以便客戶可以快速了解到信息。

基於這個體系還有個很大的好處是,互相之間可以做簡單和快速的集成,包括與公司所使用的 Slack、JIRA 等系統打通,能很方便的實現整體的自動化。

在此基礎上,AfterShip 也搭建了一系列配套服務來達到更加的自動化。

比如我們期望能有一個統一的地方去獲取到系統所有的發布變更通知,包括代碼層面變更,以及各類系統變更(比如數據庫、配置變更等)。

公司前端同事自發利用業餘時間開發了一套 Release 系統,Release 系統會匯總所有的變更信息,有統一的 Dashboard 展示所有變更信息,有新變更也會實時同步到 Slack(公司使用 Slack 作為通訊工具)。

Release 系統通過對接發布系統( AfterShip 主體使用 Jenkins )實現了自動化的錄入發布變更信息到系統中,系統同時也支持手工錄入的方式(比如數據庫變更)。

基於此,AfterShip 也定義了統一的 Release Log 格式。有了這套系統,當線上系統出現問題時,能比較方便的第一時間確定是否由於變更引起,對於問題排查能起到不少的幫助作用,畢竟變更是故障產生的關鍵影響因素之一。

每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下) 6

我們期望公司全方面盡量做到更加簡單和自動化,也很提倡大家朝著這個方向去努力。

對於構建高可用的系統,需要首先清楚有哪些方面的影響因素,進而針對性的去處理。

在此方面,AfterShip 也專門梳理總結了一系列 Checklist,比如對於系統設計階段、系統發布前和發布後需要注意哪些事項。期望幫助大家做好自檢,同時也不斷去提升大家在這方面的認知和能力。

以下為系統發布之前的 Checklist:

每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下) 7

以下為系統發布之後的 Checklist:

每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下) 8

公司也制定了故障管理制度,在故障處理方面,採用5-13 原則,期望至少在5 分鐘內感知到故障發生並且開始進行線上操作,需要能在13 分鐘內完成故障的處理和服務的恢復。

當然,這是考慮到各種場景之下的基線值,比如半夜收到報警快速的開機連接到系統等的場景。提倡先快速解決問題,不管使用什麼方式,擴容、回滾或者其他盡可能快的方式。

所有人都不期望故障的發生,但是故障很難完全避免。本著**“從故障中學習,不再犯第二次錯誤,盡量少出故障,出現故障儘早恢復”的原則,鼓勵團隊從故障中學習和成長,所以也設定故障獎罰機制。獎懲不是目的,而是期望未來能不斷做得更好。 **

公司會獎勵在工具建設和樂於助人等方面有突出表現的團隊和個人,同時也會基於故障制度會有一些懲罰機制,懲罰的方式為根據故障的級別不同去做不同工作量的工具系統建設,通過工具建設實現整體的更加自動化。

經驗總結基於以上內容,我做了一個簡單的經驗總結:

第一,新員工培訓從正式啟動立項到開始進行培訓,剛好也是在一個 Sprint 的時間內(2 週內)。這個過程也很辛苦各位組織者和講師,需要在日常工作之外去很好落實這個事情,這是1.0 的版本,快速發展階段的公司先做比起一開始就想做得很好重要很多,也期待接下來的2.0 和3.0 版本能做得更好。

第二,整個過程會需要耗費大家一定的時間精力,包括組織人員、講師和新同事的時間投入。因此,為了讓這個活動產生更直接和更大的價值,我們需要不斷地探索,並及時做一些適當的調整。比如這個活動裡,如何把所有環節有機連接起來,也是需要持續打磨好。

第三,WorkShop 的方式對於講師來說也是一個不小的挑戰,因為他不僅是一個分享者,更是一個引導者,他需要不斷地引導大家去思考和實踐。原計劃期望是所有的環節都基於WorkShop 的方式進行,但是在具體的執行過程中,也適當做了折中,我們也是推崇2-8 原則,先利用20% 的時間做好80% 的事情,後續可以再不斷迭代優化。

第四,參加者的反饋很重要。因此,我們會讓每位參與者提交反饋,讓組織者更清晰知道做得好和做得不好的地方,這樣在下一期的活動中才能加以改進,做得更好。

第五,在業務快速發展過程中的團隊,不僅需要權衡好業務發展和人員成長方面的平衡,而且要幫助現有業務快速發展,還要從中長期發展角度來做好成長體系。這時,難免會產生一定的衝突和挑戰,所以我們需要盡可能地維持平衡,這是非常重要的一點。

最後,以上每個環節的詳細介紹,基於篇幅的原因,主要以幾個關鍵點簡要說明,如果大家希望能有每個環節的詳細介紹文章,請留言或者點擊“在看”分享,讓我們了解大家對於內容的期待,也希望能有更多的機會與大家一起來更加深入的溝通和交流。

回顧以往洪小軍精彩文章:

我的移動互聯網十年經歷(一):飛信時期
我的移動互聯網十年經歷(二):新浪微博時期
我的移動互聯網十年經歷(三):美圖時期

特別提示

管理團隊還有很多方法,如果你想了解更多團隊的管理方式,與一線大咖面對面交流,找到提升自身領導力的方式。 7 月 17-18 日,2020 年 GTLC 全球技術領導力峰會·全球站(北京)將邀請 20+ 位大咖講師,為你現場解答。掃描下方二維碼,立即了解詳情! (PS.7 折優惠倒計時,最低折扣時期,等你來!)每年營收翻倍的 AfterShip 是如何體系化做新員工培訓(下) 9