怎么優雅解決項目Delay和交付質量差的問題

這篇文章給大家介紹怎么優雅解決項目Delay和交付質量差的問題，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

為什么要寫這篇文章

做了這么多年項目，參加過無數次團隊內外的項目復盤，發現不少項目延期和客戶交付質量的問題。這些問題給產品和技術負責人帶來了不少應急“救火”的困擾。分析這些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客戶驗收項目：珍惜客戶&重視團隊文檔交付質量；

關于怎么優雅解決項目Delay和交付質量差的問題就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。