業(yè)務驅(qū)動下的技術逆襲_第1頁
業(yè)務驅(qū)動下的技術逆襲_第2頁
業(yè)務驅(qū)動下的技術逆襲_第3頁
業(yè)務驅(qū)動下的技術逆襲_第4頁
業(yè)務驅(qū)動下的技術逆襲_第5頁
已閱讀5頁,還剩85頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、業(yè)務驅(qū)動下的技術逆襲技術創(chuàng)新 變革未來摘要多數(shù)組織中,技術團隊常常成為象牙塔中的人他們被刻意地隱藏在產(chǎn)品團隊或業(yè)務分析團隊這樣的前置團隊的背后,并將其工作結果依照流程交付給下游的運維實施實施團隊。而另一方面,多年來對研發(fā)人員的描述過多的理想化和簡單化,使他們看起來像一群敏感、單純、更喜歡和機器打交道的Nerd?;谶@樣的分工與暗示,技術團隊往往被動或主動地定位成需求的實現(xiàn)者或系統(tǒng)的制造者,習慣于成為流水線上的一環(huán)。但在業(yè)務高速發(fā)展的階段,在大量業(yè)務需求要快速交付以及現(xiàn)有業(yè)務要高效運轉(zhuǎn)的壓力下,技術團隊及其系統(tǒng)的表現(xiàn)卻差強人意。此時,技術團隊和業(yè)務團隊往往陷入相互指責境地。技術團隊的效率、質(zhì)量等

2、問題往往是有著實際證據(jù),但技術團隊的壓力并不輕松,工作認同度很低,團隊氣氛壓抑,創(chuàng)新匱乏,人心浮動雖然多數(shù)團隊會嘗試流程上的改進,以及使用新技術再建系統(tǒng),但如何能夠在業(yè)務高速運轉(zhuǎn)的情況下保證成功的實施。更進一步,在這一過程中如何積極的進行團隊構建,觸及問題的根本,將技術團隊打造成為創(chuàng)新的驅(qū)動力量,徹底跳出新一輪的問題循環(huán)。業(yè)務驅(qū)動下的技術逆襲亞馬遜的EFP是外部供應鏈平臺。在20122014年,其技術團隊分布在西雅圖和北京,而業(yè)務團隊則分布在美國、英國、法國、德國、日本、印度和中國等國家。中國團隊主要負責了供應商入駐、業(yè)務處理系統(tǒng)的核心、后臺管理系統(tǒng),以及數(shù)據(jù)分析工具(后期建立)。2012年1

3、2月,我從研發(fā)(SDE)轉(zhuǎn)技術管理(SDM),由需求預測團隊加入負責供應商入駐的技術團隊。其時,在2012年全年,供應商入駐系統(tǒng)的線上報障有近3000+,而Sev2的問題一周8個左右。業(yè)務層面,供應商的入駐時間平均需要3個月。而新業(yè)務的嘗試和調(diào)整需要大量的代碼改動(業(yè)務邏輯分布在幾十個文件中)和長時間的交付。這種情況下,業(yè)務團隊和技術團隊的沖突非常強烈,技術團隊的士氣很低,團隊內(nèi)部氛圍相互推脫指責,EFP整個團隊的業(yè)務和技術人員流動率非常高。接管該團隊至2013年9月,使用DDD重構的整個Onboarding系統(tǒng)上線,在線報障逐步降低了%60+,Serv2問題降低到23個月1個。同時,新功能的

4、開發(fā)時間大大縮短。之后,技術團隊開始主動為業(yè)務的運營提供支持,在技術團隊的推動下,供應商入駐時間從50天降低到1周,并為進一步優(yōu)化打好基礎。另外,技術團隊和業(yè)務團隊建立起良好的合作反饋機制。團隊成員從最初的4人擴張至8人。9個月的時間從工程師到技術管理從疲于應付到有執(zhí)行力從老系統(tǒng)到新系統(tǒng)從被業(yè)務指責到驅(qū)動業(yè)務優(yōu)化發(fā)生了什么?問題、應對和思考1. 試探2. 分析3. 沖突4. 團建5. 逆襲復盤EPISODE I 試探(14周)1. 認識團隊2. 認識系統(tǒng)與業(yè)務1. 了解團隊開發(fā)情況2. 了解整體流程3. 認識業(yè)務方4. 收集業(yè)務方初步反饋1. 建立(梳理)業(yè)務與研發(fā)的溝通與反饋渠道2. 規(guī)范計

