教你優雅解決專案Delay和交付質量差的問題

作者簡介

凌薇    百度雲智慧運維業務研發負責人

負責百度雲Noah自動化運維平臺和智慧運維解決方案的探索，在服務管理、資源管理、變更管理和故障管理的業務分析和設計方面經驗豐富，致力於推進AIOps在百度業務、公有云以及私有云客戶的運維場景落地。

為什麼要寫這篇文章

做了這麼多年專案，參加過無數次團隊內外的專案覆盤，發現不少專案延期和客戶交付質量的問題。這些問題給產品和技術負責人帶來了不少應急“救火”的困擾。分析這些Case後，發現問題集中在以下幾個方面：

• 需求界定不清晰、系統設計有缺陷、研發質量無保障、無效溝通耗時長，導致專案反覆並且嚴重延期；

• 跨團隊協作推動成本高，多團隊交付進度出現Delay，專案整體目標不可控；

• 概要設計文件、API手冊、產品使用手冊和運維手冊質量差，客戶學習成本高；

我們團隊通常會使用專案覆盤（Case Study）的方法來應對這些情況。覆盤主要為了解決以下兩個問題：其一，為專案延期和客戶交付風險找到可行的解決方法；其二，給團隊成員一些指導，避免同一個問題重複出現。當然，這些覆盤工作一般在某個專案組內部開展，需要一種方式能夠在多個專案組之間共享，這便是我寫此文章的原因。

專案管理和研發質量控制是一個比較複雜的系統工程，本文不會系統的講解一些理論和原則，而是以實際案例為索引分享一下專案管理中常見的問題以及必須要採取的方法。前車之覆，後車之鑑，希望能對新晉的專案管理同學有些幫助。

案例一：多角色人員協作的業務專案

場景描述

某監控產品需要對多個Region的多個雲服務（例如虛機、資料庫元件、快取元件、訊息佇列元件）提供多個指標趨勢圖對比檢視功能。產品研發需要PM設計產品形態和邏輯，UE設計產品視覺互動，若干FE研發前端頁面，若干RD研發後端業務邏輯，QA測試業務功能，測試通過後FE和RD聯合上線。專案研發從預期的1個半月拖延至實際3個月。研發中經歷至少5輪測試，發現2個產品缺陷，5個技術方案缺陷，低階Bug預估20+，Bug收斂速度極慢。這是一個極其典型的專案管理和研發質量失控案例，參與專案的多數是新同學，研發流程規範上認知度嚴重欠缺。

為了便於大家對專案過程的理解，附註一下相關的產品設計、介面設計和低階Bug例子：

• 產品設計缺陷：PM產品設計時遺漏在趨勢圖上標註不同Region的雲服務名字，導致使用者無法定位指標所歸屬的雲服務例項。

• 介面設計缺陷：產品要求一個趨勢圖最多支援30個雲服務例項的指標對比，前端FE介面引數檢驗限定為20個，後端RD介面引數校驗限定為10個；趨勢圖指標資料查詢無論使用者選擇的時間段多長，指標查詢的粒度都是60s，導致在時間跨度很大的情況下，返回資料點過多頁面渲染效能差。

• 低階Bug：選擇例項和監控項之後可以檢視趨勢圖，但是取消監控項選擇之後趨勢圖未消失；時間選擇框對趨勢圖展示的指標資料的時間段控制作用失效。

關鍵問題

• 產品設計和介面設計缺陷應該是在什麼階段發現？

• 低階Bug為什麼那麼多？Bug收斂速度為什麼那麼慢？

• 專案出現延期風險時，專案負責人應該在什麼階段管控風險？

解決方案

這個專案的關鍵是沒有嚴格遵循常規的軟體研發流程規範。

• PRD沒有經過評審，PM簡單畫了幾個原型圖開始安排前端FE和業務RD開發，導致產品缺陷沒有在PRD評審階段發現；

• 前端FE和後端RD的介面設計沒有完備的文件，沒有經過充分的溝通；RD提測程式碼時沒有經過整體場景的聯調和Demo Review，導致低階Bug在測試階段才暴露出來；

• QA的測試准入沒有嚴格執行，低階Bug多的情況下，QA未實施測試打回；

• 技術負責人沒有在專案即將延期時進行問題覆盤，而是在延期兩週後才跟進問題，錯過了關鍵的專案修復時間，增加了很多不必要的多人協作成本。

