20% self-improvement program 實際案例分享

前言

年末年始很適合來回顧過去展望未來，2020 對我們這代人來說絕對是難以忘記的一年，面對 2021，希望我們繼續保有對生活的熱情，享受生命的每一刻美好。

2021 的第一篇文章不談生硬的技術、不寫長篇的教學文，我想分享一下在 2020 的最後一個 quarter 中，公司團隊所嘗試的 self-improvement 計畫，討論它為我們帶來的好處與是否適合大家嘗試導入。

何謂 self improvement 計畫？又為何重要？

這個計畫實際上是由我們團隊新進主管所提出的，他認為，除了完成工作上交付的任務外，持續去精進專業能力是我們工程師的一種生活方式，這點相信毋庸置疑，大家都在推廣要撰寫部落格、參與開源專案、製作 side project 等等，這都是為了精進我們的專業能力。

然而，生活不是只有這個面向，工程師也需要照顧家人、培養各種嗜好?，以及享受其他生活美好；或更簡單點，維持你的 mental health。

若要在下班後的時間，同時完成這所有的事情，著實是相當困難。

因此他提出的 self improvement 計畫就是希望能建立一個框架，讓這一切從理想狀態變成現實。

相信大家都聽過 Google 著名的 20% time，也就是能利用上班時間的 20% 來做自己想嘗試的專案，無論是否直接跟工作有關聯。

所謂的 self improvement 計畫就是類似的概念，利用每個 sprint 的 20% 時間來增進自我，差別在於執行的專案必須要能夠幫助到你在工作上的成長。

以一個 sprint 兩個星期來說，總共十個工作天，20% 的時間等同於每個 sprint 必須騰出兩天的時間給團隊成員執行自我精進計畫。

沒錯，這等同於在要求公司對員工進行投資，但其實你仔細想想是非常合理的，畢竟當你精進了專業能力，公司當然也會受惠，更別提在過程中你的產出可能就已經直接對公司帶來正面影響，像是你可能在過程中幫忙製作了增進大家效率的開發工具等等。

不過說是這樣說，一切還是很理想化，因此在真正執行這個計畫前，團隊內部是進行不少討論的，尤其是需要說服 PM 們認同這項計畫的好處，因為這是有可能會影響到公司專案的時程。

實際運作方法

Self improvement 計畫可以歸納為三個步驟：

• The what: 選擇你要做的專案

• The how: 執行

• The outcome: 分享結果

剛剛提到，我們的 self improvement 計畫與 Google 的 20% 不同的點在於我們有限制能做的專案範圍，但實際上我們的規範還是非常寬鬆的，主要分成三類：

1. Improve internal projects and tools
2. Evaluates a new technology or framework
3. Language Improvement

你可以選擇利用平常想玩但工作上用不到的技術來實作一些增進開發效率的工具，像是我們有成員利用這時間製作了集合我們日常開發所需工具的 CLI tool，平常需要許多步驟才能設置好的環境，現在只要透過 CLI 下個指令就通通搞定，甚至有 web UI 介面可以操作；又或者你可以學習一門新的語言，截長補短，將好的概念應用到日常工作中，舉例來說，有成員學習了 Rust 與 webassembly，將 Rust 語言在 error handling 的一些概念引進我們 Typescript 的專案（雖然這樣的作法好壞見仁見智，但就我個人看來，這種火花對團隊是非常好的）。
此外，畢竟公司是跨國團隊，語言溝通還是很重要的一個環節，利用這時間來增進你的英文或其他語言的水平，對個人與公司都是有極大的好處。

除了上述這些偏向個人取向的例子外，也可以是組成一個小團隊來執行 self improvement 專案，像是前後端工程師互相舉辦 workshop，讓前端學習後端，後端了解前端；或是組織系統設計的讀書會，一起思考設計產品系統等等。

上述是三步驟中的第一步驟，也就是你要利用 self improvement time 做什麼。基本上只要能規範在我們定義的三大分類中，你做什麼都是可以的。

再來是執行面，我們訂定 two-week sprint 中的最後兩天作為 self improvement time，在每次的 sprint planning 與 backlog refinement meeting 時，必須考量到實際工作天數只有八天，依此來權衡各項 task 的優先順序，並依照先前的 sprint velocity 調整放進sprint 的點數。

而最後那兩天其實也並非整整 16 小時都是 self improvement time，我們把 sprint review, demo 與 retrospective meeting 分插到這兩天內。會想將這些 ceremonies 與 self improvement time 放在一起是有原因的，首先，每次開完 sprint review/demo 與 retrospective 後，工作效率通常不會太好，畢竟是一個 sprint 的結束，將 self improvement time 安排在同一時間內，不僅能提升大家士氣，也比較好用來說服 PM 們；另外，雖然 review、demo 與 retrospective 算是 scrum ceremonies 內比較輕鬆的部分，但就我們團隊內部觀察下來，我們也是會花費不少時間在分析檢討，將他們拆分成不同時段的會議，也有助於大家更能集中精神、更有效率。

