怎么優(yōu)雅解決項目Delay和交付質(zhì)量差的問題

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

為什么要寫這篇文章

做了這么多年項目，參加過無數(shù)次團隊內(nèi)外的項目復(fù)盤，發(fā)現(xiàn)不少項目延期和客戶交付質(zhì)量的問題。這些問題給產(chǎn)品和技術(shù)負責人帶來了不少應(yīng)急“救火”的困擾。分析這些Case后，發(fā)現(xiàn)問題集中在以下幾個方面：

• 需求界定不清晰、系統(tǒng)設(shè)計有缺陷、研發(fā)質(zhì)量無保障、無效溝通耗時長，導(dǎo)致項目反復(fù)并且嚴重延期；

• 跨團隊協(xié)作推動成本高，多團隊交付進度出現(xiàn)Delay，項目整體目標不可控；

• 概要設(shè)計文檔、API手冊、產(chǎn)品使用手冊和運維手冊質(zhì)量差，客戶學習成本高；

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

項目管理和研發(fā)質(zhì)量控制是一個比較復(fù)雜的系統(tǒng)工程，本文不會系統(tǒng)的講解一些理論和原則，而是以實際案例為索引分享一下項目管理中常見的問題以及必須要采取的方法。前車之覆，后車之鑒，希望能對新晉的項目管理同學有些幫助。

案例一：多角色人員協(xié)作的業(yè)務(wù)項目

場景描述

某監(jiān)控產(chǎn)品需要對多個Region的多個云服務(wù)（例如虛機、數(shù)據(jù)庫組件、緩存組件、消息隊列組件）提供多個指標趨勢圖對比查看功能。產(chǎn)品研發(fā)需要PM設(shè)計產(chǎn)品形態(tài)和邏輯，UE設(shè)計產(chǎn)品視覺交互，若干FE研發(fā)前端頁面，若干RD研發(fā)后端業(yè)務(wù)邏輯，QA測試業(yè)務(wù)功能，測試通過后FE和RD聯(lián)合上線。項目研發(fā)從預(yù)期的1個半月拖延至實際3個月。研發(fā)中經(jīng)歷至少5輪測試，發(fā)現(xiàn)2個產(chǎn)品缺陷，5個技術(shù)方案缺陷，低級Bug預(yù)估20+，Bug收斂速度極慢。這是一個極其典型的項目管理和研發(fā)質(zhì)量失控案例，參與項目的多數(shù)是新同學，研發(fā)流程規(guī)范上認知度嚴重欠缺。

為了便于大家對項目過程的理解，附注一下相關(guān)的產(chǎn)品設(shè)計、接口設(shè)計和低級Bug例子：

• 產(chǎn)品設(shè)計缺陷：PM產(chǎn)品設(shè)計時遺漏在趨勢圖上標注不同Region的云服務(wù)名字，導(dǎo)致用戶無法定位指標所歸屬的云服務(wù)實例。

• 接口設(shè)計缺陷：產(chǎn)品要求一個趨勢圖最多支持30個云服務(wù)實例的指標對比，前端FE接口參數(shù)檢驗限定為20個，后端RD接口參數(shù)校驗限定為10個；趨勢圖指標數(shù)據(jù)查詢無論用戶選擇的時間段多長，指標查詢的粒度都是60s，導(dǎo)致在時間跨度很大的情況下，返回數(shù)據(jù)點過多頁面渲染性能差。

• 低級Bug：選擇實例和監(jiān)控項之后可以查看趨勢圖，但是取消監(jiān)控項選擇之后趨勢圖未消失；時間選擇框?qū)厔輬D展示的指標數(shù)據(jù)的時間段控制作用失效。

關(guān)鍵問題

• 產(chǎn)品設(shè)計和接口設(shè)計缺陷應(yīng)該是在什么階段發(fā)現(xiàn)？

• 低級Bug為什么那么多？Bug收斂速度為什么那么慢？

• 項目出現(xiàn)延期風險時，項目負責人應(yīng)該在什么階段管控風險？

解決方案

這個項目的關(guān)鍵是沒有嚴格遵循常規(guī)的軟件研發(fā)流程規(guī)范。

• PRD沒有經(jīng)過評審，PM簡單畫了幾個原型圖開始安排前端FE和業(yè)務(wù)RD開發(fā)，導(dǎo)致產(chǎn)品缺陷沒有在PRD評審階段發(fā)現(xiàn)；

• 前端FE和后端RD的接口設(shè)計沒有完備的文檔，沒有經(jīng)過充分的溝通；RD提測代碼時沒有經(jīng)過整體場景的聯(lián)調(diào)和Demo Review，導(dǎo)致低級Bug在測試階段才暴露出來；

• QA的測試準入沒有嚴格執(zhí)行，低級Bug多的情況下，QA未實施測試打回；

