聊聊矽谷互聯網公司的開發流程

作者 | 朱贇

出處 | 極客時間《朱贇的技術管理課》

現在很多國內公司參考了一些矽谷的開發流程，我最近從始至終參與並負責了兩個比較大的項目。這篇文章就系統的說一下開發始終吧。總的說來，我們的開發流程包括如下階段：

OKR 的設立

主項目的確立，子項目的確立

每個子項目的生命周期

主項目的生命周期

收尾、維護、復盤

由於篇幅問題，這裡就和大家分享下前面三點，對後面也感興趣的讀者，可以直接掃碼訂閱我的專欄《朱贇的技術管理課》。這個專欄，分享了我從技術到管理的辛苦歷程和經驗總結，為你講解最新技術實戰與矽谷文化。

1

第一點，OKR 的設立

所有項目的起始，應該都是從 roadmap 做起的。矽谷公司一般 OKR（Objectives and Key Results）都是自頂而下的。也就是說，先有整個公司的 OKR，然後有每個部門的 OKR，再有大組的 OKR，再到小組的 OKR，確保整個公司有著一致的目標。在這過程中，技術驅動就反映在哪些方面呢：

首先，確定 Roadmap 的過程，我們會採用（ Survey）模式，確保工程師的聲音可以準確地觸達到管理層。比如：工程師會覺得基礎架構比較薄弱，公司就會加大這一塊的支持力度。如果大家覺得開發環境很低效，就會把這個也放到 OKR 的考慮。矽谷的公司一般會分為產品組和系統架構組。總的說來，系統架構組的 OKR 里，工程師的聲音會很大。

其次，項目怎麼做，怎麼規劃，一般是由工程師來決定。OKR 只確立目標。是不是要起新的服務，是不是要沿用現有的架構，技術選型等等，這些不是 OKR 的組成部分。

最後，估算 OKR 里的目標工期的時候，我們會除去一些用來做技術創新和支持的時間，比如編程馬拉松，開源支持等的事務。谷歌的員工會給自己留 20% 的自由項目時間，這些都是時間緩衝區。

（註：OKR 是企業進行目標管理的一個簡單有效的系統，能夠將目標管理自上而下貫穿到基層。

2

第二點，主項目及其子項目的確立

一旦確立了 OKR，下一步就是確立主項目和子項目了。主項目是主要的技術或商業產品，一般由產品經理、技術經理和一些技術骨幹經過產品需求和技術討論之後，確定要做什麼（Scope），不做什麼（Non Scope）和大的里程碑（Milestone）；後面我會在「工程師、產品經理、數據工程師是如何一起工作的」一文中更詳細地介紹不同角色之間的合作細節。

一旦主項目確定了，就需要安排不同的人做不同的模塊，也就是子項目。一般團隊協作有兩種方式：一種是每個人負責一個子項目，從始至終；另一種是大家先一起完成基本框架，然後逐個需求、逐個模塊推進，最終一起完成整個項目。

下面，我來談談兩種協作方式在實踐中的優缺點對比。

第一種協作方法：每人完成一個子項目。

優點：責任清晰，每個人都知道自己的職責，工程師們也有更多的擁有感，他們可以獨立負責產品的設計、實現、測試和維護，工作貫穿整個項目過程。

缺點：如果負責某個子項目的工程師設計或者實現能力不足，由於比較獨立，這個子項目很容易成為路障或者瓶頸，工程師之間也缺乏互相學習的機會。

另外，因為是按人並行推進項目，需要根據每個人設置里程碑，管理的時候，技術管理者需要常常跟進每個人的進度，管理代價更高。代碼審核往往也只是有限的幾個人參與。

第二種協作方法：所有人一起逐次完成每個模塊或需求。

優點：工程師之間合作最大化，可以彼此協調、彼此學習、在對方有事的時候相互補位。項目管理有明確的統一的里程碑，每個工程師都有機會接觸更多的工作，每個人的代碼可以有更多人參與審核。

缺點：每個工程師的責任不是那麼明顯，很容易出現能者多勞、勤者多勞的現象。一些新人總是做一些執行或打雜的事，得不到鍛煉。

這兩種模式我都曾親身經歷過，感覺兩者各有利弊。現實中可以根據情況組合使用。比如，兩到三個人合作負責一個模塊，也可以在每人一個模塊的基礎上，將小模塊組合成大模塊。然後每個大模塊有個技術負責人（Tech Lead），對一些能力不足的工程師給予指導和支持等。

3

第三點，每個子項目的生命周期

子項目一旦確認，它的生命周期就融入到工程師們的日常工作中，內容如下。

1. 開發初期的設計文檔。一般使用可以共享的谷歌文檔（Google Docs），Quip 等。不同的人可以編輯或者評論、閱讀。一般設計文檔會先由組內工程師和產品經理審核，然後到大組評審（包括 Legal，Compliance，Finance 等等）。

如果涉及公司的整體架構，還需要發給全公司審核。參與審核的人員是所有的工程師。很多人會有選擇的參與一些設計的審核，通常技術骨幹會預留時間審核所有的技術設計文檔。設計文檔不僅包括怎麼實現，還有選型的理由、考慮的因素、支持和不支持的屬性、時間線等等。

2. 設計測試實驗，這是可選的，如果針對某個產品需求我們想知道用戶的反饋，就需要數據工程師參與設計實驗，也就是 A/B 測試。實驗中的數據埋點也會在下一步的實現中完成。

3. 一旦設計文檔鎖定，就可以開始實現了。不論是單人負責還是多人合作，實現都是按照多次代碼提交（Pull Requests）來迭代的。每次代碼提交要寫清除代碼改動的摘要和測試。並通知不同的工程師審核。

4. 所有的實現都要加入監控、日誌、預警代碼。

5. 所有實現都是隱藏在一個開關後。當代碼都就位後，就開始灰度發布。通常是先發布給幾個開發人員測試，然後到項目組，然後到其他員工（Google 稱之為 Dog Food，因為他們可以大量使用自己的產品），最後按照百分比推給用戶。

推送的過程中會結合 A/B 測試，只有測試結果顯示對用戶體驗、公司主要的指標（ Metrics ）沒有明顯的負面影響，才會正式發布給所有用戶使用。

6. 對一些需要重構的關鍵產品鏈路，有時候也會使用雙重寫入（Dual Write），就是新特性和舊特性都寫入資料庫，並通過不同方式比較兩個實現的結果。只有驗證結果一致時，才會將交易（Traffic ）從舊實現切換到新實現。

7. 最後是一些掃尾工作，包括移除用來做 A/B 測試和灰度發布的代碼開關等，有時候還會有一些次要需求的實現。

我的專欄——《朱贇的技術管理課》，今晚（7 月 27 日）20:00-24:00，將會上線 4 小時限時拼團功能。三人成團，即可享受 ￥ 49 的拼團價，原價 ￥ 68，立省￥ 19。歡迎訂閱～

此專欄囊括了技術管理、技術實踐、矽谷文化、個人成長等 5 個維度的內容。無論你是初入職場的程序員，還是正面臨技術轉管理選擇的職場中人，相信都能在此專欄中有所收穫，找到成長躍遷的最佳路徑。

今日 20:00-24:00，三人拼團，立省￥19

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！