科技公司（尤指灣區的大多數科技公司）常常在說的Move Fast，應該如何定義和理解？

02-09

灣區很多科技公司，包括Uber，Facebook，Snapchat（雖然這貨不在灣區但好歹也是加州）等等都強調自己的「Move Fast」文化。對所謂的「Move Fast」應該如何理解？

謝邀

個人感覺，很多新興科技公司提倡的「Move Fast」，更多的是希望保持類似創業公司的快節奏高效率工作風格，與之相對的是老牌科技公司由於日積月累的內部爭鬥產生的「派系林立」的環境。

具體到事情上，以在下個人的經歷來看，Facebook比Amazon在這方面做的相對好一些。在Facebook日常工作中，如果你覺得產品的某些方面需要改進，或者想提出一些新產品的想法，可以自己聯繫幾個相熟的工程師開工，只要和Manager打個招呼就行了，只要想法合理，Manager一般都很支持。偶爾有時候Manager有不同看法，不過也都會有理性友善的討論，有時候我會堅持自己的看法，有時候會被Manager說服。簡單的說，就是Manager的功能不是用來指揮你干這干那，而是對你做的東西做出適當的指導和評價。Amazon則相對更傳統一些，任務大部分由Manager指派，個人如果有了新的想法，一般是提交Manager審議，Manager有時候會向更高層的Management提交申請，批准後才能進行，有時候批准下來執行的可能變成另外一個組了，和提出項目的人沒關係了……

當然這些說起來容易，公司越大做起來越難。有人的地方就有江湖，哪裡都有politics和內鬥，只是程度不同吧……

這個問題自問自答希望拋磚引玉。

答主在最近求職，面題目描述裡面提到的三家公司的時候都被問到了「Why here」的問題，我通通回答的是「I like moving fast"，並就此與面試官展開了友好的談笑風生，在這個過程中逐漸形成了一個自己覺得還算說得過去的理解（答主沒有全職工作經驗，只是在幾家規模不同、文化不同的科技公司實習/兼職工作過，分別是Hulu，一家創業公司，以及Google，下面內容主要是個人感受，所以如有錯誤請指正）

我覺得「Move fast」主要有下面幾個維度：

1. 軟體開發裡面的move fast；更具體而言，是如何盡量做到快速開發出特定功能，同時儘可能地保持代碼庫的可讀性和整潔性等

2. 團隊協作方面的Move fast，比如互相之間不block不delay

3. 產品開發方面的Move fast，這個可能跟精益創業裡面的內容部分重合，即如何快速開發滿足用戶需求的產品

1. 軟體開發

具體的體現就是前面說的，開發快，Bug少，代碼還特好看特好懂特好改。我感覺這個要求是非常高的，至少我自己還得修鍊上N久。下面是我認為以我目前的水準如何能盡量做到這點：

a. 開始寫代碼之前了解系統，理清思路。這個是大公司實習得出來的經驗——在一個大型系統中開發，首先要了解清楚各個系統部件的邏輯關係，以及關鍵代碼的具體實現；其次，在開始寫代碼之前腦海中要有清晰的架構設計和思路，這樣寫起來才能事半功倍（不然會經常發現寫到一半發現要修改design，然後很多需要推倒重來）。然而，很多時候不具體實現一下是難以發現問題的，所以修正設計也是常有的事。我的個人經驗是要有設計，至少要對腦海中的設計自我感覺良好，然而不要過分設計。這個真是跟經驗有關係，寫代碼寫多了掉坑的次數就會自然而然地少了……

b. 寫自動化測試。我經歷過兩個極端，一是完全不寫測試，刷刷刷功能寫出來然後直接系統跑起來人工測試；二是在G家非常嚴謹的自動化測試，就是寫100行系統代碼，500行測試代碼的那種類型。我覺得Google的方式其實在保證質量上非常好，然而拖節奏；如果要考慮Move fast的話，我感覺10%的測試用例可以涵蓋90%的功能邏輯，性價比最高。所以，我個人的結論是必須寫自動化test，但是優先寫不可或缺的（比如核心邏輯，一出錯就世界末日的），性價比最高的（簡單的測試可以涵蓋大量功能），其它的留待以後有時間慢慢加

c. CodeReview。這個對代碼可讀性而言還是非常重要的，然而對大多數要求MoveFast的團隊而言可能比較奢侈。然而還是那句，做10%的CodeReview可能能達成90%的收益（可能沒那麼多，50%吧……），有總比沒有好，流程化、正規化地做總比隨心所欲地做要好，比如沒法每次commit都做的話可以每周找個時間大家一起讀Code散散心，把自己的快樂建立在別人的痛苦之上啥的……

2. 團隊協作

作為一介碼農其實在這方面經驗並不多，我覺得最重要的體現，一是盡量少出現被block的情況，二是盡量少出現需求理解有誤造成需要返工的情況。

被block有很多種原因，比如你提交的代碼break了別人的測試，然後別人提交不上新代碼了又找不到你人（因為可能不同時區），別人可能就直接rollback了你的commit，以防被block；或者別人直接發現你的BUG，然後直接代你修改，commit了……這些我覺得都是不錯的手段。也可能是你CodeReview沒下來，或者你在等別人開發的一個部件——這個主要是交流溝通方面，要讓別人知道你這邊的進度，眼看來不及了不要顧及面子，要厚著臉皮去催（這些經歷真是讓我臉皮厚了很多……）。同一個公司跨組合作的時候也是，你在用別的組開發的工具的時候發現有問題，並且還發現了原因，這時如果你能夠有權力直接修改對方的代碼的話，你直接改了，並且改對了，那就可以皆大歡喜了。據說FB流行一句話叫「Dont ask for permission, ask for forgiveness"，說得就是，鼓勵這種發現有錯就大著膽子改的態度吧。

對於第二種情況，關鍵的一點就是溝通好需求。這個說起來簡單做起來難，因為很多時候你覺得已經講清楚了，到時東西做出來對方一看，哎喲我去這個不對那個不對之類的很常有。有幾個手段可以嘗試：

a. 一切文檔化。比如討論的功能需求，以最終落實的文檔為準，任何修改都要反映到文檔上

b. 對於涉及前端設計的，要精確的設計圖，精確到pixel的那種

c. 學會對需求提出方提問。別人提需求，你聽進去了，別人不知道你是不是真的聽進去了，你也不知道你聽進去的是不是真的就是別人想表達的；所以一定要多提問，確保弄清楚，然後文檔化的時候把問出來的細節加上去

d. 實在覺得還是弄不清楚（比如太詳細的需求別人也給不出來，或者太忙沒法寫太細），那就快速做個Demo，拿著Demo向需求提出方證實自己的理解，確定OK了再正式開工

3. 產品開發。雖然在創業公司呆過，然而對產品開發這方面的見解還是非常貧乏，應該知乎上很多人比我見解要深的多，所以就不班門弄斧了，留待他人回答。

最後本答案都是個人經驗，畢竟經驗尚淺估計有很多錯誤，希望大家指正：）

少開會多做事