• 技術(shù)負責人沒有在項目即將延期時進行問題復(fù)盤，而是在延期兩周后才跟進問題，錯過了關(guān)鍵的項目修復(fù)時間，增加了很多不必要的多人協(xié)作成本。

這個案例在很多新項目新團隊成員中比較常見。對于多角色協(xié)作的項目需要執(zhí)行嚴格的研發(fā)流程規(guī)范，需求相關(guān)的MRD，產(chǎn)品設(shè)計PRD，UE設(shè)計稿、總體設(shè)計和詳細設(shè)計文檔都需按照規(guī)范撰寫并且經(jīng)過團隊評審，只有前一個環(huán)節(jié)通過才能進入下一個環(huán)節(jié)。盡早交流和持續(xù)溝通使開發(fā)人員獲得對產(chǎn)品和業(yè)務(wù)的信息，始終遵守“及早發(fā)現(xiàn)，及早解決”的準則，如此我們便能在軟件研發(fā)過程中價值最低的階段修正問題。RD在交付QA之前需要進行系統(tǒng)聯(lián)調(diào)和Demo Review，確保研發(fā)和產(chǎn)品設(shè)計保持一致。研發(fā)質(zhì)量需要符合編碼規(guī)范，并且有單測指標，單測的行覆蓋率和分支覆蓋率不達標QA可以拒絕測試。QA需要嚴格執(zhí)行測試準入，對于低級Bug多的同學不僅拒絕測試，并且團隊內(nèi)公示項目中每個同學的代碼質(zhì)量。

項目管理者需要執(zhí)行嚴格的研發(fā)流程規(guī)范，需要合理的安排項目的進度。通常的經(jīng)驗是為 1/3計劃、1/6編碼、1/4構(gòu)件測試以及1/4系統(tǒng)測試，所以一定不要在前期的設(shè)計評審階段和后期的聯(lián)調(diào)單測階段節(jié)省時間，不然會使得項目風險頻發(fā)，脫離控制。任何創(chuàng)造性活動都伴隨著枯燥艱苦的勞動，編程也不例外。大家通常期望項目在接近結(jié)束時，軟件項目能收斂的快一些，然而，情況卻是越接近完成，收斂的越慢。一個風險問題的暴露，一個里程碑的進度偏離，最終會累積使得整體進度偏離很遠。慢性進度偏離是士氣殺手，及早的問題復(fù)盤，持續(xù)的信息同步有助于將脫軌的項目拉回到正常的軌道。

案例二：多團隊聯(lián)合解決方案實施

場景描述

部門成立一個近20個團隊的聯(lián)合項目，實施核心業(yè)務(wù)線的SCAR（項目代號）。該項目的主要目標是結(jié)合多個平臺系統(tǒng)提供的能力，組合成一個復(fù)雜解決方案，幫助業(yè)務(wù)提升能力。項目的周期是一年，多個平臺研發(fā)團隊和十幾個業(yè)務(wù)團隊需要完成該解決方案的研發(fā)和業(yè)務(wù)落地。項目實施中的初期發(fā)現(xiàn)平臺研發(fā)符合預(yù)期，若干個業(yè)務(wù)團隊沒有承諾明確的落地時間，或者承諾的時間因為團隊的其他項目影響落后于項目預(yù)期。聯(lián)合團隊采取了緊急溝通，實施了一些雙重匯報機制和指標管控方法，保障了項目如期交付。這個項目成功落地業(yè)務(wù)線取得了非常好的效果，作為成功案例在多個團隊做項目管理分享。

關(guān)鍵問題

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

• 如何跟進項目及時發(fā)現(xiàn)進度風險？

解決方案

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

因為涉及的團隊比較多，多個業(yè)務(wù)團隊的落地進展對橫向團隊負責人來說是一個黑箱。橫向聯(lián)合團隊負責人需要設(shè)定相應(yīng)的指標監(jiān)督項目進度和識別項目風險。關(guān)鍵的指標包括以下三類：

• 先行指標（Leading Indicator）：項目啟動之初建立該項指標，明確到項目結(jié)束時SCAR系統(tǒng)具備的能力以及在業(yè)務(wù)線實施的覆蓋度，通過這些指標可以引導(dǎo)項目負責人關(guān)注黑箱中該注意的事情。

• 線性指標（Linearity Indicator）：為了達到目標設(shè)定的理想進度指標，可以理解為項目分季度分月的KPI指標，比如系統(tǒng)研發(fā)的進度，比如業(yè)務(wù)線實施覆蓋度。以業(yè)務(wù)線實施覆蓋度為例，可能14個業(yè)務(wù)線，第一個季度實施4個業(yè)務(wù)線，后面的兩個季度每個季度實施5個業(yè)務(wù)線。設(shè)置線性目標是為了指導(dǎo)項目分階段的進度，避免因為項目時間跨度過長項目風險整體不可控。

