話題描述

返工，任何項目和項目經(jīng)理都不愿意面對的一個事。一旦這件事發(fā)生，就意味著，要么PM 干不下去了，要么項目就干不下去了。但是有的時候，返工對項目經(jīng)理個體來說是沒有辦法控制的，原因方方面面。

面對大量返工，如何梳理流程來控制進度和成本？

聽他們說

01

（一）找原因?

? ? ?對于這個“大量返工”這個命題來說，首先我們應該確認返工的根本原因是什么造成的。我認為無非 3 種：?

1、需求不明確，需求變更導致可交付物無法定型，長期處于動蕩狀態(tài)，從而導致不斷推翻重來的返工。?

2、需求明確，質(zhì)量控制不嚴，未能及時發(fā)現(xiàn)研發(fā)人員交付的功能的缺陷. 3、時間緊任務重，功能來不及驗證，邊上變改。?

需要 PM 針對以上三種情況對癥下藥，同時也應該明確一點“預防的成本是最小的”，我們要隨時都有這種危機意識。

（二）對癥下藥?

? ? ?對于需求不明確：?

? ? 需求不明確造成的返工，這點基本上不可避免總會發(fā)生的，而需求變更控制也是 PM 的基本功之一，之前在關(guān)于需求變更控制的分享中也有關(guān)于如何控制需求變更的一些個人見解，大家有興趣的話可以找群精華看看。（文章末尾有鏈接）?

? ? ?對于質(zhì)量控制不嚴：?

? ? ?需求明確、質(zhì)量控制不嚴導致的返工。需要 PM 在項目的全生命周期進行跟蹤與關(guān)注，首先項目啟動階段，召開項目啟動會議時將研發(fā)、測試人員叫到一起，讓他們對系統(tǒng)功能實現(xiàn)做到心中有數(shù)，從而保證大方向步調(diào)一致。PM 必須制定項目的設計說明書，包括但不限?

于原型設計、pdr 文檔等。?

然后是項目研發(fā)階段，此時要求項目經(jīng)理制定嚴格的開發(fā)計劃，我的理解是每一個功能點的開發(fā)時常不應該超過 2 個工作日，否則視為 PM 對項目的理解不到位，同時開發(fā)計劃的周期為 2 個工作周，后邊的開發(fā)計劃可以模糊一點畢竟項目的本質(zhì)是漸進明細。然后每個工作周組織測試人員對研發(fā)交付的功能進行驗證（前提是研發(fā)人員完成功能自測），測試人員認為功能滿足才能視為此功能開發(fā)完成。研發(fā)人員在執(zhí)行開發(fā)計劃過程中必須嚴格遵守設計說明書，嚴禁不看文檔直接開發(fā)的情況發(fā)生。?

另外最好能做 30 分鐘左右的一個站立會，組內(nèi)成員匯報各自前一天的進展情況和當天工作計劃，原則上要求回報與計劃的偏離情況（正偏離，負偏離），保證任務保質(zhì)保量的完成。?

基本上也就是咱們的 PMBOK 中說的“PDCA”模式。?

? ? ?對于時間緊任務重：?

? ? ?時間緊任務重的情況造成返工。首先 PM 和技術(shù) leader 溝通一下趕工的情況下能否完成指定的工作要求，如果無法完成的情況下，確認需要多少資源然后立即匯報領(lǐng)導，申請資源如果在全力投入的情況下依舊無法完成的話，組織內(nèi)部會議溝通出能完成的極限需求范圍（保質(zhì)），然后跟甲方、客戶溝通閹割交付需求（盡可能給自己爭取閹割一些非必要功能）。?

因此趕工的情況下沒什么好的辦法只能硬著頭皮上，但是切記權(quán)衡一下無法按時上線和交付出去后質(zhì)量無法保證哪個對公司造成的打擊更嚴重。畢竟趕工的必然會意味著質(zhì)量不會被很好的保證。?

? ? 那么綜上所述，還是那句話“預防勝于治療“，盡可能把風險掐死在搖籃里。

02

（一）返工原因?

? ? ?返工，任何項目和項目經(jīng)理都不愿意面對的一個事，一旦這件事發(fā)生，就意味著，要么 PM 干不下去了，要么項目就干不下去了，但是有的時候，返工是作為項目經(jīng)理個體來說沒有辦法控制的，原因方方面面。?

