Culture
(圖片來源︰Scott Beale)

前言

首先要和大家說聲抱歉的是,原本上集 po 出時,說再過一週就會 po 出下集,但後來就......,總之不管有什麼原因,我還是拖稿了真是不好意思啊。這一週總算是克服了小弟的惰性,把下集給翻譯完成了,希望對各位朋友們有所幫助 (但我想大家應該早就去找原文,把下半部給看完了吧 XD)。一樣有任何翻譯上的謬誤都歡迎提出喔!

翻譯正文

六、建立程式碼共有的環境 (Build shared ownership of code)

當團隊中的每個成員,對於程式庫基底(code base) 或基礎建設(infrastructure) 中的方方面面都越來越了解時,那麼自然就不會有人覺得,自己是這些程式的擁有人或唯一維護者(solo maintainer)。讓團隊成員在一兩年內,只負責特定領域(的程式或模組) 並成為該領域的專家,在短期內可能會提昇工作效率;但長期來說,這樣的配置會傷害到團隊。

以組織面來說,共享程式碼所有權的作法,提供了三個好處。第一,可以維持「巴士因子」 (bus factor) [18] 大於 1,來減少維護者的壓力,並減少程式維護者離職的風險 (譯註︰因為這時候就沒有其他人改得動這模組,或是要重新上手需要花費不少時間)。(巴士因子為 = 1) 也使得團隊成員很難放一個無憂無慮 (worry-free) 的假。我真的不會想念當我還在 Ooyala 工作時,我人放假在夏威夷爬火山,卻還收到呼叫器傳來的簡訊,只因為我是系統日誌處理程式(logs processor) 唯一維護者的那段歲月。

(針對 buf factor 的譯註︰直白的來說,指的是以前目前團隊成員的分工和配置來看,當有多少人不幸被巴士撞死時,這個程式/模組就會變成無法開發/維護下去。一般使用這個因子來評估專案/程式的 know-how 是否過度集中、依賴在某些人上面。有興趣的朋友可以閱讀下面相關文章︰巴士指数(Bus Count)死亡無所懼——但請處理好你的「巴士因子」)

第二,共享程式碼的所有權,使得工程師不會在特定領域牽扯太深,以致於無法提供新鮮的想法,它將工程師從被綁死在特定類型專案的泥沼中解放出來 (譯註︰因為 know-how 發散,所以不同成員間可以互為替補。關於這點,有興趣的朋友也可以閱讀 Teddy 大大的好文︰Shared Code:讓我們變成博格人吧),並鼓勵他們從事多樣性的專案,這種做法也可以維持工程師的熱情,並啟發他們的學習動機。從長期來看,這種方式也會降低團隊中的工程師們,因為覺得無法成長而想離職的風險。[19]

第三,共享程式碼的所有權,也會建立一個讓多個團隊成員可以共同協作 (swarm together) (源自於敏捷開發的技術) 來解決高優先權問題的基礎,尤其是當你們需要更快速完成一個策略性目標 (strategic goal) 的時候。當程式碼的所有權很侷限的時候,(解決問題的) 負擔很容易就會集中落在特地的一或兩個人身上。

許多工程團隊常會犯的一個錯誤就是,在團隊還不大的時候,過早將整個團隊切割成一群有技術領導者 (tech leads) 的小團隊(subteams)。每個小團隊都會建立屬於自己團隊(程式)所有權的一道牆,而每個成員也會缺少跨越這道牆的動機,因為每位成員的績效評估依據,都是源自於他們自己所屬小團隊中的目標。

當我還在 Ooyala 工作時,Ooyala 中也是採用這樣小團隊的配置,而也因此我錯過了和其他團隊的夥伴們一起共事的機會。我那時候所聽到的是,他們已經因為採用了敏捷開發流程,專注於程式碼的所有權的共享,所以大幅度的提高了他們在工作上的生產力和滿意度。

而從另一個層面來看,我喜歡在 Quora 工作的原因,是我們強調專案(完成)的重要性要大於團隊(的分際),因此我有機會可以參與許多不同類型的專案,範圍從用戶成長 (user growth)、機器學習、協調工具 (moderation tools)、推薦系統、分析、站台速度調效 (site speed) 到廣告留言偵測 (spam detection) 等領域都有涉獵。

