解密Facebook產品的開發流程

描繪遠景，設定目標

做每件事情之前都要有明確的目標，在聚焦於細節之前要有大的遠景（Vision），這可以在以後的實施過程中指引方向。對於遠景的思考，主要圍繞以下三點。

1. 為什麼設這個目標，而不是另外一個？

2. 在做一件事情之前，腦子裡應該有這件事情完成之後是什麼樣子這個畫面，接下來很多事情都是圍繞著這個最終畫面來進行的。

3. 計劃做些什麼來實現這個遠景？這就需要將最終目標具體化，變成一個可以想象的圖片，甚至量化，然後才能使得最終目標容易被別人理解。

那又該如何設定目標呢？在Facebook，常用的方法是遵循“SMART”規則。

S——非常詳細具體的（Specific）。目標必須被清晰定義，無法被混淆或者誤解。

M——是能夠衡量的（Measurable）。只有可以被衡量的目標，才能一直清楚做得如何，離目標有多遠，當前是超出還是低於預期的進度。

A——要有足夠的難度和挑戰性（Aggressive）。容易完成的目標，很容易讓員工懈怠；一旦失去戰鬥的激情，更談不上發揮潛能。

R——現實的（Realistic），這是對上一點的平衡。過於有難度的目標，會令員工疲憊不堪，如果最後還是沒能完成任務的話，對他們的信心是非常大的打擊。

T——要有實現的期限（Time-bound）。沒有實現期限的目標是沒有意義的，因為不知道什麼時候應該到達什麼程度。

有了目標之後，才可能有很詳細的專案計劃，所有的專案都應該是跟這些目標相關的。不相干的專案會分散注意力（Distraction），要堅決抵制。接下來，組裡人員的絕大多數時間都要花在跟這幾個目標相關的專案上。

收集想法並排出優先次序

有 了目標以後，會產生很多相關的想法（Idea），但很難判斷究竟哪個想法一定能達到這些目標，也不可能把所有的想法都試一遍，往往到最後都需要有理有據地 進行“賭博”，把精力押在某幾個核心的想法上。這也是Facebook要招最好的工程師的原因之一。工程師不僅要善於寫程式，也要有選擇想法的能力，你不 僅要對這個問題有很深入的思考，進行大量的分析，還要有膽量，能果斷押注，並且有很高的命中率。

那麼，這些想法從何而來呢？最自然的方式就 是之前延續下來的、大家明確知道要做的專案，而那些不明確的想法，才是難點。在發展非常快的公司裡，絕對不會缺少這種不明確的想法。在Facebook， 一般是由技術經理、產品經理、工程師貢獻大量的想法。負責商業運營（Business Operation）的同事也會貢獻一些想法。做下一個月計劃時，我會在當月25日左右開始給相關人員發一個一週後的頭腦風暴會議邀請，並希望他們在會議 之前把自己認為應做的或者想做的事情發郵件告訴我。我事先做分類整理，讓會議進行得更加高效。當然，線下的討論、分享等也是產生想法的好機會。

接下來最為關鍵的就是分析想法——如何挑選出最可能產生效果的想法。理論上，如果有無限的資源，我們應該嘗試所有的想法。但在Facebook，任何時候都處於資源短缺的狀態，我們必須把有限的資源放到有可能產生最大價值的想法上面。

這裡，我要特別強調一下“Top X（只做前X項）”規則：只做對目標最有影響的前X項。我們會對所有的想法進行討論，根據每個想法對目標的影響和其所需要的資源（主要是人力與時間—— “人周”）進行討論，然後排序（按P0，P1，P2……的方式來），最後挑選排在最前面的幾項。分析完後，對幾個明顯一定要做的想法很容易決定，對幾個要 去掉的也很容易決定，關鍵是剩下的那些想法，沒有足夠的精力把它們都嘗試一遍，這就要考驗你的抉擇能力了。

跨團隊溝通

決定了要做的專案之後，就需討論如何跟其他相關組的計劃對接。你當然不希望原本以為兄弟組能配合自己做一個專案時，卻發現對方並未把與你專案相關的工作放入他們的計劃中。這裡要進行的溝通，就是讓相關組之間做的事情是相輔相成的，而不是互相扯皮，造成不必要的內耗。

有兩類人是特別需要溝通的。

1. 不同職能之間的溝通，包括工程師、產品經理、設計師，還有與專案相關的上下游團隊或部門。

2. 相關的工程兄弟組之間的溝通。因為大家相互之間經常有技術或者框架上的共享，我們定下要做的事情，就看看相互之間是否有可以匹配的專案，如果我們需要他們的配合，就要看怎樣可以列入他們的計劃。

