摘要
本文為網易有道企業發展高階效能專案經理張浩然《研發效能實踐助力網際網路行業專案管理“行之有效”》的演講內容，圍繞研發效能的實踐和專案管理兩個主題展開。
我寫分享PPT的時候，起初想的是針對於網際網路行業的專案管理。但現在不止是網際網路，傳統行業也在做數字化轉型。所以，這個專案管理是全行業都可以一起探討的。我之前做研發，後面主要做專案管理，過程中做過一段時間的產品管理。目前主要在網易有道企業發展部，做整個研發效能的推廣和專案管理的提升。
我將從四個部分來闡述下自身的分享主題。
1.網際網路專案管理面臨的常見挑戰
目前我們處於一個烏卡時代，不光是網際網路，傳統行業也處於這個時代。任何一個時代到來，都不會拋棄任何一個人，這個時代有哪些特殊性？——易變，不確定性，複雜性和模糊性。
所謂易變，就是每次迭代開發要快，因為市場變化很快，我們其實也不確定產品的下一步方向在哪，使用者有哪些新的訴求；
而複雜性是說現在產品的形態、架構很多，不能像以前一樣用一套標準的解決方案滿足各個客戶的需求。因為客戶也學聰明瞭，我們需要去應對一些更復雜且不明確的訴求。模糊性更好理解，一些大廠如阿里是電商出身，百度是搜尋引擎，但是越往後，每一塊垂直領域市場趨於飽和，大家在各自的邊界越來越模糊。所以，我們要不斷地讓我們的MVP產品快速推出，在烏卡時代取得先機。
專案管理，能在這個時代幫助企業降本增效，快速驗證。但是我們在管理整個軟體研發團隊時，多少會遇到一些問題或困擾。比如現在有一個想法需要做，我們組建了一個團隊，快速地做研發迭代。為了趕進度，大家還要加班。很辛苦，但真正交付產品的時候，還是會出現延期交付。
在研發過程中，為了趕進度多少會產生一些質量問題。在整個過程中，為了彌補延期和質量差的問題，會去抓人效，抓的過程中又容易引起團隊裡的一些反駁，導致士氣低落，如果在上線以後，我們的產品再不被市場接受，整個團隊久而久之士氣更加低落。
有人說我是一個經驗很豐富的專案管理或者產品經理，或者技術領導，我在整個排期或者任務分配的過程中都沒有問題。那我們如果有跨團隊協作，比如說網易有一個A團隊，很重視測試環節，在測試環節分為好幾輪，並且用網易易測平臺去掃描檢查程式碼。另外一個B團隊，業務形態沒有那麼複雜，只是簡單地走完測試流程就OK了，過程中沒有很多自動化工具，可能還在用XMIND等思維導圖寫用例，線下做管理。但如果B團隊的夥伴去支援A團隊的專案，對於A團隊的工具、流程都不熟悉，怎麼能夠快速讓B團隊融入A團隊，快速產出，這都會成為阻礙團隊高效產出的問題障礙。
我們現在的挑戰是會遇到交付過程慢的問題。因為我們的產品線越多，需要交付的產品就越多。在不同的過程中，針對於某一個產品有一些新的需求，需求過來以後就會建立很多版本分支。這個過程中，比如我正在開發A版本的過程插入了新需求，要新開B版本，從A切到B的時候其實是對開發有影響的。同時，比如專案前期，大家都在做一些調研，然後再開發，這個階段測試人員在等待開發完成才能進入測試，等待時間過於長，導致整個交付比較慢。質量差也是一個問題，研發之前沒有測試的意識，只寫好自己的程式碼就提交了，可能有些為了趕進度都不自測。排期不合理，大家有可能經常會遇到這種問題。排期就是把研發的時間排出來，把剩下的時間壓縮為測試時間，測試很大的一部分功能模組也就幾天，三四天，小功能的話半天就得趕緊測完要上線，所以為了去趕進度，犧牲了質量。
協作難這個問題，有多個團隊缺少標準的流程工具。在整個過程中一是出現人員的協作、專案切換難；二是遇到一些問題的話，可能會出現扯皮；最後，就是少度量。如果沒有度量的話肯定是不行的，專案經理包括管理層不知道整個團隊目前的現狀，包括技術領導也肯定沒有辦法合理地做任務分配。整個過程度量的缺失，就沒有辦法去衡量大家的績效。現在在推行OKR，其實也是有度量的，也就是KR的達成程度怎麼樣。這些常見問題時壓在團隊身上的幾座大山。
在這個過程中，會形成馬太效應。每次質量差，上線以後有問題，運維工程師變成“背鍋俠”；測試需要針對現有的問題儘快去驗證，追著開發去修復，成了“追責俠”；最後我們的開發，只能加班加點去幹，成了“加班俠”。這就是網際網路時代“三俠”，工作很累，但是結果不理想，每天還吵得不得了
2.針對這種情況，有道怎麼做探索和實踐？
第一步，發現問題。
通過訪談或者觀察的方式看目前是什麼問題。訪談是一部分，觀察也一定要有。因為整個研發團隊在工作過程中是不希望被打擾的，如果打擾到他，一是可能配合力度不夠，二是在訪談過程中可能會有一些答案是得不到的，所以在團隊人員時間緊張的條件下，需要通過觀察來發現問題。大家如果有時間，可以邀請去做共創，或者是內部的共創。同時可以把好的案例分享給我們團隊，看看他們的接受程度。
第二步，收集到一些問題，對問題做進一步的分析和定位。
我們當時收集到了從需求到整個開發構建、測試、部署包括監控等多個環節的問題。
需求的話，一開始沒有需求管理工具，大家靠書面記錄，效率比較低，而且需求更新後，下游是不可知的。沒有做需求變更管理就會導致快上線驗收的時候才發現，開發的一些功能和實際想要的完全不一樣，或者差異很大，這對團隊是一個致命打擊。包括開發構建、測試等環節也或多或少會有問題，針對這些問題我們做分析和定位，包括人、流程、工具各個方面。
針對這些，我們定了一個計劃：
首先從業務到運維多個環節對單點的工具、流程進行一些優化，終極目標是建立一套能夠從業務需求到上線釋出的端到端，能夠支援整個研發過程，快速高質量和持續釋出的解決方案。
一是要快速，二是質量要高，三是持續交付。不能是一次快，或者是一次質量好，要持續達到這個目標。
第一步，引入敏捷開發模式
第二步，從整個企業發展的層面去打造一套工具鏈，把全域性拉通
第三步，準備自建自己的DevOps能效平臺，做一體化平臺。
前期會通過一些流程規範，針對需求做基於流程的驅動。我們搭建了一套標準工作流，在這個工作流中基於不同的團隊建分支流程，儘量落在這套標準的流程上。我們希望通過一些流程，來推動整個產研的過程，不管是通過卡片還是通過自動化的工具，或者說轉化過程，通過工具去驅動，把這個資料沉澱下來。同時，在程式碼級別和測試級別，自己做了一些封裝，有些是自己去做的。CICD方面後面講，沒有完全做成自建的，會做前端的封裝。我們的產研團隊的使用者看到用的是一套平臺，在一套平臺上完全整個需求到上線的過程，對他們的感知比較友好。
CI/CD的核心流程，用tekton引擎去做的。通過一些pipeline組合，去完成整個流程管理，通過task的檔案去做整個pod的排程，實現整個過程持續的流水線。
基於這個層面，已經從產品設計到需求、程式碼去做一些構建，發到對應的環境，去做自動化的測試，完全去實現全鏈路的拉通，包括上線以後有資料看板。有了這一套全鏈路的工具平臺，就可以更好地去支撐我們的敏捷開發模式，最後一步卡在運維。
這樣的話，通過這套平臺可以得到一個需求，跑完以後快速上線，上線以後快速地驗證。驗證完以後，是否OK，具不具備釋出條件，當期釋出目前已經是OK的。
3.專案管理與研發效能的有效結合
把整個研發過程拉通，通過自建去做。我們的專案管理應該怎麼去做一些切入？和研發效能做結合。首先，在專案管理方式上做一些改進，在傳統的專案管理中有一個傳統鐵三角的概念。專案管理管理上，會針對專案的範圍、時間、成本傳統的軟體行業，更注重這三塊。比如我是乙方，給甲方簽了合同，交付一些平臺或者系統，在這個過程中會有嚴格的範圍定位。我們的立項時間分幾個月去交付，一期、二期、三期包括我們的時間、成本，甲乙方對接的時候更需要做成本控制。專案管理更多的是在這三個層面觸發，然後在過程中去做過程管理。但是這種模式，其實是需要做一些改進的。因為現在是一個網際網路時代，烏卡時代，大家不可能說在一開始就確定要什麼，給你多長時間，給你多少預算做出來，所以需要做一個轉變，這就是敏捷三角的概念.
範圍、時間和成本這三塊也要看，只是比重沒有那麼高，而是作為整個專案管理的約束條件，也就是說我們要在有限的範圍、時間、成本里面尋求最有價值的部分。
而在這個過程中，可以通過一些工具、流程把質量逐步提升。通過敏捷三角的專案管理方式，每次去交付最有價值，而不是全量的範圍，可以基於價值每次去拆分最小的單元顆粒度做mvp，如果價值有變化，快速地做調整。
其次，專案管理過程中要做一些流程改進。從專案管理角度來說，原來是一個線性的流程，一般有了專案以後，要去做立項，做可研論證，可行性研究，做整個產品的設計，UE、UI的設計，研發、測試、上線，整個過程中都是線型的。存在一個問題，如果產品的需求PRD沒有畫好，UE是不是不能做？開發是不是也不能做？
於是我們改進了流程，減少了它的前置時間。PRD沒有完全寫好，但是用這種使用者故事的形式，先給出整個使用者故事的全貌。通過最終要做成什麼樣，拆出來最有價值的部分，後面UE和開發就可以先做這個部分的需求。最有價值的部分做完以後，可以實現優先順序排序裡第二有價值的功能。相當於把整個功能拆解完以後，後續的各個流程都可以直接接入。
另外根據專案管理計劃，要做管理肯定要有一個度量體系，不然無法知道整個研發團隊的效率點，或者工作飽和的情況。允許大家存在一定的“摸魚”，但是要適可而止。有一些“摸魚"明顯不合理時，就需要做度量。
最後，專案管理裡，我們也逐步找尋健康的度量方式和體系，逐步改進過程。
短期度量是第一步上來要做的，因為沒有全流程的鏈路平臺統計，都是基於過程的度量，只能單點收集需求、開發、測試、運維各個過程的資料。專案經理比較累，需要通過excel表，手動地去各個平臺去扒，或者去其他的一些地方去問，這是比較難的。但是有了這個度量體系，基本上可以以此驅動。哪個資料現在大家看得比較重要，或者收集過程比較痛苦，就可以逐步做一些改進。
單點的資料有了，第二步就要關注交付的目標。比如這次需要交付5個還是交付10個的故事，這個過程基於整體的目標去做，在過程中會通過一些人員的效率，比如說週期，人均的效率包括缺陷的修復時間，通過整個迭代去看，而不是通過某個需求去看。另外，迭代釋出的話，看一下發布頻率或者釋出前置時間。釋出前可能涉及到環節沒有準備好，因為遇到過一些情況，大家一開始著急開發，等到快上線的時候，給測試發申請，或者又在等一個機器配置什麼的，很阻礙時間。釋出時間就會拉得很長，導致最終整個迭代的版本上線就會很長。質量是會通過一些整個過程和迭代裡面的冒煙駁回率、缺陷密度和缺陷漏測率和其他指標去做。
第三步，基於價值的度量。有了目標，但是這個目標只是說實現產品價值中間的過程，最終還是要實現有價值。以價值為導向，層層去過濾整個環節，單點去做還是通過迭代去做，層層拆解，逐步的消除。以價值的交付為導向，通過視覺化的看法或者儀表盤逐步分解，分析，提高整個研發效能的效率和質量。
這樣的結合路徑會基於產品使用者和市場三個層面做整體權衡，輸出這次最有價值的點，相當於有一套自己的價值評估體系，會融入到整個產研體系。在產研過程中會去做一些需求規劃、版本管理、時間盒，專案經理可以更有效地做過程把控。
我們的目標是希望通過整套能效平臺，可以快速地探索和分析業務，形成一個MVP，快速實現MVP的上線和驗證。
4.研發效能的未來展望
一、DevOps繼續深入，重點還是整合豐富的資料來源。
要關注資料是否有效，合理性怎麼樣，夠不夠豐富，要做這塊的資料來源整合，通過分析增加監控指標。這個深度需要更加合理，更加促進研發團隊高效工作，不破壞團隊氛圍。
二、現在已經啟動了，但還沒有形成很大的規模的AIOps。
雖然我們公司也有AI的能力，AI的團隊，但是AI要基於大資料去做。只有資料很豐富同時合理性高時，去做AIOps才會合理有效。因為只有對正確合理的資料進行分析，檢測出的問題以及自動修復才是合理有意義的。用不合理的資料去做AI，方向就錯了。
三、終極的目標是想做NoOps，相當於釋放整個產研側的壓力，完全實現流水線自動化。
今天我的演講就到這裡，謝謝大家！
