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

時間 2020-04-12

標籤優雅解決項目 delay 交付質量問題简体版

原文原文鏈接

本文做者：AIOps智能運維前端

做者簡介數據庫

凌薇百度雲智能運維業務研發負責人編程

負責百度雲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使用說明、接口鑑權方法，接口輸入和返回的各類參數說明、接口返回系統錯誤碼的明確含義等。

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

文檔規範的執行效果須要有質量控制方法，否則文檔規範就成了擺設。項目負責人經常使用的方法能夠稱之爲「海關與監視器」，團隊經理經常使用的質量控制方法是隨機檢驗。

「海關」是指咱們先設下重重關卡，文檔惟有經過檢驗以後才能進入下一步的研發流程，若是文檔沒法經過評審，便被打回重作或者是廢棄。概要設計文檔和接口設計文檔應該使用此方法。
「監視器」是指咱們能夠將不知足質量檢測的文檔內容標識上記號，這個文檔將不會在流程中的各個關卡被截住，整個流程將會變得順暢，在這種檢測中，有問題的地方超過必定的量，則須要當即修訂。對於用戶手冊和運維巡檢手冊中場景的覆蓋度問題能夠視狀況採用「監視器」的方法進行多輪迭代。
隨機檢驗就是隨機抽查。由於項目不少，不一樣項目負責人對文檔把控的嚴格程度也會有誤差，因此對於團隊經理來講，逐個文檔檢查的成本很是高，改變檢驗的頻率也就理所固然。若是一個經理對他的下屬事必躬親，就可能形成干預，並且將會浪費更多的時間在不會出錯的下屬上。更糟糕的是，他的下屬可能所以會造成依賴性——反正什麼事情老闆最後都會檢查。隨機檢驗應用在管理上，既能夠增長項目負責人的責任感，又能夠節省經理時間。