女博士工程師：聊聊矽谷網際網路公司的開發流程

之前很多文章或多或少已經說了一些點，現在很多國內公司也參考了一些流程，最近從始至終參與並負責了兩個比較大的專案。這篇文章就係統的說一下開發始終吧。總的說來，我們的開發流程包括如下階段：

• OKR 的設立

• 主專案的確立，子專案的確立

• 每個子專案的生命週期

• 主專案的生命週期

• 收尾、維護、復盤

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



第一點，OKR 的設立

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

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

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

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

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



掃碼即可訂閱我的專欄

第二點，主專案及其子專案的確立

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

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

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

第一種協作方法：每人完成一個子專案。

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

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

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

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

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

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

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

第三點，每個子專案的生命週期

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

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 測試和灰度釋出的程式碼開關等，有時候還會有一些次要需求的實現。

我是朱贇，極客時間專欄《朱贇的技術管理課》出品人，計算機博士，前Airbnb技術經理，公眾號“嘀嗒嘀嗒”作者。

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

歡迎訂閱～

 使用我的二維碼，可以減 6 塊錢哦 

 使用我的二維碼，可以減 6 塊錢哦 

 使用我的二維碼，可以減 6 塊錢哦