這個案例在很多新專案新團隊成員中比較常見。對於多角色協作的專案需要執行嚴格的研發流程規範，需求相關的MRD，產品設計PRD，UE設計稿、總體設計和詳細設計文件都需按照規範撰寫並且經過團隊評審，只有前一個環節通過才能進入下一個環節。儘早交流和持續溝通使開發人員獲得對產品和業務的資訊，始終遵守“及早發現，及早解決”的準則，如此我們便能在軟體研發過程中價值最低的階段修正問題。RD在交付QA之前需要進行系統聯調和Demo Review，確保研發和產品設計保持一致。研發質量需要符合編碼規範，並且有單測指標，單測的行覆蓋率和分支覆蓋率不達標QA可以拒絕測試。QA需要嚴格執行測試准入，對於低階Bug多的同學不僅拒絕測試，並且團隊內公示專案中每個同學的程式碼質量。

專案管理者需要執行嚴格的研發流程規範，需要合理的安排專案的進度。通常的經驗是為1/3計劃、1/6編碼、1/4構件測試以及1/4系統測試，所以一定不要在前期的設計評審階段和後期的聯調單測階段節省時間，不然會使得專案風險頻發，脫離控制。任何創造性活動都伴隨著枯燥艱苦的勞動，程式設計也不例外。大家通常期望專案在接近結束時，軟體專案能收斂的快一些，然而，情況卻是越接近完成，收斂的越慢。一個風險問題的暴露，一個里程碑的進度偏離，最終會累積使得整體進度偏離很遠。慢性進度偏離是士氣殺手，及早的問題覆盤，持續的資訊同步有助於將脫軌的專案拉回到正常的軌道。

案例二：多團隊聯合解決方案實施

場景描述

部門成立一個近20個團隊的聯合專案，實施核心業務線的SCAR（專案代號）。該專案的主要目標是結合多個平臺系統提供的能力，組合成一個複雜解決方案，幫助業務提升能力。專案的週期是一年，多個平臺研發團隊和十幾個業務團隊需要完成該解決方案的研發和業務落地。專案實施中的初期發現平臺研發符合預期，若干個業務團隊沒有承諾明確的落地時間，或者承諾的時間因為團隊的其他專案影響落後於專案預期。聯合團隊採取了緊急溝通，實施了一些雙重彙報機制和指標管控方法，保障了專案如期交付。這個專案成功落地業務線取得了非常好的效果，作為成功案例在多個團隊做專案管理分享。

關鍵問題

• 如何確保多團隊目標的一致性？

• 如何跟進專案及時發現進度風險？

解決方案

多團隊協作的一個重要問題是每個團隊都有各自的重點專案指標，SCAR專案只是其中的一個，也可能不是其重點專案，各個團隊投入的關注度和資源不一定充分。在這種情況下，需要成立橫向聯合的虛擬團隊，在多個團隊的經理層面明確專案目標，使得該目標變成經理自身考核KPI中的一項，並且每個團隊還需要抽取出一名成員作為介面人蔘與聯合專案。虛擬團隊實施雙重彙報機制，團隊成員除了向各自的經理彙報以外，還需要向橫向聯合團隊的負責人彙報，團隊成員的年底績效考核時，橫向聯合團隊的負責人也會給出一份評價。這種機制可以確保各個團隊的專案經理對專案的支援度，以及跨團隊的成員在專案中有足夠的投入和友好的協作。

因為涉及的團隊比較多，多個業務團隊的落地進展對橫向團隊負責人來說是一個黑箱。橫向聯合團隊負責人需要設定相應的指標監督專案進度和識別專案風險。關鍵的指標包括以下三類：

• 先行指標（Leading Indicator）：專案啟動之初建立該項指標，明確到專案結束時SCAR系統具備的能力以及在業務線實施的覆蓋度，通過這些指標可以引導專案負責人關注黑箱中該注意的事情。

• 線性指標（Linearity Indicator）：為了達到目標設定的理想進度指標，可以理解為專案分季度分月的KPI指標，比如系統研發的進度，比如業務線實施覆蓋度。以業務線實施覆蓋度為例，可能14個業務線，第一個季度實施4個業務線，後面的兩個季度每個季度實施5個業務線。設定線性目標是為了指導專案分階段的進度，避免因為專案時間跨度過長專案風險整體不可控。

• 趨勢指標（Trend Indicator）：以時間標準為基礎，根據對過去的觀察，從趨勢中預測未來。例如，專案的初期系統易用性較差，業務落地的成本高，前期的業務實施覆蓋度指標有可能落後於一開始設定的線性指標。經過一段時間的系統優化，業務落地的成本變低了，後期的業務實施覆蓋度指標有可能快於一開始設定的線性指標。專案負責人需要週期性Review專案的趨勢指標，及時協調資源，調整專案的進度和把控風險。