? ? ?總的來說，作為項目經(jīng)理和組織級項目管理部門還是要積極的應對，要么盡量試圖修正這些返工帶來的影響，要么避免類似情況在將來的項目中再發(fā)生。?

? ? ? ?當然了，出現(xiàn)了返工的情況，而且如果是大量的返工情況，實際上我們第一個要做的是評估一下現(xiàn)在的狀況，對于合同承諾履行的情況（如果是甲乙方項目的話），看看這個項目是不是還值得搶救一下，如果還一息尚存，該趕工趕工，該啟動管理儲備就啟動管理儲備，先將項目有序的做完，針對返工的情況做一些針對行的措施。?

? ? ? 要是已經(jīng)死透了，該歸檔歸檔，也是要分析分析原因，定一定未來規(guī)劃的。?

? ? ? 那對于返工來說，我們先得知道返工產(chǎn)生的根本原因，刨得越深刻，對解決這個事情越有利，往往在職場上，有些話不能說，怕得罪人，但是我只能說……盡量做個正直的人……拋去非正常變故還有比如說，資源故障，人員能力問題，技術(shù)不成熟等等這些特定因素，產(chǎn)生返工的根本原因無非是就是需求和質(zhì)量兩大方面（拋開在這兩個過程中的人的因素，哪個組織無論什么崗位，總有那么一兩個不靠譜的），那我們暫且先就研究這兩個問題。?

? ? ? 先簡單說說那些其他原因，對于項目經(jīng)理來說，對項目最負責的態(tài)度我覺得應該是想方設法讓項目可控，有些導致趕工的原因是能夠在項目啟動之前就能預見到的，就是我們俗稱的風險。比如說技術(shù)不成熟的問題，是不是必須要用不成熟技術(shù)？如果要用，是不是要有一定的調(diào)研成本保障？要不要引入外部資源？資源故障的問題，是不是可以備份？等等，對于這些原因產(chǎn)生的返工，不太客氣的說，都是自己作的，作為項目經(jīng)理，只要能夠預見和控制的，都應該想到。?

? ? ? 當然了，肯定還有一些不可控的原因，比如老板抽風之類的~盡人事，聽天命，就是這個道理。?

（二）如何應對?

1、需求?

? ? 從需求角度講，最常見的產(chǎn)生無非就是需求描述不清，驗收標準不明確。這其實是需求管理范疇，我通常比較喜歡引入一些敏捷的思想和方法，避免或緩解返工產(chǎn)生的，能想到的做法大概如下：?

1）更頻繁的交付和反饋?

? ? ? 客戶或者用戶通常來說對自己的需要是不清楚的，至少是講不清楚的，按照一個正常人的邏輯來說，實際上能看到的東西才是最直觀的，所以我們盡量用一個 MVP（minimum viable product（最小可行產(chǎn)品），用盡量低的成本去確認用戶或甲方的需要，當然了，這得需要甲方或客戶最大成都的配合從而能夠盡早的識別變更，降低變更成本，從而降低成本，保證進度，減少返工。?

2）需求漏斗?

? ? ? 或者也叫需求判定漏斗，是一種需求獲取的建模工具，雖然說對這件事建模會顯得比較奇怪，但是在實際工作中，用模型思想去做一些事情確實是有用的，他是判定真?zhèn)涡枨蟮墓ぞ?，實際上是，通過問好幾個 Why 來決定 How 的一個需求過程。其基本宗旨就是，不要輕易相信你聽到的是什么，要確定需求的根本原因是什么，那保證這個需求是有用的，不至于做出來被廢棄或者是返工。介個東西大概長這樣（靈魂畫手上線，很多年前研究過需求工程，不知道畫的對不對了已經(jīng)）

3）用戶畫像和應用場景分析

? ? ? 同樣的，也是一種獲取需求的一種方法，通常會用在產(chǎn)品類型的項目中，實際上就是對終端用戶的一種行為模擬。通常我們定義一個人群，給這類人描述一定的屬性和行為特征，這個過程就是用戶畫像。通過這些屬性和行為特征，講該類人群放在一個場景里面，來假設一些活動，從而判斷活動產(chǎn)生的效果，這就是應用場景分析，最后我們會輸出一系列的用戶故事，也就是需求，這種描述方式會貼近于真實的應用環(huán)境和用戶環(huán)境，從而保證這個需求是有效的。