5、劃過程3. 調(diào)理團隊氛圍團隊成員:空降的情況下,要盡快了解團隊成員的情況。如果有條件,可以單獨和資深員工私下先接觸。通過其他人側(cè)面了解團隊成員的情況:性格特點,技術能力,是否負責任等等系統(tǒng)與業(yè)務:收集與系統(tǒng)和業(yè)務相關的資料安排團隊相關人員講解具體業(yè)務和系統(tǒng)。講解過程中可以重點詢問系統(tǒng)和業(yè)務存在的問題(從研發(fā)的角度)了解上下游系統(tǒng)與業(yè)務,并了解其接口人,盡早進行接觸自己開發(fā),問題多自己開發(fā),問題多基于公司標準,問題少每周1次電話會議郵件需求不多主要是維護,問題不多郵件新需求多(來自供應商的,來自EFPM)問題多工作量不飽和工作量過飽和業(yè)務方與團隊情況:了解需求的來源(業(yè)務方)渠道與溝通方式了解各

6、業(yè)務方的情況:需求量,對應系統(tǒng)的情況等。尤其是業(yè)務方對研發(fā)情況的反饋。了解當前項目進展的情況,了解團隊成員的工作安排需求研發(fā)+運維了解整體流程:需求的提報方式方法研發(fā)如何排期和開發(fā)測試和運維如何進行了解各階段的銜接情況:如何銜接,是否有瓶頸等研發(fā)人員完成全部工作,包括7*24oncall有一套非常完善的基礎設施,研發(fā)和部署效率很高重點舉措構建信任感:依據(jù)業(yè)務初步反饋,找到重點問題解決,快速建立業(yè)務和研發(fā)的信任感。進行初步團隊建設,調(diào)理團隊氛圍,建立團隊成員之間的信任感。構筑管理者與團隊的信任感。業(yè)務反饋研發(fā)慢研發(fā)不透明反饋不及時系統(tǒng)問題多團隊反饋業(yè)務雜事多系統(tǒng)問題多成員之間有隔閡溝通混亂缺乏信

7、任目標不一致構建溝通渠道需求渠道所有需求先歸口到經(jīng)理,由經(jīng)理統(tǒng)一管理。業(yè)務人員不能直接找研發(fā)人員。問題反饋建立業(yè)務與研發(fā)的定期對接,安排每周一次與業(yè)務的對接會議,了解需要幫忙跟進的事項。執(zhí)行反饋在周報中關注研發(fā)計劃和問題根據(jù),將業(yè)務方作為周報的關注者,使其了解進展情況。規(guī)范計劃過程場景走查相關人員(甚至是整個組)在業(yè)務流程和系統(tǒng)操作流程上將PRD的需求串聯(lián)起來,這樣做有如下好處:讓研發(fā)人員對所做的事情達成共識構建整體業(yè)務流程的全貌形成整體產(chǎn)品的感覺防止業(yè)務和功能上的遺漏統(tǒng)一研發(fā)和業(yè)務的溝通語言規(guī)范計劃和溝通過程敏捷計劃在場景走查基礎上,由團隊將任務切分到23人天,以此安排兩周內(nèi)的工作。引入任務

8、墻,以便第一時間了解項目的進展狀態(tài)以及資源安排情況每日站會站會起到兩個作用:第一,讓團隊成員有一個時間彼此溝通,第二,每日跟進項目推進的情況回顧/復盤早期采用標準的回顧會議方式,幾次后由于團隊人數(shù)有限,我們開始以座談的方式進行復盤,識別改進點。調(diào)理團隊氛圍每日站會團隊在固定的時間相互溝通和熟悉調(diào)整座位將FNLP的兩位同事調(diào)整到DS的大團隊中,整個團隊坐到一起,加強歸屬感,并消除溝通上障礙。調(diào)整團隊名稱將DS Onboarding和FNLP統(tǒng)一為EFP NM(Node Management),對外對內(nèi)統(tǒng)一對團隊責任的認知。責任共擔革命友誼的建立需要一起扛槍打仗,因此,工作上必須有交集。這種交集早

9、期通過共同輪值來建立。從長期看,F(xiàn)C方面的需求會越來越少,而DS問題很多,后期需求會一直穩(wěn)定。因此,負責FNLP的兩位研發(fā)同事必須介入到DS的開發(fā)中,但此時他們?nèi)孕杼幚鞦C方面的需求,所以,負責FNLP的兩位同事先參與到DS的輪值工作(oncall)中來,并明確DS的兩位同事在初期必須全力輔助配合。與大齡強力程序員建立頻繁的非正式溝通:放低姿態(tài),增加熟悉程度。借抽煙一起聊天,聊孩子、聊攝影、聊團隊了解他的想法,也讓他了解我的想法,并征求他的意見我的感受:茫然焦慮緊張團隊的感受:陌生懷疑EPISODE II 分析(58周)穩(wěn)定推進新舉措面向問題,深入分析建立1對1溝通深層問題浮現(xiàn)與處理:淺層問題

