谷歌员工的一个工作习惯:Snippet

Snippet 其實原本是一個程式設計的名詞,它的原意就是「小碎片」、「小片段」。工程師常喜歡把自己看到、寫過的一小段程式、方法,或是一個子單元保留起來,以後可以在其他程式裡頭重複使用。這套方法被套用在 Google 內部的工作流程裡,原本只是方便組織運作,不致於浪費太多時間在開會,不過並沒有什麼特別漂亮的軟體或系統,只是單純利用最簡單的 Email 來進行。

這樣的好處是:隨時隨地都可以回報。不管你是透過 Blackberry、筆記型電腦,或是在家、在旅行,只要想到都可以記錄下來,snippet 的形式非常簡單,只是跟原本工程師習慣記錄 code 的方式很像:很簡短、扼要。這樣的好處是避免過於冗長,每次都得要花上很多時間來「解讀」,如此一來就失去了 snippet 的意義了。

在工作流程上的應用,snippet 除了是個人工作記錄的一部分外,運用在組織管理上,配合了組織內需要回報工作及進度的特性。於是,兩者便有了巧妙的整合。所以,把 snippet 形容為工作流程的 scrum(敏捷工作術),再合適也不過了。

工程師的 snippet

在 Google 內部,寫 snippet 很簡單,對工程師而言,依舊是保留其最原始的簡單、扼要的結構,所以我常看到的工程師的 snippet,通常是長這個樣子:

[This Week]
1. Action Item 1: goal, target date, expected outcome.
2. Action Item 2: goal, target date, expected outcome.
3. Action Item 3: goal, target date, expected outcome.

[Next Week] 
1. Expected Item 1: goal, target date, expected outcome.
2. Expected Item 2: goal, target date, expected outcome, self-learning.
3. Expected Item 3: goal, target date, expected outcome, study.

[This Week] 裡列的是本週重要工作事項,他的形式很像是 to do list(待辦事項),之所以只有三條其實非常有意思。一來,每個人每週的工作時間不過是 5 天,每天 8 小時,扣掉吃飯、低工作效率時段,其實時間極其有限,二來,列了太多項目反而是不切實際,就像是吃 buffet,卻拿了多餘的菜餚在盤子上一樣 “put too many dishes on your plate”(餐盤裡放太多東西了),反而會消化不良或浪費食物了。

[Next Week] 裡列的是下一週的工作目標或項目,目標是比較廣泛的方向,項目則是很具體的事項。下週要執行的目標或方向,可以很具體,也可以尚待開發,這在 Google 裡頭十分常見。例如,要開始動手寫程式或規劃一個系統前,你會需要做一些先遣的「功課」,比如說,你剛接觸一個新的產品,會需要先閱讀、瞭解他的架構或 API,這樣的事項可以被列為一個項目:瞭解 XXX 產品的架構跟 API。

這是工程師的 snippet:非常簡單、扼要。因為大部分時間必須要專注在寫程式上,花太多時間想自己要做什麼事是不符合效率原則的,這樣的原則其實也適用公司裡的每一個角色,所以 snippet 最大的原則是:不要花超過 5 分鐘。

snippet 跟工作流程的整合

在矽谷其實有很多公司實作類似的方法,據我前同事的告知,Yahoo! 在美國總部的某些部門也有這樣的「回報」機制。這樣的機制到了不同部門,也會因為不同部門的特性差異,開始有了衍生的版本。

例如,產品經理是一個橋樑的角色,常常需要跟不同部門的同事間溝通、協調,所以 dependency(依存項目)便會常存在產品經理的工作流程裡。不過,dependency 並不會被列為獨立的一個項目,而是解釋一件事情執行過程中出現的可能影響執行的因素。此時,通常還會多出一個用中括號的大項:

[Need Help With]
1. Need A’s support with getting XXX done by DDD.
2. Waiting for B’s implementation of YYY expected to be done by DDD.
3. Will be meeting with C, D and E for launch plan.

這些項目是記錄你在執行自己的工作事項過程中遇到的 dependency,你也必須去追蹤其進度,甚或是構思其他可以解決或加速執行的方法或資源,以在合理時間內完成你自己的工作事項。在 Google 的產品經理工作流程,我們還會加上紅、藍、綠「燈號」標示工作項目的進度跟狀況:

[This Week]
1. Action Item1: XXX
Status: [Green]
blah blah

2. Action Item 2: YYY
Status: [Yellow]
blah blah blah

3. Action Item 3: ZZZ
Status: [Red]
blah blah

這些燈號沒有非常嚴格的規範,不過大致上是這樣劃分的:[Green] 表示一切順利進行,可以如期完成。[Yellow] 表示可能有些停滯,也許會影響到進度,必須多加留意。[Red] 也就是紅色警戒了,表示確定該事項確定會延遲。

與組織目標、績效的碰撞 

 

snippet 可以是個人工作流程,當然也可以跟組織的流程碰撞,產生不同的效果。

公司每一年都會訂出幾個大的方向、方針,例如:提昇搜尋市場佔有率 XX%、在 XXX 市場有顯著的成長。然後各部門再依據幾個大方針去落實必須要執行的具體項目。所以每個部門都會有依照自己部門特性所規劃出來的執行目標。