• 趨勢指標（Trend Indicator）：以時間標準為基礎(chǔ)，根據(jù)對過去的觀察，從趨勢中預(yù)測未來。例如，項目的初期系統(tǒng)易用性較差，業(yè)務(wù)落地的成本高，前期的業(yè)務(wù)實施覆蓋度指標有可能落后于一開始設(shè)置的線性指標。經(jīng)過一段時間的系統(tǒng)優(yōu)化，業(yè)務(wù)落地的成本變低了，后期的業(yè)務(wù)實施覆蓋度指標有可能快于一開始設(shè)置的線性指標。項目負責人需要周期性Review項目的趨勢指標，及時協(xié)調(diào)資源，調(diào)整項目的進度和把控風險。

通過虛擬團隊的雙重匯報機制，通過設(shè)定項目的先行指標和線性指標，周期性Review趨勢指標，可以幫助項目負責人在多團隊協(xié)作項目中能夠比較好識別項目風險和調(diào)度資源解決問題。

案例三：ToB客戶驗收項目

場景描述

團隊承接了某個客戶的平臺研發(fā)，需要交付時提供完備的系統(tǒng)概要設(shè)計文檔、用戶手冊和標準運維流程手冊給客戶。項目交付前期團隊內(nèi)部抽查了部分文檔，發(fā)現(xiàn)一些文檔內(nèi)容的完備性、可讀性和可操作性欠缺，急需規(guī)范和優(yōu)化。為了保障對客戶高質(zhì)量的輸出，團隊陷入緊急的文檔優(yōu)化過程，很多RD和PM進入了加班“救火”狀態(tài)。在ToB項目中，每一份文檔都代表著對客戶的承諾和服務(wù)意識，代表著一個團隊的技術(shù)素養(yǎng)，需要認真對待。

關(guān)鍵問題

• 什么階段該寫文檔？一個好的文檔應(yīng)該具備什么樣的特征？

• 團隊經(jīng)理和項目負責人如何保障文檔質(zhì)量？

解決方案

概要設(shè)計文檔需要在項目設(shè)計階段產(chǎn)出并且評審?fù)ㄟ^，而不是在項目交付階段進行補充；接口設(shè)計需要在研發(fā)之前完備并且經(jīng)過評審；用戶手冊需要在實施客戶培訓(xùn)前完備，具備良好的易讀性，客戶學習成本低；運維巡檢和故障處理SOP手冊需要在交付客戶運維之前完備，并且經(jīng)過演練執(zhí)行。

一個團隊應(yīng)該有確定的可執(zhí)行文檔規(guī)范，而不是每個項目每個團隊成員想當然的自行發(fā)揮才華，交付質(zhì)量參差不齊。對每個文檔的維護也提供了項目的狀態(tài)監(jiān)督和預(yù)警機制，文檔使各項計劃和決策在整個團隊范圍內(nèi)得到交流，也便于及時發(fā)現(xiàn)項目的問題。

概要設(shè)計文檔需要明確項目的背景、名字解釋、功能概述、性能指標、依賴的軟硬件環(huán)境、系統(tǒng)的總體架構(gòu)、系統(tǒng)核心業(yè)務(wù)模型、系統(tǒng)各模塊交互的數(shù)據(jù)關(guān)系、各模塊的功能概述、各模塊依賴第三方服務(wù)的接口說明。

HTTP Restful風格的接口設(shè)計文檔需要明確面向資源的HTTP URL設(shè)計方法、HTTP Method使用說明、HTTP Status Code使用說明、接口鑒權(quán)方法，接口輸入和返回的各種參數(shù)說明、接口返回系統(tǒng)錯誤碼的明確含義等。

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

文檔規(guī)范的執(zhí)行效果需要有質(zhì)量控制方法，不然文檔規(guī)范就成了擺設(shè)。項目負責人常用的方法可以稱之為“海關(guān)與監(jiān)視器”，團隊經(jīng)理常用的質(zhì)量控制方法是隨機檢驗。

• “海關(guān)”是指我們先設(shè)下重重關(guān)卡，文檔唯有通過檢驗之后才能進入下一步的研發(fā)流程，如果文檔無法通過評審，便被打回重做或者是廢棄。概要設(shè)計文檔和接口設(shè)計文檔應(yīng)該使用此方法。

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

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

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

寄  語

以上是對幾個典型項目場景下遇到問題的復(fù)盤思考，這些案例給我們的啟示如下：

• 多角色人員協(xié)作的業(yè)務(wù)項目：嚴格遵守軟件研發(fā)流程&及早發(fā)現(xiàn)問題及早解決；

• 多團隊聯(lián)合解決方案實施：建立雙重匯報機制&設(shè)定并且盯好業(yè)務(wù)指標；

• ToB客戶驗收項目：珍惜客戶&重視團隊文檔交付質(zhì)量；

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