【編者注】王淮是Facebook第二位中國籍工程師，也是第一位中國籍研發(fā)經(jīng)理，他一手開創(chuàng)了Facebook的支付安全和客服工具領(lǐng)域。2011年他離開Facebook，回國成為天使投資人，希望用自己在Facebook的經(jīng)驗幫助創(chuàng)業(yè)者。

　　在詳細說明Facebook產(chǎn)品開發(fā)流程的九大步驟之前，必須先講清楚一點，這些是我用馬后炮的方式來思考自己在Facebook做產(chǎn)品、項目的實踐中可能出現(xiàn)的步驟。所謂的“流程”，在Facebook內(nèi)部并不存在，這些步驟并不都是必須的。對于不同類型的項目，有些對時間要求高一些，所以更強調(diào)速度；有些對質(zhì)量要求高一些，會更強調(diào)項目管理的流程（Process）。請讀者在閱讀時仔細斟酌，哪些符合自身的實際情況，則可以借鑒； 哪些不適合，要靈活掌握。

　　描繪遠景，設(shè)置目標(biāo)

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

　　1. 為什么設(shè)這個目標(biāo)，而不是另外一個？

　　2. 在做一件事情之前，腦子里應(yīng)該有這件事情完成之后是什么樣子這個畫面，接下來很多事情都是圍繞著這個最終畫面來進行的。

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

　　那又該如何設(shè)定目標(biāo)呢？在Facebook，常用的方法是遵循“SMART”規(guī)則。

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

　　M——是能夠衡量的（Measurable）。只有可以被衡量的目標(biāo)，才能一直清楚做得如何，離目標(biāo)有多遠，當(dāng)前是超出還是低于預(yù)期的進度。

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

　　R——現(xiàn)實的（Realistic），這是對上一點的平衡。過于有難度的目標(biāo)，會令員工疲憊不堪，如果最后還是沒能完成任務(wù)的話，對他們的信心是非常大的打擊。

　　T——要有實現(xiàn)的期限（Time-bound）。沒有實現(xiàn)期限的目標(biāo)是沒有意義的，因為不知道什么時候應(yīng)該到達什么程度。

　　有了目標(biāo)之后，才可能有很詳細的項目計劃，所有的項目都應(yīng)該是跟這些目標(biāo)相關(guān)的。不相干的項目會分散注意力（Distraction），要堅決抵制。接下來，組里人員的絕大多數(shù)時間都要花在跟這幾個目標(biāo)相關(guān)的項目上。

　　收集想法并排出優(yōu)先次序

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

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

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

　　這里，我要特別強調(diào)一下“Top X（只做前X項）”規(guī)則：只做對目標(biāo)最有影響的前X項。我們會對所有的想法進行討論，根據(jù)每個想法對目標(biāo)的影響和其所需要的資源（主要是人力與時間—— “人周”）進行討論，然后排序（按P0，P1，P2……的方式來），最后挑選排在最前面的幾項。分析完后，對幾個明顯一定要做的想法很容易決定，對幾個要去掉的也很容易決定，關(guān)鍵是剩下的那些想法，沒有足夠的精力把它們都嘗試一遍，這就要考驗?zāi)愕木駬衲芰α恕?/p>

　　跨團隊溝通

　　決定了要做的項目之后，就需討論如何跟其他相關(guān)組的計劃對接。你當(dāng)然不希望原本以為兄弟組能配合自己做一個項目時，卻發(fā)現(xiàn)對方并未把與你項目相關(guān)的工作放入他們的計劃中。這里要進行的溝通，就是讓相關(guān)組之間做的事情是相輔相成的，而不是互相扯皮，造成不必要的內(nèi)耗。

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

　　1. 不同職能之間的溝通，包括工程師、產(chǎn)品經(jīng)理、設(shè)計師，還有與項目相關(guān)的上下游團隊或部門。

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

　　告知所有可能關(guān)心的人

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

　　整個計劃定下來之后，會發(fā)一封郵件給所有關(guān)心該計劃的人和相關(guān)工作的人。并且會在接收人那里把老板、老板的老板都放進去，以確保他們能清楚、理解并支持我們組的計劃。

　　設(shè)計產(chǎn)品

　　對于任何一個項目，具體執(zhí)行中一般都涉及四個維度：功能（Feature Set），預(yù)期完成時間（Time to Market），預(yù)算（Budget，主要是人員，還有服務(wù)器、帶寬資源、金錢等），完成質(zhì)量（Quality，包括可擴展性Scalability、性能Performance等）。不管你做沒做計劃，所有的決定都圍繞著這四個方面進行考量。如果進度拖后了，那么可以去掉或精簡一個功能，或者推后完成的時間，或者增加人手、加大投入，或者降低質(zhì)量等，無非就是在這四個方面進行取舍。

