vivo TWS Air開箱體驗：真輕 臻好聽
在vivo S15系列新機的發(fā)布會上，vivo的最新款真無線藍牙耳機vivo TWS Air也一同發(fā)布，本次就這款耳機新品給大家?guī)硪粋€簡單的分享。外包裝盒上，vivo TWS Air保持了vivo自家產
PMO 是干什么的？不就是個拉會的嘛？
這種根深蒂固的誤解，就像，你說你是學計算機的，別人以為你是修電腦的。如果你是這么想的，那這篇文章應該會重新認識項目管理，以及PMO這個角色。
我們之所以寫這篇文章，一是覺得國外傳到中國來的PMO守則、指導方針等，存在水土不服的問題，我們現(xiàn)在遇到的問題甚至可能都比國外還要復雜。二是，我們在得物飛速發(fā)展的過程中結合理論與實戰(zhàn)積累了一些經(jīng)驗，希望可以跟相關從業(yè)者探討和交流。
文章從得物技術團隊的發(fā)展不同階段遇到的挑戰(zhàn)出發(fā)，PMO在不同階段的工作方向重心，實踐沉淀，能力建設演進等。
近幾年來，得物的業(yè)務百倍增長，得物技術團隊作為業(yè)務快速擴張的重要支撐，團隊規(guī)模在2年多時間內也發(fā)生了指數(shù)級的變化，以20倍+的速度快速增長，在此過程中，得物項目管理團隊-PMO和技術er協(xié)同摸索、實踐總結出了一套得物技術千人量級的規(guī)模化敏捷實踐。
圖片
與單個敏捷團隊通常選擇Scrum或者Scrumban的模式相比，得物PMO認為需要在此基礎上選擇適合自己的大規(guī)模敏捷框架，同時需要根據(jù)團隊發(fā)展的不同階段及時調整框架，而不能照搬業(yè)界熟知的框架，需要進行自創(chuàng)和優(yōu)化。
本文將從得物技術部的敏捷迭代在落地過程中的實踐出發(fā)，對比敏捷行業(yè)敏捷實踐的共性及差異性，以大規(guī)模團隊的實踐做為切入點，以點帶面帶大家了解千人規(guī)模的敏捷迭代在得物的落地實踐。
電商業(yè)務本身屬于長流程業(yè)務，從產品上架到用戶下單再到履約，涉及到商品管理、訂單處理、支付結算、物流配送等多個方面。長流程的業(yè)務存在較重的上下游依賴情況，業(yè)務模式的復雜度疊加組織快速發(fā)展：新人快速進場、多地協(xié)同，端到端交付的協(xié)作復雜度呈指數(shù)級上升。
這些問題在不同行業(yè)、不同團隊規(guī)模、不同團隊成熟段階段都可能會遇到，大家都會有不同的切入點和解決方式，我們把上面的問題，歸因到兩類：
首先來看團隊劃分，團隊的組織形式和工作方式的選擇始終要與公司的發(fā)展階段相匹配，得物技術部從早期的100+人規(guī)模到現(xiàn)在的千人規(guī)模，過程中也伴隨著業(yè)產研團隊協(xié)作方式的變化，資源要根據(jù)公司的發(fā)展階段，以業(yè)務順利開展為第一調整目標快速做到支撐。
團隊組織方式的變化，先看下面的圖例：
圖片
可以看到在調整之前，團隊交付的組織形式是職能型的架構組織，資源按照共享的方式在使用，因為各業(yè)務都有自己的優(yōu)先級，資源使用每次都要經(jīng)過多輪溝通后才能達成一致，資源使用的溝通成本很高；在這個痛點下，與業(yè)務及產品溝通后，將技術部團隊交付組織形式進行了調整，調整后的團隊按照各個業(yè)務線進行了資源歸屬的劃分，一個業(yè)務線團隊支持著這個業(yè)務線下不同的產品或者功能交付；從這個虛擬團隊的組織形式可以看到Spotify的影子，Spotify Tribe對應業(yè)務線；Spotify Squard與該業(yè)務線下下一級的功能交付團隊相對應；Spotify Charter對應前后端等團隊的職能組織。
這樣的實踐經(jīng)過百人規(guī)模向千人發(fā)展之后，逐漸進行了沉淀，形成了最終特性團隊(Feature Team)模式設計的矩陣型組織結構，旨在與業(yè)務模式相匹配，實現(xiàn)研發(fā)協(xié)同與管理模式的有效設計。該組織設計涉及橫向職能維度和縱向交付維度的雙向發(fā)力，具體體現(xiàn)在以下方面：
根據(jù)業(yè)務領域劃分特性團隊：將研發(fā)職能團隊劃分為多個特性團隊，每個團隊負責一個或多個業(yè)務板塊的研發(fā)交付工作，實現(xiàn)持續(xù)端到端交付用戶價值。
設置業(yè)務域PM統(tǒng)籌各職能角色：業(yè)務域PM負責統(tǒng)籌各職能角色，協(xié)同推動特性團隊實現(xiàn)業(yè)務目標。
職能TL專注組織發(fā)展：組織建設、人才發(fā)展，通過招聘、培訓和指導，提升團隊成員的技術能力和職業(yè)發(fā)展。
職能TL專注架構演進：職能TL聚焦技術基建、架構演進等工作，推動技術發(fā)展和創(chuàng)新。
通過這種組織架構設計，得物技術部能夠實現(xiàn)跨職能協(xié)作、端到端交付、業(yè)務目標導向和技術創(chuàng)新驅動等目標。特性團隊模式的應用有助于提高團隊的敏捷性、創(chuàng)新性和協(xié)作效率，使得技術部門更好地適應快速變化的市場需求和業(yè)務挑戰(zhàn)。
圖片
得物敏捷迭代在推廣落地過程中并沒有死搬硬套行業(yè)內的一些敏捷框架，諸如團隊級的敏捷框架Scrum甚至是組織級的大規(guī)模敏捷框架SAFE等，而是結合自身業(yè)務和團隊的特點，借鑒和落地好的敏捷實踐，形成了自己特色的解決方案。
其次我們來看業(yè)產研的協(xié)同，除了在組織架構的設計上保持靈活性之外，還結合敏捷項目管理方法，定義了適合得物產研的協(xié)同模式。
敏捷開發(fā)中，產研交付以用戶價值為導向，傳統(tǒng)項目管理的鐵三角（成本、時間、范圍）轉變?yōu)椤凹s束”，在固定的時間周期內（Timebox），結合可用資源，交付高價值&高質量的需求。
圖片
需求在沒有上線之前只是假設（假設這樣做可以解決用戶的問題），敏捷開發(fā)中，通過需求拆分，高優(yōu)先級需求識別及迭代交付機制，盡快將一個需求從提出推進到上線，能夠盡早收集用戶反饋，驗證需求價值，并及時響應變化。
圖片
基于以上，得物選擇了雙周迭代模式。基于的思考如下，1周時間較短，無法交付相對復雜的需求，同時對于存在App端的互聯(lián)網(wǎng)公司，頻繁發(fā)布也會打擾用戶。3周時間較長，對在做創(chuàng)新或者需要快速迭代的業(yè)務模式起不到試錯的效果。所以2周是一個相對剛好的節(jié)奏。
但是2周是一個整體節(jié)奏，并不是意味著所有需求必須等到2周才能發(fā)布，2周是最晚的發(fā)布窗口，在版本結束之前達到發(fā)布標準的可以任何時間發(fā)布，但是如果沒有趕上2周的窗口，那只能等下一趟；可以參考SAFe中的ART（Agile Release Train）的概念，火車不等人。
這里強調一下迭代周期和發(fā)布能力是要區(qū)分開的，對于APP的迭代周期來說是以兩周作為維度，但是發(fā)布是可以根據(jù)實際情況單周進行甚至任意時間點進行的動作。
得物有很多的業(yè)務線和對應的業(yè)務類項目，在每個迭代周期結束后，所有團隊都會同時調整資源的投入方向，甚至可能會在不同的業(yè)務域之間進行資源調配；在同一時間節(jié)點調整避免了因多迭代周期節(jié)奏在不同的窗口期調整帶來的協(xié)作成本并降低了人為風險。
另外，團隊規(guī)模變大后，一些效能相關度量指標及統(tǒng)計報告都會以迭代周期統(tǒng)計，如果各個業(yè)務域節(jié)奏不一，會導致數(shù)據(jù)的橫向沒有可比性，這也是在制定迭代周期時容易被忽視的地方。
最后，當解決了團隊資源和產研協(xié)同的問題之后，持續(xù)改進效率問題就變得尤為重要，在這里我們不討論coding本身的效率，一起來探討如何有效的設置研發(fā)效能度量指標才能真正的幫助到我們做到持續(xù)改進。
沒有度量就沒有改進的方向，設置合理的度量指標事半功倍，否則度量會變成笑話，給團隊帶來負面影響。
舉個簡單粗暴的例子：人均完成需求數(shù)/每迭代；我相信大家都不會選擇這個指標是因為軟件開發(fā)本身是一個基于變量（需求大小、人員成熟度、開發(fā)環(huán)境及上下游環(huán)節(jié)）進行的工作，這與機械制造行業(yè)的流水線工序是完全不同的工作，不能夠用工業(yè)標準的思維來衡量軟件質量開發(fā)。所以要做好研發(fā)效能的度量要有一些基本的原則，才能用指標更好的評估現(xiàn)狀，為團隊持續(xù)改進提供正確的方向。
得物技術部基于以上的原則制定了研發(fā)和測試過程指標，從交付速率，內建質量，持續(xù)發(fā)布能力及線上質量幾個維度定義了一系列指標，在此我們不一一展開。
對以上的思路進行整理，我們用以下一些字母來進行釋義，可以簡單的稱之為：Type-P：
在整體闡述Type-P時，為了方便理解，引用主流的規(guī)模化敏捷LESS、SAFE作為參考。
Type-P、LESS、SAFE是基于不同的背景、邏輯所構建的項目管理實踐方法，只有左右之別，不存在高低之分。借鑒意義并非是非此即彼的。
圖片
各類資源數(shù)各域固定；
各域單獨一份product backlog，業(yè)務一號位決策，域內優(yōu)先級決策高效。
在抽象出Type-P的核心原則的過程中，發(fā)現(xiàn)和Type-C的命名非常相似，也期望得物所特有的Type-P在經(jīng)過過去、現(xiàn)在、未來的努力之后，不僅是得物特色，也能同Type-C一樣，成為一種業(yè)界通用的“標準接口”，給更多同業(yè)/同行更多的參考、借鑒意義。
敏捷實踐過程的落地離不開PMO團隊，這個過程中PMO首先承擔了以下的一些工作。
這些工作其實業(yè)內大部分團隊是一樣的，但是隨著團隊人數(shù)的增多，團隊成熟度的變化，敏捷實踐階段的改變，PMO團隊的定位和方向也是隨著變化的。
從“吞吐優(yōu)先”向“價值優(yōu)先”過渡。流程落地、項目管理工具落地是在實踐過程的前期一定會去做的事情，這個落地過程中的問題也會因為各種因素層出不窮，這個階段的落地目標也會把團隊的吞吐情況作為第一目標去完成。
當落地階段完成之后，常規(guī)PMO團隊所需要完成的事項就變成了基礎工作，團隊目標也從“吞吐率”轉向了“價值”，這里的價值有兩層含義：第一是需求和項目的交付更注重業(yè)務本身的價值，形成端到端的閉環(huán)，從需求提出本身的價值角度判斷優(yōu)先級，提升團隊交付的意義。在業(yè)內，很多團隊的閉環(huán)交付受到業(yè)務形態(tài)和外部因素的影響，在尾部復盤階段會推行的很艱難。第二是PMO自身在職能團隊和業(yè)務團隊中的價值，幫助團隊找到流程卡點和人效洼地，提出改進方案和提升研發(fā)團隊效能產出。這需要PMO和團隊建立足夠的信任感，提升自身在團隊的影響力，信任感的建立不是一朝一夕的，需要在日常的工作中真正幫助到了團隊，才會逐漸形成。
這個目標看似簡單，但是實際過程中還是會有很多難點，需要得物的PMO具備更強的個人綜合實力和軟技能，業(yè)務感知力、數(shù)據(jù)分析能力、談判技巧、團隊洞察力、社交能力等，迭代和項目管理是基本盤，需要花更多的時間在技術團隊的人效提升上，哪怕是交流溝通去建立信任，也是一件花時間的事情。
本文先從團隊發(fā)展的角度，看我們遇到的一些挑戰(zhàn)；第二部分針對這些挑戰(zhàn)，不斷去嘗試解題思路；這些挑戰(zhàn)是從實際出發(fā)，結合實際問題我們歸納到兩類，一個是資源，一個是協(xié)同。那從資源協(xié)同的角度，我們怎么抽象化地解這個問題？解這個問題就兩個思路，一個是解資源的，另一個是解協(xié)同的，協(xié)同上又用到了價值導向、小步快跑和雙周迭代的思路。不管是協(xié)同、資源、還是問題也好，都會牽涉到「研發(fā)效能度量」，通過上文的思路和舉措，基本上就是把我們遇到的挑戰(zhàn)給解決了。另外，也補充說明了得物特色的敏捷管理思路Type-P，區(qū)分主流項目管理框架，因地制宜，打造了得物特色千人敏捷項目管理。
每家公司所處的行業(yè)，階段各不相同，敏捷宣言也已經(jīng)從1.0升級到了2.0，隨著AI時代的到來，符合各自敏捷場景的落地又會有更多的變化和挑戰(zhàn)，希望通過上面的一些介紹，能給大家在敏捷落地過程中有一些啟發(fā)，也希望大家可以擁抱變化，一起交流，共同進步，開創(chuàng)一個屬于我們自己的敏捷時代。
本文鏈接：http://www.tebozhan.com/showinfo-26-80830-0.html千人規(guī)模敏捷迭代實踐分享，你學會了嗎？
聲明：本網(wǎng)頁內容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： .NET WebAPI 自定義返回類：實現(xiàn)統(tǒng)一與靈活的API響應
下一篇： 面試官：聽說你很懂線程池？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號