告知所有可能關心的人

我們會召開一次最終的計劃定奪會議。主要是由工程師和產品經理及一些非常相關的人參加，這種會議是小規模的，因為不想在決策時讓其他非產品技術的人員參與進 來，其他人的聲音已經在之前的跨團隊溝通過程中被充分地考慮了。如果前面的工作準備得比較好，這種會議速度都很快，一般半個小時左右。

整個計劃定下來之後，會發一封郵件給所有關心該計劃的人和相關工作的人。並且會在接收人那裡把老闆、老闆的老闆都放進去，以確保他們能清楚、理解並支援我們組的計劃。

設計產品

對於任何一個專案，具體執行中一般都涉及四個維度：功能（Feature Set），預期完成時間（Time to Market），預算（Budget，主要是人員，還有伺服器、頻寬資源、金錢等），完成質量（Quality，包括可擴充套件性Scalability、性 能Performance等）。不管你做沒做計劃，所有的決定都圍繞著這四個方面進行考量。如果進度拖後了，那麼可以去掉或精簡一個功能，或者推後完成的 時間，或者增加人手、加大投入，或者降低質量等，無非就是在這四個方面進行取捨。

很重要的一點是，設計產品時，要大概知道第一版本（V1）是什麼樣子。可以在設計時構思產品的最終狀態，但公司不會允許花大量的資源去打造一個所謂的終極版本。一定要思考第一版本包含哪些功能、什麼時間釋出、要多少人員配置、要花多少錢做市場宣傳、達到什麼效果等。

這可以避免一開始投入過大，但做出的產品並不是市場所需要的，再進行很大修改甚至放棄該產品的情況出現，這無疑是很大的浪費。

而對於技術性的系統或框架，通常會召集相關專家開會，介紹新系統，並討論為什麼做這個系統，以及其優缺點、跟已有系統的關聯。這種討論會，相對技術性比較強，一般不會有產品經理參與（他們不大懂後臺的技術），更多的是邀請有相關經驗的後臺工程師參加。

這裡要特別強調的是，Facebook非常注意不重複開發新的技術系統。一個原則是：有好的開源系統，就用開源的；有好的商用產品，就購買商用的；必須自己 開發的或者跟Facebook核心競爭力息息相關的，則集中力量開發一套，而不是重複勞動，開發多套類似系統。而對於一些跟核心資料息息相關的系統，即使 市場上有商用系統，Facebook還是會自己開發。

另外，Facebook從不期望由一個人完成某個專案所有的事情。我會要求某個組員來承擔某個專案的責任，但要的是讓他驅動整個專案，並不代表所有的事情都完全靠他個人去做。我會要求他善於使用整個公司的力量，學會積極主動地獲得別人的幫助，事半功倍地完成一個專案，同時在這個過程中獲得成長。如果讓其他組幫助做一些事情更加適合的話，我也會鼓勵朝這個方向努力。

但如果一個專案最終不成功，那麼專案負責人是不能以別人無法提供幫助作為藉口的。因此，即使別人答應幫忙，專案負責人還是需要學會去激勵別人、監督別人，通過“抒情講理”甚至“威逼利誘”等各種手段獲得及時的幫助。

但Facebook的文化鼓勵只有適合尋求幫助時才這麼做，屬於一個專案核心的工作必須由該團隊自身去完成。別人一般只能在他們的系統上給予配合或者技術上給予建議，最主要的挑戰還是靠自己。也只有這樣，一個團隊才能真正獲得成長。

指定專案責任人

要為每一個專案都指定一個明確的責任人，一般都是工程師。這樣做最大的好處是責任非常清楚，每一個專案都有非常清晰的擁有者（Owner），這讓推脫責任變得很難。

第二個好處是鍛鍊員工的才能。Facebook不希望初級工程師永遠做螺絲釘的角色，希望每個工程師都能積極領導一項任務，推動專案進展。責任明確的專案可以“逼迫”工程師擔當起責任。

第三個好處是方便交流。公司裡任何一位對某個專案感興趣的同事都可以瞭解該專案的進展情況，專案責任人就是他交流的物件，而不需要一定要去找技術經理或者產品經理。

定期碰頭會

對於每一個開發中的專案，我們都要清楚地知道具體進展，因為今天做好的東西是明天的基礎。根據專案的緊急性和重要程度定期討論，可以每天都進行，也可以每週進行一兩次。一般每次會議在10～30分鐘，而越頻繁的碰頭用的時間應該越短。

