解密Facebook產品的開發流程(2)

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

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

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

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

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

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

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

　　指定項目責任人

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

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

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

　　定期碰頭會

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

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

　　了解進度　匯總報告

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

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

　　發布產品　監測數據

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

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

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

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

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

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

原文轉自：http://kb.cnblogs.com/page/173482/