10、處理見效快,易于獲得好的反饋,利于構建信任感和自信心。深層問題之后會逐漸出現(xiàn),它們需要更多數(shù)據(jù)、更深入的分析,需要關注長期的解決方案,也需要更好的執(zhí)行力進行推進。在團隊的層面上,需要更深層次的了解團隊和團隊成員,建立一種定期的、有目的性的溝通機制。1對1溝通:每2周與團隊成員進行3060分鐘的單獨溝通溝通內(nèi)容:團隊成員的感受(滿意的地方,不爽的地方有什么建議或需要幫助推進的地方)團隊成員的個人目標(最好與團隊目標相契合,一起分析,落實到計劃和雙方的行動,每次溝通進行檢查)對團隊成員進行反饋(好的正面肯定,不好的一起分析,給出建議:行為-影響-建議)好處:成員情緒管理,及早了解可能的異動幫助成員

11、進行目標管理按自己的領導風格對團隊進行改造重點舉措需求研發(fā)為什么慢?研發(fā)人員負責開發(fā)與運維2012年,3000+ tickets,其中workflow的ticket有1000+,而operation request的ticket有1000+2013年平均每周60個ticket,其中8個Serv2 ticket需求對接研發(fā)+運維從數(shù)據(jù)入手,分析運維工作的情況,如何應對?Serv2 ticket非常影響研發(fā)人員的工作,必須盡一切可能消除。因此,對每周Serv2進行RCA分析,給出到短期和長期解決方案,落實到人(外部團隊)和時間,積極推動。(1個月后每周Serv2降低到2個左右,2個月后降低到每周1

12、個,重構開始前已降低到每月1個左右)歸類分析所有Operation Request,將重復出現(xiàn)的工作工具化,提供給業(yè)務方使用。(修改IOG等)分析前一年的所有workflow問題,進行歸類,按重復次數(shù)和修改的難易度進行歸類和排定處理順序,落實到人和時間,積極推動。(deprecate stanza等)關注每周、每月、每季度ticket數(shù)量,了解運維工作變化趨勢,持續(xù)向合理推進。(以上工作的在重構前使ticket每周降低到30個左右)通過分析還發(fā)現(xiàn):DSC系統(tǒng)設計很差、耦合度高,業(yè)務邏輯散布在不同的JSP和Java文件中,這是造成研發(fā)慢重要原因之一。舊workflow欠缺很多機制,有些相關tic

13、ket無法從根本上解決??此埔貥婦SC和workflow,但無法第一時間做。(為什么不立即做?因為沒有明確重構的目的和必要性,缺乏數(shù)據(jù)支持)通過1對1溝通逐步構建出團隊畫像團隊畫像:我的感受:茫然焦慮團隊的感受:開始感受正面反饋初步信任相互開始熟悉,但無深入合作EPISODE III 沖突(912周)明確技術方向明確研發(fā)方向(與資源準備)凝聚團隊人才盤點與梯隊建設成員沖突處理績效考核與人員取舍技術方向:團隊要在技術的采用上達成一致的認識??梢酝ㄟ^團隊的tenet來明確技術與業(yè)務的關系。優(yōu)先使用成熟技術,不要盲目嘗新。如果公司提供了基礎架構和工具,就不輕易重復造輪子。后續(xù)業(yè)務,不再使用有問題的

14、技術或工具,停止產(chǎn)生新問題(技術債)。自己開發(fā),問題多公司有DJS歷史悠久自己開發(fā),問題多基于公司標準技術成熟問題少無法維護耦合,問題多需要重構不直觀要廢棄研發(fā)方向:明確產(chǎn)品(或業(yè)務)的演進路線圖(在一個具體的時間跨度內(nèi),業(yè)務或產(chǎn)品將要處理的工作)??梢宰约号c業(yè)務對接確定,取決于產(chǎn)品(或業(yè)務)情況以及相關人員的水平,路線圖的時間跨度可長可短,內(nèi)容可以細致也可以粗略。讓團隊明確今后的研發(fā)重點,因此,需要整個團隊參與。可以根據(jù)研發(fā)方向及早明確資源(HC)的準備計劃。人才盤點與梯隊建設:明確關鍵崗位的要求,明確關鍵崗位對人員的要求通過關鍵維度來衡量團隊成員,識別關鍵人才。簡單的考慮績效和潛力,復雜的

15、可以考慮目標和價值觀(亞馬遜使用Leadership Principle)。重點找出核心成員和高潛力成員,重點關注和培養(yǎng),優(yōu)先防范核心成員的流失。核心成員必須建立后備,針對后備制定培養(yǎng)計劃。防止由人員造成的知識單點,做好成員互備,知識積累。通過項目促使核心成員培養(yǎng)新人,釋放和固化知識與非技術能力(責任感和執(zhí)行力)。成員沖突:鼓勵一定程度的觀念沖突。但要對事不對人,批評必須要有建設性。團隊領導要以身作則。一旦開始針對人,早介入,早處理,防止擴大化。一旦發(fā)生嚴重問題,明確原則,及時止損,做好各方安撫,避免矛盾再次發(fā)生。必要時要做好丟車保帥的準備(犧牲非核心員工),迅速解決。要從人員之間的矛盾尋找根