召開碰頭會時，所有跟這個專案相關的人都要參與，圍繞著這個專案把所有相關的任務及其進展迅速過一遍，每個人把自己前一天（或者前一週）完成的任務情況彙報 一下。如果遇到了困難，大家會集中討論，幫忙解決。最好不要找一些愚蠢的藉口來搪塞，這將導致原先答應的事情沒有按時按質按量地完成。

瞭解進度　彙總報告

對負責一個團隊的研發經理而言，要對自己組裡正在進行的每個專案都有深入和及時的瞭解，知道最新進展。處於綠燈狀態的，當然很好，要給予鼓勵；處於黃燈狀態 的，要給予適當的幫助，挪掉絆腳石，加速專案進展；處於紅燈狀態的，要了解為什麼會這樣，還能否採取相應措施補救。在行動之外，非常重要的就是反省，弄清 楚為什麼沒有在黃燈時及時發現並給予幫助，然後吸取教訓，避免將來出現同樣的失誤。

對戰鬥在第一線的團隊，定期的專案碰頭會可以讓某個專案 的所有戰鬥人員都能保持對資訊獲取的一致性，有共同的交流基礎。然而，後方人員，比如關心某個專案的同事或者老闆的老闆等，要了解一個專案的進展不是非常 輕鬆的事情。作為研發經理，我會在每週五把組裡當前正在進行的所有專案的進展情況彙總到一起，形成簡報，給所有關注支付產品的人發郵件，讓他們都能有機會 瞭解到相關情況。

釋出產品　監測資料

產品完成開發之後，當然就要推出去。推出去之前，有些產品需要進行風險控制。比如，支付類的產品經常會做釋出前評估（Pre-launch Review）。

所謂釋出前評估，就是在釋出之前，根據具體的產品或者該次釋出的特點，做一些諸如釋出策略、需監測的核心資料、產品演示、核心演算法改變等方面的討論。在做產 品討論時，我會要求參會的人員思考這個問題——“如果這次釋出出現大問題的話，可能會是什麼？”主要目的是在釋出之前思考可能會出現失誤的節點，如果是大 風險，做一些必要的防護措施；如果是小風險，心裡要清楚自己在冒這個險，準備好一旦出問題該如何補救。另外，由於Facebook釋出的產品比較多，經常 出現互相影響的情況，做釋出前評估可以讓大家知道什麼產品即將在什麼時候推出去。

一種釋出工程的做法是閥門控制式的灰度釋出，就是有所控制地選擇釋出的人群及其比例。灰度釋出是控制釋出的範圍和速度，但如何才能得知某一階段產品釋出的質量，何種狀況下才提高灰度釋出的範圍呢？只有通過資料監測來判斷髮布狀態。需要監測兩類資料。

一類資料反映當前的系統狀態，比如訪問總量、訪問成功量及其佔總量的比例、致命範圍錯誤的量和比例、訪問速度、出現最多的錯誤型別統計等。這些資料的統計和展示都應該是實時的，才能確保一旦發生問題，能夠在最短的時間內發現並採取措施。

另一類資料反映新功能的使用者影響（User Impact或者Business Insight）。這部分資料能直接反映出一開始做這個產品或者功能的目的。只有這部分的資料反饋是正向的，而且其變化達到了讓人接受的程度，才可以考慮擴大發布範圍。

並不是所有的釋出都是成功的。從我的經驗來看，追求完美的釋出是不現實的，不管之前的Pre-launch Review多麼全面，每次釋出都有這樣或者那樣的問題產生，最好的情況就是每次的問題都是新的，而不是上次已經出現的失誤。但在問題發生之後，通常通過 Post-Mortem嘗試儘可能從失誤中吸取教訓，讓每次的釋出帶來的學習價值最大化。

所謂Post-mortem，是通過分析過去發生的問題，從中總結可以採取的行動方案，以避免類似的錯誤再次發生。不僅適合於產品釋出產生的問題研究，同時也常用於任何突發事件的事後分析。

小結

以上就是我所總結的Facebook產品開發流程，當然，對於每一個具體的產品來說，不一定嚴格按照這些步驟進行，但大體的思路類似。根據需要，部分步驟可以被省略。根本目的是為了在產品滿足基本的質量標準之後，儘可能早地釋出出去，然後根據監測資料再快速迭代。

我跟國內的一些創業公司就產品開發流程進行過溝通，希望矽谷公司的思路可以帶給他們啟發。然而，Facebook的這些做法不一定適用於中國的網際網路企業。 在Facebook，很多時候是在證明你不行之前，假設你有能力完成一件艱鉅的任務。由於Facebook招的人都是最頂尖的，這種假設在多數情況下被證明是可行的。

 

本文節選自印刷工業出版社《打造Facebook：親歷Facebook爆發的5年》一書。特此感謝作者王淮的授權。本文選登時有刪減。