我先前是待在產品管理部門,產品部門當然也會訂下幾個執行目標。這樣的目標也被落實到 snippet 裡,將需要執行的工作事項,分別依照不同的大方向,列舉出不同的專案、執行項目、進度。這樣的好處是,非常結構化,一目了然。然而,隨之而來的副作用就是:snippet 不再只是 snippet。所以產品經理的 snippet 通常有點過於冗長 — 所以產品經理必須要用更有效率的方式工作,將 snippet 作為個人的「計分板」。

此外,組織彼此間常常需要大量的溝通,而在 Google,snippet 被視為減低這種溝通成本的良方之一。透過 snippet 這種較為結構性的一封 email,可以讓主管或其他人花不到一分鐘就明瞭你目前正在進行哪些事項。

首先,每個人被規定要養成一個好習慣:每個禮拜五下班前,花五分鐘時間,編寫自己的 snippet,然後寄到一個 weekly 的 mailing list。有的時候,因為出差或真的忘了,最遲可以在星期一早上八點前寄出 — 但絕大部分人都選擇在 TGIF 後就立刻將 snippet 寄出,一來只需要花五分鐘,時間不長,很快就可以完成;二來「今週事今週畢」,趁記憶猶新時,趕緊把進度的狀態做一個更新,免得過完週末就忘光了。

Snippet 在每個禮拜一早上會由一支程式依照組織的 report line 做彙整,所以你的主管其實會收到一封 compile(彙整)後的信件,裡頭是所有報告給他的直屬下屬的 snippet,由於每個人都很簡短,所以信件不致於太長 — 但有些主管的直屬下屬人數眾多,真的就會是很長的一封信,這個時候人事單位也會 review 過多的直屬下屬是否會造成工作效率的低落,作為調整的依據之一。

這些都沒有特殊的「系統」在運作,依賴的只是最常見的 email、mailing list,非常有效率,公司也不會耗費太多時間跟成本在開發企業工具。

除了這種溝通、工作記錄的效用外,Snippet 最大的好處還是「跟個人績效考核的結合」。

每年的 focal review(績效成果檢視)時,每一個員工必須先要撰寫自己的 self assessment(自我檢視),列出自己過去一年來的績效,Google 的運作方式也很結構化,每一季會進行一次 quarterly review(季成果檢視),這個時候,員工便可以從那些以週為單位的 snippet 中,「回顧」一下自己做過哪些事,有了什麼樣的成果。

snippet 設計為以週為單位很有趣,既不會太干擾正常的工作,以致於花費太多時間在這上頭,進行 quarterly review 時,其實也不過是去回顧一下每個月最多 4(或 5) 個 snippets x 3 個月(一季)的數量,從中挑出具體的績效項目,並不會耗費太多時間。而年度的 focal review 便可以從過去三個季度,加上剛過的一個季度的  quarterly review 結果來進行彙整。

這樣的結合,讓員工在做 self assessment 的時間,分攤在每週五分鐘的時間裡完成的 snippets 裡,很輕易就可以彙整成自己的具體績效列表。

Snippet 的實作經驗

Snippet 在 Google 被實作得很好,因為每個人都有相同認知跟好的習慣,並且配合了公司的整體方向在實行 — 重點是在上上下下員工的認知與認同,而不在使用了多強大的工具或方法。

我在幾個實作得不好的公司觀察到其失敗的原因,通常都是因為大家不相信這樣(這件事、這種方法)會有效,所以漸漸就怠惰了。到最後,無疾而終的除了是每個人不認同下, 變成了應付,也在不認同下,變成了「額外的負擔」。當一切變成了「應付」跟「額外的負擔」,就註定了會是失敗的實驗了。

我也曾經見過員工「排斥」跟其他人報告自己的工作進度 — 職場本身就是一個社群,很多事情必須仰賴不同功能的其他員工來共同完成,如果畏懼讓其他人知道你的工作進度,就跟公司不告訴你執行方向一樣矛盾。這是一個團隊合作的時代,每個人都必須是 team worker(團隊工作者),team worker 的意義不只是在於可以與其他人協同作業、彼此分工與配合,同時更在於有共同的認知。

Snippet 能否成功地被執行,帶給一個公司在工作流程或效率上的實質效益,其實不在於使用了什麼樣的工具或方法,而是在於整個團隊都擁有共同的認知。

最後,這個 snippet 的概念,被一家在西雅圖的新創公司在2010年8月實作成一個產品了,其中兩位共同創辦人就是 Google 離職的員工。ThinkFuse — 沒想到在 Google 內部這個寫 snippets 的工具也可以被商業化。

補充:

有人問:「沒有預訂完成日期的工作項目算敏捷嗎?」
其實,列在上面的就是你預訂在一週內可以做到、完成的。如果不是一週內可以完成的項目,可以將之細分為好幾個以週為單位的小的執行項目,這樣可以避免貪多、讓 snippet 上的項目變成真的只是應付交差了事。同時,隨著每週的時間更迭,snippet  上的項目的執行進度也會被執行的人持續追蹤、更新。

转:http://dannyimages.com/2012/06/05/2106-smart-working-with-snippets

发表评论