　　很重要的一點是，設(shè)計產(chǎn)品時，要大概知道第一版本（V1）是什么樣子。可以在設(shè)計時構(gòu)思產(chǎn)品的最終狀態(tài)，但公司不會允許花大量的資源去打造一個所謂的終極版本。一定要思考第一版本包含哪些功能、什么時間發(fā)布、要多少人員配置、要花多少錢做市場宣傳、達到什么效果等。

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

　　而對于技術(shù)性的系統(tǒng)或框架，通常會召集相關(guān)專家開會，介紹新系統(tǒng)，并討論為什么做這個系統(tǒng)，以及其優(yōu)缺點、跟已有系統(tǒng)的關(guān)聯(lián)。這種討論會，相對技術(shù)性比較強，一般不會有產(chǎn)品經(jīng)理參與（他們不大懂后臺的技術(shù)），更多的是邀請有相關(guān)經(jīng)驗的后臺工程師參加。

　　這里要特別強調(diào)的是，F(xiàn)acebook非常注意不重復(fù)開發(fā)新的技術(shù)系統(tǒng)。一個原則是：有好的開源系統(tǒng)，就用開源的；有好的商用產(chǎn)品，就購買商用的；必須自己開發(fā)的或者跟Facebook核心競爭力息息相關(guān)的，則集中力量開發(fā)一套，而不是重復(fù)勞動，開發(fā)多套類似系統(tǒng)。而對于一些跟核心數(shù)據(jù)息息相關(guān)的系統(tǒng)，即使市場上有商用系統(tǒng)，F(xiàn)acebook還是會自己開發(fā)。

　　另外，F(xiàn)acebook從不期望由一個人完成某個項目所有的事情。我會要求某個組員來承擔(dān)某個項目的責(zé)任，但要的是讓他驅(qū)動整個項目，并不代表所有的事情都完全靠他個人去做。我會要求他善于使用整個公司的力量，學(xué)會積極主動地獲得別人的幫助，事半功倍地完成一個項目，同時在這個過程中獲得成長。如果讓其他組幫助做一些事情更加適合的話，我也會鼓勵朝這個方向努力。

　　但如果一個項目最終不成功，那么項目負責(zé)人是不能以別人無法提供幫助作為借口的。因此，即使別人答應(yīng)幫忙，項目負責(zé)人還是需要學(xué)會去激勵別人、監(jiān)督別人，通過“抒情講理”甚至“威逼利誘”等各種手段獲得及時的幫助。

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

　　指定項目責(zé)任人

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

　　第二個好處是鍛煉員工的才能。Facebook不希望初級工程師永遠做螺絲釘?shù)慕巧Ｍ總€工程師都能積極領(lǐng)導(dǎo)一項任務(wù)，推動項目進展。責(zé)任明確的項目可以“逼迫”工程師擔(dān)當(dāng)起責(zé)任。

　　第三個好處是方便交流。公司里任何一位對某個項目感興趣的同事都可以了解該項目的進展情況，項目責(zé)任人就是他交流的對象，而不需要一定要去找技術(shù)經(jīng)理或者產(chǎn)品經(jīng)理。

　　定期碰頭會

　　對于每一個開發(fā)中的項目，我們都要清楚地知道具體進展，因為今天做好的東西是明天的基礎(chǔ)。根據(jù)項目的緊急性和重要程度定期討論，可以每天都進行，也可以每周進行一兩次。一般每次會議在10～30分鐘，而越頻繁的碰頭用的時間應(yīng)該越短。

　　召開碰頭會時，所有跟這個項目相關(guān)的人都要參與，圍繞著這個項目把所有相關(guān)的任務(wù)及其進展迅速過一遍，每個人把自己前一天（或者前一周）完成的任務(wù)情況匯報 一下。如果遇到了困難，大家會集中討論，幫忙解決。最好不要找一些愚蠢的借口來搪塞，這將導(dǎo)致原先答應(yīng)的事情沒有按時按質(zhì)按量地完成。

　　了解進度　匯總報告

　　對負責(zé)一個團隊的研發(fā)經(jīng)理而言，要對自己組里正在進行的每個項目都有深入和及時的了解，知道最新進展。處于綠燈狀態(tài)的，當(dāng)然很好，要給予鼓勵；處于黃燈狀態(tài) 的，要給予適當(dāng)?shù)膸椭驳艚O腳石，加速項目進展；處于紅燈狀態(tài)的，要了解為什么會這樣，還能否采取相應(yīng)措施補救。在行動之外，非常重要的就是反省，弄清楚為什么沒有在黃燈時及時發(fā)現(xiàn)并給予幫助，然后吸取教訓(xùn)，避免將來出現(xiàn)同樣的失誤。

