Dec 27, 2016

很值得一看的 Spotify 的工程文化

這是在網路上流傳很久的 Spotify 公司工程文化的介紹，雖然是兩年前的影片，但看完後覺得跟我們公司有很多相似的地方，而且也有值得學習的部份。因此特別把其重點整理並紀錄下來，以供往後組織參考與討論。

Part 1

重點整理：

基於敏捷的工程文化：早期引入 Scrum ，但彈性去應用這些標準。
拆分小隊來自主管理與執行任務，但都朝向產品目標前進。並想辦法讓目標一致性與小隊自主性都達到最大值。
由領導者去溝通該解決的問題與原因，由敏捷團隊共同去找出最好的解決方案。
不強制所有小隊標準化，讓小隊自行決定該怎麼進行任務。而小隊之間可以互相傳授技術，讓工作的進行逐漸減少阻礙。
將系統的功能單純化並互相獨立，並讓一個小隊負責一個系統。但注重程式碼共享，不用等到負責的小隊有空才修改。可以在修改完後由負責的小隊 code review 。
尊重隊友，並信任每個人的自主性，但又可以在需要協助時獲得幫忙。
持續改善職場環境，讓員工的滿意度達到最高。
用部落、分會、公會等分散式社群結構來凝聚每個員工，不讓公司階層式組織架構侷限了員工的領域發展與自主性。
發佈程式版本應該要容易且頻繁，所以投資在自動化測試與持續整合交付的基礎建設上。
發佈時應該要互不影響，所以各模組改用嵌入式網頁的區塊來獨立開發與發佈。
開發小隊分成：用戶 App 小隊群、功能開發小隊群、基礎建設小隊群。
自主服務模式是讓小隊先行啟用環境，讓其他小隊可以更容易加入功能，同時也讓交接不再被視為畏途。
利用功能切換模式 (Feature toggle) 來加入未完成的功能，而不是 branch 的方式來加入功能。這樣可以早期曝露整合問題或更容易地進行 A/B 測試。
信任比控制重要，恐懼不會抹滅信任，但會扼殺創新。如果失敗會被懲罰，人們就會不敢嘗試新的事物。

Part 2

重點整理：

一個包容失敗並快速復原的環境，讓團隊能更快地犯錯，並儘快從中學習，並且改善它們。
不是檢討誰犯錯，而是檢討為什麼會犯這個錯，以及學到了什麼，改善了什麼。
持續改善流程，而不是僅僅修復產品。並且從下而上驅動，從上到下支持這個文化
失敗必須有爆炸範圍，不能因為一個小功能失敗而影響整個系統。每個功能都會事先釋出給小部份使用者試用，等待穩定後再逐步切換。
實驗階段的精實創業：先思考功能是不是用戶需要的，再建立 prototype 來讓人們試用並取得回饋；依照回饋來建立 MVP ，儘快釋出給部份用戶並且學習與改進直到達到預期成效，最後才全面釋出。
除非跟合作夥伴或行銷活動有關，否則就先專注於是否交付出有價值的創新功能、而後才會注重計劃性的預期成效。
駭客日或駭客週可以讓工程師有空做一些自己有興趣的創作或實驗，重點在有趣，而不是有用。鼓勵大家有所創新，並從中找到靈感。
鼓勵實驗的文化，嘗試各種可能性並比較哪種比較適合團隊或功能，讓文化的延續是基於客觀條件來決定的。
排斥浪費的文化，有價值的事可以持續進行，沒有價值的事就儘快拋棄，避免浪費工程師寶貴的時間。
大型專案通常是沒有必要的，儘可能以精簡的小專案來進行。真的有必要的大型專案就用視覺化流程與每日會議，讓每個小隊與利害關係人能協同討論合作並得到快速的回饋。
小而紥實的領導團隊來監看整個大型專案的方向，包含技術經理、產品經理與設計經理。
利用看板方法來看見專案的全貌，像是進行中的任務，或造成發展阻礙的項目。
用 Awesome 來定義哪些事是值得做到的方向，然後再用看板方法來專注在流程的改善與工作的追蹤。
透過健全的文化來快速修復有問題的流程；讓新人在一週內透過密集訓練去熟悉這些文化，並且有真正的產出。
用故事來流傳文化的價值，分享成功與失敗的經驗。
組織的文化就是成員的心態與行動的總和。當成員塑造出自我期待的行為，他們就是公司的文化。

心得

在 KKBOX 工作這麼久，雖然知道我們還有很多要改進的地方，但一直沒有很認真地思考這個問題；而兩年前的 Spotify 在敏捷開發的流程上，其實有很多值得我們團隊借鏡的地方。這點我們正在試著透過很多方式來影響團隊成員的態度，讓他們能夠逐漸接受這樣的觀念與方法，進而往這個時代應該要有的先進流程來邁進。

一個良好的公司文化真的要靠每個員工心裡願意去改變自己才能建立起來，一直抱持著趕快完成專案進度的心態而忘了公司真正產品的價值，是無法在這個業界繼續立足的。期盼公司高層能重視這樣的文化，並且讓每個 KKBOX 員工能以世界一流的軟體公司為榮。