解密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招的人都是最頂尖的，這種假設在多數狀況下被證實是可行的。