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 blah2. Action Item 2: YYY
Status: [Yellow]
blah blah blah3. 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