16、源,針對性解決根本原因??冃Э己耍阂锌陀^的數(shù)據(jù),簡單的可以考察交付的數(shù)量與質(zhì)量直接領導的評價360度反饋,考察來自同事和客戶(業(yè)務)的意見。重要性按照:數(shù)據(jù)直接領導評價360反饋要避免更高層領導的干預。盡量公平(平時要注意防止團隊馬太效應)重點舉措關鍵項目:在明確了技術方向的基礎上,我們需要一個新業(yè)務的開發(fā),證明未來系統(tǒng)重構的業(yè)務價值,同時建立新的開發(fā)規(guī)范和團隊協(xié)作氛圍。業(yè)務價值的考慮上是為了統(tǒng)一業(yè)務和研發(fā)的目標,將未來大系統(tǒng)的重構落地到業(yè)務層面上。OP1&OP2:需要和團隊一起討論確定大致了解未來的研發(fā)重點以及安排人員招聘的數(shù)量半年期計劃:按月計劃相對粗粒度但側(cè)重點要清晰360反饋提高是目

17、的,不是為批評圍繞Leadership Principle打分,并使用行為-影響-建立來反饋。人才盤點:績效/業(yè)績能力潛力動力滿意度離職風險業(yè)績/績效潛力+動力需要成長滿足期望無潛力有潛力高潛力超出期望 5=關注人才8=自我提升人才7=穩(wěn)定人才6=穩(wěn)定人才9=提升績效者4=核心人才3=核心人才2=:核心人才1=明星人才矛盾公開化與處理團隊領導很大程度上影響團隊氛圍矛盾的根本在于張?zhí)鞄?,必須盡力屏蔽天師對團隊的負面影響。同時要收集數(shù)據(jù)改變天師對成員的看法。VF WF項目由孫和白直接對接,二師兄參與。從團隊的利益出發(fā),對人員進行安撫和調(diào)度。要依賴悟空,但要防止過度依賴我的感受:焦慮著急團隊的感受:

18、信任受挫EPISODE IV 團建(1316周)關鍵項目交付與反饋價值觀與領導風格向上管理人員招聘交付關鍵項目:通過來自業(yè)務方的反饋和歷史數(shù)據(jù)的對比,提高團隊的自信心、成就感和集體榮譽感。證明了重構的業(yè)務價值。VF WF項目交付后,WF相關ticket為0,VF node的onboarding時間從23周降低到3天左右。新的UI操作更方便。VF WF的后期調(diào)整時間在2天以內(nèi)。JP第一個VF通過新WF上線(3天)。收集數(shù)據(jù)作為績效證據(jù)。領導風格:責任感、執(zhí)行力、服務意識。執(zhí)行力需要:充分討論(決策過程) 要有反饋(中間過程,總結性反饋) 要追蹤 (落實的行動項)領導風格極大地影響團隊行事氛圍。西

19、雅圖VF研發(fā)團隊喜歡push back,為什么?要以身作則。向上管理:定期主動溝通:團隊的情況和訴求,自己的情況和訴求。了解領導未來的訴求,積極配合。遇到?jīng)Q策,做好功課,讓領導做選擇題,而不是思考題。重點舉措團隊變化直屬經(jīng)理換團隊,高級經(jīng)理換團隊西雅圖新招了高級經(jīng)理介紹團隊的歷史情況新成員從大團隊轉(zhuǎn)入新招若干人團隊氛圍趨向穩(wěn)定,能夠積極產(chǎn)出組織新老大和大團隊一起去爬野長城、睡大通鋪、談心EPISODE V 逆襲(1736周)重構 vs. 重做使用DDD,重構中梳理領域(業(yè)務)知識設計文檔化單元測試關注業(yè)務價值業(yè)務運營數(shù)據(jù)收集業(yè)務數(shù)據(jù)分析與報告推動業(yè)務自動化推動業(yè)務決策重構的前提:研發(fā)團隊穩(wěn)定、有責任感、有執(zhí)行力研發(fā)理解業(yè)務 遺留系統(tǒng)問題(技術債務)明確、可控研發(fā)團隊有確定的技術方向已有指標性數(shù)據(jù),并有收集方式重構有明確的業(yè)務目標重構有明確的范圍、期限重構的要求:核心負責全員參與積累知識關注質(zhì)量分步進行數(shù)據(jù)驗證定期復盤技術驅(qū)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論