Lyft高管教你如何管理技術團隊

新聞 06-02

行走在舊金山的街頭，你一定曾見過裝飾成這樣的車：

戴著萌萌的粉色裝飾，行駛在夜幕下的城市中，這些看起來頗為可愛的車並不是因為司機大叔們突然地童心萌發，抑或行為藝術——它們來自 Uber 在美國最大的競爭對手 Lyft。

同樣是總部位於舊金山，Lyft 可以說是 Uber 在美國市場中的主要競爭對手。在時刻與對手強力競爭的情況下，不僅在市場營銷策略方面不可有所疏漏，產品技術的全面支持和引導更是不必可少。要實現用技術工程文化幫助提升產值效率，打造對研發工程師和管理者有積極影響的工程團隊文化是重中之重。

沈思維畢業於密歇根大學和卡內基梅隆大學。他早年在 Google 任軟體開發工程師 (2005 - 2011)，2011年加入 Twitter，後任產品安全部高級研發經理，負責反垃圾及帳號安全方面的工作。2015年底至今在 Lyft 擔任研發總監，負責包括支付平台，風控平台、開放平台在內的多個團隊。工作之外，沈思維關注並致力於提高科技行業里中國人的職業規劃發展。

我們也邀請沈思維在矽谷Live平台上分享更多管理技術團隊和矽谷工程團隊文化的，文末有報名鏈接。

營造正確的團隊文化

Lyft 開放平台（Public API Platform）是對 Lyft 主 app 的延伸，包括 Lyft 企業版、禮賓服務、與酒店航空等其它行業的合作對接，以及與其他平台的深度整合與資源共享。打造推廣公共開放平台涉及公司各方面，除了技術團隊外，還覆蓋了產品、設計，售前售後技術支持、運營、商務、銷售、市場、法務等等。

對於這樣多個職能部門合作，業務覆蓋面廣的大型項目，除了需要高質素的研發人員之外，良好的團隊文化至關重要。

營造正確的團隊文化有兩個直接的目的：提高團隊效率；促進人才培養。本文以上面這個案例為背景對團隊的技術工程文化做深入的分析，側重點放在企業團隊文化對研發工程師和管理者的要求和影響。

全棧型組織架構

健康的技術工程文化需要一個合適的組織架構來支撐。拿近幾年流行的全棧（full stack）概念來說，比起傳統按技術領域分組，全棧式的技術團隊的主要優點是消除了一些跨部門合作的壁壘，減少團隊對於外部其它組的依賴。

以往前後台研發通常是分開的，現在的做法是讓每個項目都有屬於自己的前台、後台，伺服器端和移動端，甚至專屬的測試、數據分析部門。在一些較大規模的公司里，還出現了把技術、產品、運營從組織架構上深度配套，組成一個事業部並統一管理的結構，以保證相互間的高度同步。這就把全棧式團隊的意義進一步推廣到了技術範疇之外。即便如此，設計、商務、銷售、市場、法務等這些不可或缺的職能部門，仍會因為資源有限，而難以分散在各項目中。所以全棧式的團隊不是萬能葯，有了全棧式的研發團隊，依舊要考慮如何讓跨職能部門的合作達到無縫高效。

全棧式也有資源重複、技術實現缺乏統一性，以及限制個人發展等缺陷。把研發團隊按照技術職能分組，雖然容易造成瓶頸，甚至導致各部門搶奪資源的情況。但是按技術背景的劃分結構，統一技術架構設計模式代碼規範往往可以做得更好。此外，全棧式團隊中某些技術領域的工程師會落單，出現沒有全職工作量的情況，即「衛星工程師」（satellite engineer）。全棧式的組織架構雖然對總體團隊效率有利，但對衛星工程師的職業發展不是最佳的選擇。

這裡有兩個常見的對策。

首先，鼓勵盡量多的研發人員變成全棧工程師；其次，對於每個技術領域形成跨團隊的「虛擬組」（virtual team）。每個虛擬組應該定期地交流討論，以此確保各個團隊之間在同一個技術領域的技術上的一致性兼容性。

團隊有了全棧的技術能力，隨之而來的問題，是如何分配做產品功能和做基礎架構的研發資源。

初創公司經常犯的錯誤，是把所有的研發資源都投入到做產品追求最大化的增長速度。雖然這樣短期效果喜人，但隨著產品的複雜化，會出現「技術債務」，即基礎平台的不健全會阻礙新產品功能的實現。

為了杜絕技術債務，全棧式研發團隊在任何階段，都應當有組合型的工作規劃（portfolio aproach），平衡產品研發投入和對基礎架構上的投資。這與資產投資的理念相似，即將短期與長線相組合。因而一個公司的技術團隊所有的組都發展全棧式是不可取的，過度的全棧是一種「組織債務」（organizational debt）。