最後一個步驟是 outcome，我們利用公司資源，把時間花在進行 self improvement 上，總是要做出點什麼成果才說得過去，對吧？

這樣的想法是很自然的，但執行起來有很多面向要考慮，首先，要確保成員信任這個機制並不會影響到你的績效考核，否則所謂的 20% time 就不是 80% + 20%，而是 100% + 20%，額外增加了更多的壓力在成員身上，這就本末倒置了。

再來就是不該限制形式，我們鼓勵大家舉辦 sharing、workshop、open source 或甚至是參加 conference 的方式去展現你的成果，但沒有任何硬性規定。

每個月，我們會舉辦一次內部的簡單分享會，讓大家自由得談論各自在 self improvement time 中做了哪些事情，還有哪些想做、有沒有需要找人一起幫忙的等等。在分享會上，我們不批判你的進度與成就多寡，我們專注在這過程中，你『有沒有獲得』些什麼。

在一個大家都有同樣共識，且優質的團隊內，你會發現這樣看似過於自由奔放的機制，反而能驅動大家去做出很棒的東西，以我們團隊的例子來說，有人因為這多出來的時間，有機會在公司內部工程部落格中發表研究成果，也有人撰寫了一整套 CI 自動化測試的工具，能夠推廣給公司內其他團隊使用，並寫出完整的說明文件。

你或許會說這些人就算沒有 self improvement time 也會做這些事，但重點就是，讓他們在工作的時間內完成，對成員本身來說的感覺就很好，更別提能讓他們有更多的時間去接觸專業外的事物，接收不同的刺激，理論上能更加反饋到專業能力上頭。

執行結果與過程中的阻礙

說得這麼美好，實際的執行過程中，也是有一些阻礙，否則就也不會有網路上一堆關於 Google 20% time 神話破滅的討論了（The Myth Of Google's 20% Time. It is one of the most enduring innovation ideas, but it may not be all that it seems, The truth about Google's famous '20% time' policy, Google 創新「80/20」法則名存實亡？員工時間分配技巧是創新最大考驗 ），就連待過谷歌的前雅虎 CEO Malissa Mayer 都說那其實是 120% time 了。

在試驗的一個季度內，我們總共執行了兩次 monthly sharing，每一次都會收集一些 feedback 來做調整，大致上觀察到的阻礙有以下幾點：

• 真的不知道要做什麼。不是每個工程師都有想要做的 side project。

• 難以在平常的工作時間切換思緒，去做增進自我的專案。

• self improvement 計畫只有在我們團隊內部執行，許多跟其他團隊有相依性的事務很難真的在那兩天內排開，加上後端團隊都有 on call schedule。

這幾點是比較難解決的必然問題，對於不知道要做些什麼的成員，我們會由其他成員來帶動，邀請他們加入其他已經在進行的專案；覺得無法適應如此切換工作狀態的成員，我們也不勉強，先以安排工作上一些比較沒時間處理的 refactor 或 tech debt 給對方，讓他們慢慢適應；而至於與其他團隊的合作上，我們也會告知他們我們的 scrum 時程，在不影響公司主體專案進行下，調整 schedule，並在必要時給予 support，但還是以不打擾成員兩天的 self improvement time 為基本準則。

上述問題用這樣的處理方式到目前為止算是還算穩當，但畢竟才執行一個季度，後續還需要繼續觀察調整。

對於我個人來說，困難的部分在於要捨得在那兩天確切的放下工作上的項目。即便在 sprint planning 時已經把時間也考慮進去了，但在實作 tasks 的過程，不免會有一些突發狀況，或是靈光一閃想要多做些什麼東西，這時候在那兩天內我還是會偶而會忍不住偷做一下工作的內容，但由於 self improvement 計畫並沒有規定要有多少產出，也不在績效內，所以並不至於到變成 120% time。

另外還有一點值得一提。

在前面我說過，我們為了不增加大家的負擔，盡量不限縮成果分享的形式與內容多寡，但我們是很明確的跟大家說明『一定要空出兩天作為 self improvement 計畫』，算是強制性要求大家參與，若是連參與本身都不強制，那整個計畫很容易就流於形式，到最後就不知不覺得消失了。

結論

就如同前面提供的許多關於 Google 20% time 機制的討論，這件事情執行起來很容易不小心就走歪，絕對不是適合每間公司每個團隊都採取這樣的做法，但至少是值得大家拿出來討論看看，是否能對你的團隊造成正面影響。我也不會覺得我們團隊能夠依照現在的步調走到多遠，但不斷的試驗與調整不就是工程師最擅長的嗎？大家又是怎麼看待這件事情呢？歡迎大家一起提出觀點討論！