七、投資於自動化測試 (Invest in automated testing.)

(追求) 單元測試覆蓋率和某種程度的整合測試覆蓋率,是唯一一種具有延展性的的方式,可用來管理大型程式庫基底、大群的工程師,而不用定期打斷軟體建置。

自動化測試可以在進行大規模重構以改善程式碼品質前,帶給我們自信和有意義的保護。在缺乏精密的自動測試的情形下,手動測試所需要的時間 - 不論是由工程團隊自己或是委由外包的測試團隊來進行 - 都很容易使團隊難以負荷。而且這種情況,也很容易造成一種畏懼修改程式碼的團隊文化,因為害怕不小心改壞了什麼東西。

在實務上,自動測試是當團隊成長時,要使得持續部署 (continuous deployment) 可以運作的必要條件。因為當程式碼基底的大小,隨著產品成長而變大時,團隊成員對於程式庫的平均熟悉程度,卻會隨著新成員的加入而下降。

讓程式碼的原作者,在程式碼剛撰寫完成、印象還非常強烈時,一併將自動測試和驗証也加上,會比讓他們在幾個月甚至是幾年後,再回頭來修改同一份程式碼 (而且沒有測試),要來得更加容易 (譯註︰針對這點小弟是非常有共鳴的)。鼓勵一個強健的單元測試文化,也可以將程式驗証的責任轉向程式碼的作者 (譯註︰而不是未來的維護者)。

八、20% 時間政策的實施 (Allot 20% time)

Gmail 源自於 Paul Buchheit 的 20% 時間專案,而他只用了一天就做出了第一版[20]。 Google News、Google Transit 和 Google Suggest 也是源自於 20% 時間專案。當我在 Google 工作時,利用我的 20% 時間來建立一個 Python 語言下的框架,以使得進行搜尋頁面展示 (demo) 更加容易。也許目前 Google 的 20% 時間,成果產出較 Google 早期時要來得少[21],但讓工程師花費他們 20% 的時間,來從事某件跟公司產品路線 (product map) 無關的業務,這對於較小的工程團隊來說,仍然代表了一種創新搖籃的信念。

當我在 Ooyala 工作時,Ooyala 並沒有正式宣佈 20% 時間政策,但我仍然花了一些時間來開發一個針對 Flex 和 Actionscript 的命令列建置工具,以加快團隊的軟體建置速度。而我也剛好在 Adobe 的 Flex Builder 建置方案開始變差 (started to degrade) 時完成了工具的開發,現在這工具仍然在 Ooyala 中被使用,即使團隊的規模已經較原本成長了超過 3 倍。

Atlassian 在經過一年的實驗後決定導入 20% 時間政策;而 Facebook 所採取的是 20% 時間政策的變形,就是週期性地舉辦黑客松 (hackathons)︰一個整夜的活動,這活動的唯一規則是,你可以進行任何與你目前在做的事無關的程式開發。Facebook 這樣的做法也在後來被 Ooyala 所仿效採用[22]。

當然自上到下的產品規劃,對於聚焦公司的整體方向是必要的,但這種方式不能自工程師這邊取得太多與基層貼近的創意。只要工程師們為他們 20% 的時間負責,並專注於進行影響力高的開發,那麼這些 20% 專案對於產品來說,將可以為產品帶來大量的進展。當然若沒有正式的 20% 時間政策,這些事仍然可能發生,但工程師和設計師們將更難去嘗試某些瘋狂的創意想法 - 這些狂熱份子,基本上都要犧牲他們的週末或假期,才能夠進行這些嘗試。

九、建立一個持續學習與改善的文化 (Build a culture of learning and continuous improvement)

可以從工作中得到學習和適當的挑戰,是進入心理學教授 Mihaly Csikszentmihalyi 所說的「流」(flow) 狀態的兩個要件,當人們進入這狀態時,會非常專心在他們正在從事的事情上,而且會專注到忘了理會時間[23]。使用較快的迭代週期 (iteration cycle) 以帶來直接和快速的回應循環,是進入流狀態的另一個要件。

