解密Facebook產品的開發流程

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

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

　　描繪遠景，設置目標

　　做每件事情之前都要有明確的目標，在聚焦于細節之前要有大的遠景(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等)。不管你做沒做計劃，所有的決定都圍繞著這四個方面進行考量。如果進度拖后了，那么可以去掉或精簡一個功能，或者推后完成的時間，或者增加人手、加大投入，或者降低質量等，無非就是在這四個方面進行取舍。

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