歡迎光臨
每天分享高質量文章

女博士工程師:聊聊硅谷互聯網公司的開發流程

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

  • 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 塊錢哦 



赞(0)

分享創造快樂