其次,每週舉辦的技術講座 (tech talk) 可以為工程師提供一個園地,來分享他們的設計或最近的專案成果,並提供機會來使得工程師對他們的工作成果引以自豪。對於團隊來說,也可以趁這個機會,來學習更多團隊工作範圍以外的新知。

最後,將內部流程給文件化 - 像是電子郵件服務如何運作,或是搜尋引擎中的排名如何變動的原理等方向 - 也有利於工程師可以自行來學習和探索新知,這種做法也可以和 20% 時間政策形成良好互補 (譯註︰因為先拿 20% 時間來了解現有技術流程,有助於進行在這之上的技術創新)。在 Quora 公司,我們會在內部運行專屬於內部交流使用的 Quora 站台,在內部的站台中,我們可以互相詢問產品與開發相關的問題。

當學習文化建立後,組織自然會聚焦在帶領和訓練每個工程師,以確保他們具備基本的演算法、系統和產品等確保團隊成功的必要技能。當一個工程部門越是成長,花在招募 (特別針對大學校園的招募) 和需要花費在帶領和訓練 (新進人員) 的成本心力也就越高。對於一個新進工程師導師 (mentor) 來說,在新人 (new hire) 到職後的前 4 週,每天花費一小時在他們身上,似乎是一種負擔。但從另一方面來看,這樣的投資,代丧未來這個新人,在未來的一年中,將會花費少於 1% 的總時間在這些初階問題上,而且團隊也可以較高的標準來判斷新人是否已經準備好 (譯註︰因為投入的成本心力更高,可以預期新人會比放牛吃草更加進入狀況)。

十、聘用最好的人 (Hire the best)

聘請最好的人,是上述我所提出的許多點論述的基石。如果你覺得你同事是 B 級工程師,那麼你很難尊重他的專業能力;如果你不相信你同事的產品嗅覺,那麼你就很難給予他在產品開發上的自主權;最後,如果沒有其他聰明的人來挑戰你的想法,和驅使你簡化你的設計,這時候你很容易掉入陷阱,去建置某個複雜的系統,只因為你沒有足夠的工程經驗,來識別要如何建立出正確的軟體抽象層。

在矽谷流傳一種說法,據說是由史蒂夫·喬布斯 (Steve Jobs) 所創造的,即「A 級的工程師會聘請 A 級工程師,而 B 級工程師卻只會聘請 C 級工程師。」[24] [25] (譯註︰意思是 A 級的工程師會喜歡良性競爭和激盪,而 B 級的工程師會找能力不如他的新人,以維持他的優越感) 聚焦在招募和聘請合識的人,對於工程團隊的健全成長來說,是非常困難但卻關鍵的議題。

Yishan Wong,前任的 Facebook 工程經理和總監,他認為聘用新人對於工程團隊中的每個人來說,都是第一優先重要的事,不只是對管理者而言,對於工程師來說也是如此[26]。他也很準確地指出,「聘用最好的人」("hiring the best) 和「聘用你面試的人選中最好的那個人」("hiring the best candidate that you've interviewed.) 這兩件事上在本質上是有區別的。

在 Ooyala 公司的早創期,我們幾乎快被湧進來的客戶需求所淹沒,使得我們幾乎都要降低我們的招聘標準,以使我們能聘請足夠多的人來消化手上的工作。我很高興當時我們沒這麼做,因為低質量的代碼和較弱的工程師所產生出來的技術債,最終一定會傷害我們的團隊和產品。

結論

建立一個好的軟體工程文化,一定會花費許多工夫,但最後所形塑出來的工作環境,將會令您覺得這一切都非常值得。(Building a good engineering culture is certainly a lot of work, but the resulting work environment is well worth it.)

Reference List

[18] What is "bus number" and why do you want it to be greater than 1?
[19]: How do experienced engineers at startups avoid stagnation due to the overabundance of operational issues?
[20]: Communicating with code
[21]: How does Google’s Google Innovation Time Off (20% time) policy work in practice?
[22]: Inside Facebook’s final Palo Alto Hackathon
[23]: Flow (psychology)
[24]: What is an "A Player"?
[25]: What I Learned From Steve Jobs
[26]: Engineering Management - Hiring