不受限的研發團隊

在 Lyft，我們使用OKR（Objectives and Key Results）進行季度規劃，即目標和關鍵結果。因為谷歌全面採納 OKR 的巨大成功，很多公司爭相效仿。OKR 用於對公司、團隊，甚至個人每季度的工作做規劃、追蹤，和衡量。

Lyft 公共開放平台的所有團隊都各自製定了OKR，並連續多個季度近乎完美地達到了預期的結果。然而，當回頭看核心數據時，月活躍企業版訂單的增長曲線並不像 OKR 打分那麼令人滿意。在總結調查中我們發現，增長不給力的原因是企業版功能複雜、流程冗長——傳統行業的企業客戶因大幅的數據及賬戶遷移門檻太高，望而卻步；潛在合作公司發現產品不支持其獨特功能需求。這直接導致了這些客戶的離開。

這裡有兩個問題：第一，在開發之前，團隊就已了解所有的產品要求，但是為了在預定期限內完成，不得不放棄部分功能；第二，產品的用戶體驗不好，而OKR 打分卻很高，這說明 OKR 定得有問題。

產品開發中，因為時間壓力而減去部分功能，這樣的現象在科技行業司空見慣。為了趕進度放棄部分功能，研發往往想讓產品經理背鍋，但被排除的功能是否重要，需要實踐測試。但這時候研發推脫道，界面設計太慢，Beta 測試來不及，項目優先順序不夠。

與其說是研發團隊推卸責任，倒不妨客觀地把問題想成是不同職能之間合作的必然產物。在資源有限的情況下，我們應當從研發團隊入手，從技術工程文化上做改進，尋找技術可控的解決方案。

技術團隊的主導地位

首先是「產品決定（product decision）」的謬誤。我們需要一種文化，讓工程師對產品有強烈的主人翁意識；讓他們有自主權和權威去履行職責。我們倡導研發人員對其開發的軟體質量和用戶接受度全權負責。

如果產品用戶體驗不好，無論代碼多好，開發者依舊需要為此承擔負責。在 Lyft 剛開始推行此理念時，很多工程師覺得不合理。然而，用戶最需要最喜歡的體驗到底，是需要嘗試需要更新迭代不斷摸索的。在尋找到解決方案之前，所有人都不能認為自己已完成工作。作為技術人員，也要對產品的成功與否負責。

在很多公司，每當產品發布，產品經理常常會發一封熱情洋溢的感謝信，把公司上上下下謝個遍。Lyft 的做法是讓技術主管（Tech Lead）發信，除了對功能、產品的簡單描述，必須包括初步統計數據——任何影響終端用戶的產品改動，都需要經過分階段發布的過程，初步統計數據即在此時獲取。在宣布產品推出市場的時候，應清楚地說明成功標準及衡量方法。

換句話說，發布一款產品本身不值得慶祝，值得慶祝的是被用戶接受從而給公司帶來收益；而這樣的電子郵件由技術主管來發，是為了明確技術團隊的主導地位。

Lyft 企業版研發中的另一問題，是缺乏用戶流程迭代和Beta測試。此時，研發團隊將問題推給了UX設計：一直沒有給出完美的設計（pixel perfect design），這種思路是不對的。工程師應懂得如何讓自己不被受阻，在必要時做決策。對於Lyft，在我們面臨的競爭環境里，必須要讓每個人在存在未知的情況下有自主權去嘗試。雖然難免有錯誤，但是贏得了速度，得到來自用戶的實時反饋。

設計團隊應傳授設計原理給其它部門，尤其是研發和產品人員。在許多項目的初期，鼓勵工程師和產品經理在設計團隊的協助下，甚至是獨立於設計團隊地做自主設計選擇，會大大提升效率。通過高頻的迭代測試，從隨機抽取的小部分用戶實際使用情況，從而確定產品功能選擇。技術和產品團隊也可以給設計團隊講解不同設計的所對應的工程成本。在特殊的情況下，不是百分百完美的設計可以在不影響產品質量的情況下，大幅降低研發，帶來意想不到的好結果。

眾所周知，好的產品來自反覆試驗和快速迭代。在需要跨部門合作的項目中，增加人手並不直接解決問題，此時需要有一個技術工程文化，去鼓勵研發人員突破框架，扮演不同的角色。

讓研發人員跳出技術的束縛，扮演不同的角色，也是他們職業發展的關鍵。在職業起步初期，提高意味著對某一領域更深入的了解。隨著成長，知識結構和綜合能力應成為一個T字形——這也是目前矽谷各大公司競相追逐的人材類型。具有T字形能力的人，精通一個或某幾個領域，但對專業以外的其它職能有興趣，並敢於涉足。

