225
解密Facebook產品的開發流程
王淮是Facebook第二位中國籍工程師，也是第一位中國籍研發經理，他一手開創了Facebook的支付安全和客服工具領域。2011年他離開Facebook，回國成為天使投資人，希望用自己在Facebook的經驗幫助創業者。王淮下周將做客CSDN，歡迎讀者朋友留言，我們將挑選部分問題，在專訪中邀請王淮解答。在詳細說明Facebook產品開發流程的九大步驟之前，必須先講清楚一點，這些是我用馬後炮的方式來思考自己在Facebook做產 品、項目的實踐中可能出現的步驟。所謂的“流程”，在Facebook內部並不存在，這些步驟並不都是必須的。對於不同類型的項目，有些對時間要求高一些，所以更強調速度;有些對質量要求高一些，會更強調項目管理的流程(Process)。請讀者在閱讀時仔細斟酌，哪些符合自身的實際情況，則可以借鑒; 哪些不適合，要靈活掌握。
描繪遠景，設置目標
做每件事情之前都要有明確的目標，在聚焦於細節之前要有大的遠景(Vision)，這可以在以後的實施過程中指引方向。對於遠景的思考，主要圍繞以下三點。
為什麼設這個目標，而不是另外一個?
在做一件事情之前，腦子裏應該有這件事情完成之後是什麼樣子這個畫麵，接下來很多事情都是圍繞著這個最終畫麵來進行的。
計劃做些什麼來實現這個遠景?這就需要將最終目標具體化，變成一個可以想象的圖片，甚至量化，然後才能使得最終目標容易被別人理解。
那又該如何設定目標呢?在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……的方式來)，最後挑選排在最前麵的幾項。分析完後，對幾個明顯一定要做的想法很容易決定，對幾個要 去掉的也很容易決定，關鍵是剩下的那些想法，沒有足夠的精力把它們都嚐試一遍，這就要考驗你的抉擇能力了。
跨團隊溝通
決定了要做的項目之後，就需討論如何跟其他相關組的計劃對接。你當然不希望原本以為兄弟組能配合自己做一個項目時，卻發現對方並未把與你項目相關的工作放入他們的計劃中。這裏要進行的溝通，就是讓相關組之間做的事情是相輔相成的，而不是互相扯皮，造成不必要的內耗。
有兩類人是特別需要溝通的。
不同職能之間的溝通，包括工程師、產品經理、設計師，還有與項目相關的上下遊團隊或部門。
相關的工程兄弟組之間的溝通。因為大家相互之間經常有技術或者框架上的共享，我們定下要做的事情，就看看相互之間是否有可以匹配的項目，如果我們需要他們的配合，就要看怎樣可以列入他們的計劃。
告知所有可能關心的人
我們會召開一次最終的計劃定奪會議。主要是由工程師和產品經理及一些非常相關的人參加，這種會議是小規模的，因為不想在決策時讓其他非產品技術的人員參與進 來，其他人的聲音已經在之前的跨團隊溝通過程中被充分地考慮了。如果前麵的工作準備得比較好，這種會議速度都很快，一般半個小時左右。
整個計劃定下來之後，會發一封郵件給所有關心該計劃的人和相關工作的人。並且會在接收人那裏把老板、老板的老板都放進去，以確保他們能清楚、理解並支持我們組的計劃。
設計產品
對於任何一個項目，具體執行中一般都涉及四個維度：功能(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招的人都是最頂尖的，這種假設在多數情況下被證明是可行的。
最後更新：2017-04-03 21:30:11