通過虛擬團隊的雙重彙報機制，通過設定專案的先行指標和線性指標，週期性Review趨勢指標，可以幫助專案負責人在多團隊協作專案中能夠比較好識別專案風險和排程資源解決問題。

案例三：ToB客戶驗收專案

場景描述

團隊承接了某個客戶的平臺研發，需要交付時提供完備的系統概要設計文件、使用者手冊和標準運維流程手冊給客戶。專案交付前期團隊內部抽查了部分文件，發現一些文件內容的完備性、可讀性和可操作性欠缺，急需規範和優化。為了保障對客戶高質量的輸出，團隊陷入緊急的文件優化過程，很多RD和PM進入了加班“救火”狀態。在ToB專案中，每一份文件都代表著對客戶的承諾和服務意識，代表著一個團隊的技術素養，需要認真對待。

關鍵問題

• 什麼階段該寫文件？一個好的文件應該具備什麼樣的特徵？

• 團隊經理和專案負責人如何保障文件質量？

解決方案

概要設計文件需要在專案設計階段產出並且評審通過，而不是在專案交付階段進行補充；介面設計需要在研發之前完備並且經過評審；使用者手冊需要在實施客戶培訓前完備，具備良好的易讀性，客戶學習成本低；運維巡檢和故障處理SOP手冊需要在交付客戶運維之前完備，並且經過演練執行。

一個團隊應該有確定的可執行文件規範，而不是每個專案每個團隊成員想當然的自行發揮才華，交付質量參差不齊。對每個文件的維護也提供了專案的狀態監督和預警機制，文件使各項計劃和決策在整個團隊範圍內得到交流，也便於及時發現專案的問題。

概要設計文件需要明確專案的背景、名字解釋、功能概述、效能指標、依賴的軟硬體環境、系統的總體架構、系統核心業務模型、系統各模組互動的資料關係、各模組的功能概述、各模組依賴第三方服務的介面說明。

HTTP Restful風格的介面設計文件需要明確面向資源的HTTP URL設計方法、HTTP Method使用說明、HTTP Status Code使用說明、介面鑑權方法，介面輸入和返回的各種引數說明、介面返回系統錯誤碼的明確含義等。

使用者使用手冊需要場景化，有截圖，需要明確給使用者標識出錯誤使用的風險。運維巡檢和故障處理手冊需要步驟清晰可執行。

文件規範的執行效果需要有質量控制方法，不然文件規範就成了擺設。專案負責人常用的方法可以稱之為“海關與監視器”，團隊經理常用的質量控制方法是隨機檢驗。

• “海關”是指我們先設下重重關卡，文件唯有通過檢驗之後才能進入下一步的研發流程，如果文件無法通過評審，便被打回重做或者是廢棄。概要設計文件和介面設計文件應該使用此方法。

• “監視器”是指我們可以將不滿足質量檢測的文件內容標識上記號，這個文件將不會在流程中的各個關卡被截住，整個流程將會變得順暢，在這種檢測中，有問題的地方超過一定的量，則需要立即修訂。對於使用者手冊和運維巡檢手冊中場景的覆蓋度問題可以視情況採用“監視器”的方法進行多輪迭代。

• 隨機檢驗就是隨機抽查。因為專案很多，不同專案負責人對文件把控的嚴格程度也會有偏差，所以對於團隊經理來說，逐個文件檢查的成本非常高，改變檢驗的頻率也就理所當然。如果一個經理對他的下屬事必躬親，就可能造成干預，而且將會浪費更多的時間在不會出錯的下屬上。更糟糕的是，他的下屬可能因此會形成依賴性——反正什麼事情老闆最後都會檢查。隨機檢驗應用在管理上，既可以增加專案負責人的責任感，又可以節省經理時間。

不管使用上述哪種文件質量檢查方法都是在培養團隊的文件質量意識，因為交付給客戶每一項質量差的文件都可能會導致客戶的流失，也會影響團隊口碑和產品品牌。

寄  語

以上是對幾個典型專案場景下遇到問題的覆盤思考，這些案例給我們的啟示如下：

• 多角色人員協作的業務專案：嚴格遵守軟體研發流程&及早發現問題及早解決；

• 多團隊聯合解決方案實施：建立雙重彙報機制&設定並且盯好業務指標；

• ToB客戶驗收專案：珍惜客戶&重視團隊文件交付質量；

希望這些分享可以給新晉的專案管理負責人一些參考，避免一些不必要的彎路。後續依然會持續關注團隊的專案實施和分析，歡迎更多有興趣的同學一起討論和分享。

↓↓↓ 點選"閱讀原文" 【瞭解更多精彩內容】