以被替換為目的的管理模式

技術工程文化的另一個重要元素，是技術研發經理的角色扮演。對於管理職位的定義，中美有所不同。在國內或其它亞洲國家，管理職位常被視作一種晉陞；而在西方，管理是一種不一樣的職能，強調管理和技術的獨立性，淡化管理和研發之間的從屬關係。一名研發人員的事業的發展，可以鑽研技術，也可以選擇管理，或者均有嘗試。但無論如何，要創建一個健康的團隊文化，管理者起到決定性的作用。

首先，管理者應該把自己看作教練，而不是試圖成為最好的球員。很多技術研發經理曾經都是的工程師出身，當初次擔任管理角色時，他們往往正是團隊中最資深的工程師，此時要適應逐漸放手讓團隊中的其他人去做決定。當管理者寄希望長期扮演雙重角色，既是團隊的經理也是技術主管時，自身的效率會限制團隊的效率。

關於管理有一個常見的誤區：如果不負責技術細節，技術經理就只能專註於處理人事。這是很多優秀的工程師難以適應管理工作的一大原因——他們不願意只管理人事，認為體現不了自我的價值。作為管理者，也必須要對團隊業績負責。不是為了處理人事而處理，一切都是為了團隊利益。當管理者授權了團隊的成員做所有技術決策後，需要把自己的時間花在其它正確的事情上，間接地為業務目標做出貢獻。

在 Lyft 公共開放平台案例中，包括了與第三方的合同談判，對用戶流量的預估，競爭對手的分析比較，營銷推廣手段等等。技術管理者在這些工作中的跨界不僅加快了進度，也對自己管理能力有所提升，更是增加了作為技術管理者對商務的認知度和敏感度。

管理者的另一重要任務，是時刻尋找能夠取代自己的人。聽起來荒謬，但事實上，培養接班人是最有效的推動自己不停進步的方法。當發現下屬已經可以完全擔當自己的角色，管理者就會有危機感去發掘更大的舞台，拓寬自己的業務。

優秀管理者應必備的特質，是要勇於展示自己的弱點。正視自身的不足，會讓周圍的人感受管理者的真實，也會讓團隊的人意識到他們自己不可或缺的角色。最好的點子往往在別人的腦子裡，作為管理者如果不能溝通不能贏得信任，就無法激發那些有最佳想法的人的潛能。

統一全面的績效衡量

單個職能部門的業績（OKR打分）和總體業務 KPI 之間如何脫鉤？解決方法非常直接：讓項目中各職能部門在制定 OKR 時都使用統一的績效衡量指標。

什麼是最好的統一績效衡量指標？最直接的即為總體業務KPI本身。但實際操作起來，僅用總體業務 KPI 做指標未必能很好地衡量具體工作。所以每個部門內部仍需有細分的針對性指標，但必須堅持用總體業務成績決定的各部門的最終打分評估，從而杜絕某些部門因追求表面業績而避重就輕。

除此之外，對於每個有關增長的目標，應添加一個相關產品質量的槓桿指標。任何一項指標，都會將我們的注意力引向它監控的東西。對於庫存，需要監控的槓桿指標就是供應短缺發生率。把槓桿績效指標用在互聯網產品研發上，在大力推動用戶增長的同時，必須關心用戶使用反饋，否則就是刷數據，而非真正地解決用戶的痛點。

從團隊組織架構，到研發人員突破框架擔起責任，再到研發經理管理者的角色，最後是團隊之間使用統一全面的指標，這是Lyft 的公共開放平台近半年從技術工程文化上做的一些改進，效果是極其明顯的。

公司的規模發展階段，以及宏觀的經濟情況和市場走向，都會影響我們的決策。在中國，競爭激烈程度可能導致我們必須調整或放棄對一些文化元素的追求；在美國，由於優秀技術人才資源更緊俏，對公司的運作效率提出了更大的挑戰。

本期矽谷 Live 邀請到了 Lyft 工程總監沈思維，為大家分享他在 Google、Twitter 和 Lyft 等公司的技術工程管理實踐中總結的六項技術工程原則：

本期Live圍繞以下主題：

研發責任制，包括自主權、對結果負責等話題以及注意事項

數據迭代，包括數據定義優先順序、數據評價績效等話題

迭代式發展，包括遞增實現大目標、靈活轉向等話題

組合型規劃，包括人才輪換、杜絕技術債務等話題

客戶為先，包括確定主要用戶、槓桿指標等話題

統一性，包括組織獨立、技術統一、可再用性等話題

答疑將圍繞如何管理技術團隊展開

適用人群：