4）原型

? ? ?大家都懂，在需求這件事上，通過語言或文字在不同的人腦補下，畫面絕對是不一樣的，這樣就很容易產(chǎn)生預期偏差，一旦產(chǎn)生預期偏差就會造成無價值交付，既然沒有價值要么不要了要么重做。在原型的環(huán)境下，我們所見即所得，引導激發(fā)需求來源的真實需要。

5）能引發(fā)討論的，有明確驗收標準的需求條目或者需求卡片

? ? ?當需求被記錄下來，或者被轉(zhuǎn)述后，在團隊不同角色對需求的理解是有明顯偏差的，所以，敏捷中的方法對這件事提出了 3 個 C 的原則，即 Card，Communiacation，Confirmation，也就是說，我們用一張卡牌去傳遞需求，通過卡牌引發(fā)對需求的探討，從而達成多方的一致，以保證需求不會被歪曲。另外，所有的需求都要定義什么叫 Done，這個 Done 絕對不是臆想出來的，也是要通過討論和確認的。這樣的做法旨在保證能夠?qū)⒆钤嫉男枨髠鬟f到最后，并保障需求還原的質(zhì)量。

6）做好項目的需求變更管理

有的同學就問，VUCA 時代，不是應該擁抱變化嘛？但是我要說的是，擁抱變化并不是范圍蔓延，更不是項目鍍金，而是盡早的識別變化，以適應這些 VUCA。而管理變更，更不是阻止變更，是要讓這些變化有序的發(fā)生。變更管理不善，特別容易產(chǎn)生交付困難，項目成本和周期的增加的問題。至于怎么管理變更，書上都寫爛了，不多描述了。

因為需求是一個項目的根，方法很多，路子也很廣，我列舉的這些也就是就牛之一毛，大家還有什么想法都可以廣泛的展開思路。

2、質(zhì)量=

? ? 對于質(zhì)量的問題，我更傾向于用一些強管理手段和強過程手段來做，畢竟敏捷對質(zhì)量的管理，更注重與人和人的價值，更注重于團隊本身，在實際操作來說，多數(shù)團隊，特別是國內(nèi)團隊做這些實踐有困難，大概是這樣的情況；

1）首先我們要做一個盡量詳細和到位的質(zhì)量管理計劃

? ? 在這個計劃中，著重點在于，質(zhì)量評價的方法，質(zhì)量的標準（這是底線），重點不在于多嚴格，多謹慎，重點在于能夠在多大的范圍內(nèi)（包括發(fā)起人、相關(guān)方和團隊內(nèi)部甚至終端用戶）達成一致的認識，這有助于在項目上能夠自始至終和全部成員都能夠按照統(tǒng)一的標準去工作。

2）評審！評審！評審！

? ? 重要的事說三遍，在項目中評審是很重要的質(zhì)量活動，大家都知道，質(zhì)量≠測試，那為什么不能把質(zhì)量控制都放到測試中去呢~因為有很多問題都能在測試之前 fix 掉，從需求、設計、代碼、樣品、用例等等，每一項成果物都做了評審，而且都與原始需要進行了對應那對于產(chǎn)品的質(zhì)量和交付質(zhì)量都是有百益而無一害的。

3）注重人員的培養(yǎng)

? ? 人員技能的提升也是質(zhì)量管理的重要的一部分，有的團隊會采用傳幫帶的工作方式，我個人覺得是及好的，我也曾經(jīng)做過導師，小朋友們在一對一的環(huán)境下成長的很快，更重要的是，會更趨近于所在團隊，或者說師傅所在團隊的工作風格，這不止是對質(zhì)量，對團隊和項目的健康發(fā)展也是有好處的

? ? ?質(zhì)量崩塌導致返工，在我的工作中不是太常見，所以也沒能舉出很好的實際的例子來，但是對于團隊來說，質(zhì)量管理不到位，一定會產(chǎn)生返工甚至項目消亡等嚴重的后果。

? ? 返工是誰都不想看到的，但是我覺得，有時候換個角度來看，如果返工的產(chǎn)生，能夠推動項目進行制度或流程改革，甚至是推動組織變革，對項目、項目經(jīng)理和組織來說，也未嘗不是一件有意義的事。?