　　對戰(zhàn)斗在第一線的團隊，定期的項目碰頭會可以讓某個項目的所有戰(zhàn)斗人員都能保持對信息獲取的一致性，有共同的交流基礎(chǔ)。然而，后方人員，比如關(guān)心某個項目的同事或者老板的老板等，要了解一個項目的進展不是非常輕松的事情。作為研發(fā)經(jīng)理，我會在每周五把組里當(dāng)前正在進行的所有項目的進展情況匯總到一起，形成簡報，給所有關(guān)注支付產(chǎn)品的人發(fā)郵件，讓他們都能有機會了解到相關(guān)情況。

　　發(fā)布產(chǎn)品　監(jiān)測數(shù)據(jù)

　　產(chǎn)品完成開發(fā)之后，當(dāng)然就要推出去。推出去之前，有些產(chǎn)品需要進行風(fēng)險控制。比如，支付類的產(chǎn)品經(jīng)常會做發(fā)布前評估（Pre-launch Review）。

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

　　一種發(fā)布工程的做法是閥門控制式的灰度發(fā)布，就是有所控制地選擇發(fā)布的人群及其比例。灰度發(fā)布是控制發(fā)布的范圍和速度，但如何才能得知某一階段產(chǎn)品發(fā)布的質(zhì)量，何種狀況下才提高灰度發(fā)布的范圍呢？只有通過數(shù)據(jù)監(jiān)測來判斷發(fā)布狀態(tài)。需要監(jiān)測兩類數(shù)據(jù)。

　　一類數(shù)據(jù)反映當(dāng)前的系統(tǒng)狀態(tài)，比如訪問總量、訪問成功量及其占總量的比例、致命范圍錯誤的量和比例、訪問速度、出現(xiàn)最多的錯誤類型統(tǒng)計等。這些數(shù)據(jù)的統(tǒng)計和展示都應(yīng)該是實時的，才能確保一旦發(fā)生問題，能夠在最短的時間內(nèi)發(fā)現(xiàn)并采取措施。

　　另一類數(shù)據(jù)反映新功能的用戶影響（User Impact或者Business Insight）。這部分數(shù)據(jù)能直接反映出一開始做這個產(chǎn)品或者功能的目的。只有這部分的數(shù)據(jù)反饋是正向的，而且其變化達到了讓人接受的程度，才可以考慮擴大發(fā)布范圍。

　　并不是所有的發(fā)布都是成功的。從我的經(jīng)驗來看，追求完美的發(fā)布是不現(xiàn)實的，不管之前的Pre-launch Review多么全面，每次發(fā)布都有這樣或者那樣的問題產(chǎn)生，最好的情況就是每次的問題都是新的，而不是上次已經(jīng)出現(xiàn)的失誤。但在問題發(fā)生之后，通常通過 Post-Mortem嘗試盡可能從失誤中吸取教訓(xùn)，讓每次的發(fā)布帶來的學(xué)習(xí)價值最大化。

　　所謂Post-mortem，是通過分析過去發(fā)生的問題，從中總結(jié)可以采取的行動方案，以避免類似的錯誤再次發(fā)生。不僅適合于產(chǎn)品發(fā)布產(chǎn)生的問題研究，同時也常用于任何突發(fā)事件的事后分析。

　　小結(jié)

　　以上就是我所總結(jié)的Facebook產(chǎn)品開發(fā)流程，當(dāng)然，對于每一個具體的產(chǎn)品來說，不一定嚴格按照這些步驟進行，但大體的思路類似。根據(jù)需要，部分步驟可以被省略。根本目的是為了在產(chǎn)品滿足基本的質(zhì)量標(biāo)準(zhǔn)之后，盡可能早地發(fā)布出去，然后根據(jù)監(jiān)測數(shù)據(jù)再快速迭代。

　　我跟國內(nèi)的一些創(chuàng)業(yè)公司就產(chǎn)品開發(fā)流程進行過溝通，希望硅谷公司的思路可以帶給他們啟發(fā)。然而，F(xiàn)acebook的這些做法不一定適用于中國的互聯(lián)網(wǎng)企業(yè)。 在Facebook，很多時候是在證明你不行之前，假設(shè)你有能力完成一件艱巨的任務(wù)。由于Facebook招的人都是最頂尖的，這種假設(shè)在多數(shù)情況下被證明是可行的。

　　本文節(jié)選自印刷工業(yè)出版社《打造Facebook：親歷Facebook爆發(fā)的5年》一書。特此感謝作者王淮的授權(quán)。本文選登時有刪減。

it知識庫：解密Facebook產(chǎn)品的開發(fā)流程，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。