在職場上，即使再怎么小心，也免不了接到一些爛項目的時候。這種時候，如果沒有經驗，我們需要怎么面對？本文作者講述了他的親身經歷和一些做法，希望能幫到大家。

———— / BEGIN / ————

工作中，我們都有概率，會碰到爛項目，有可能是別人甩鍋，故意坑你，也有可能是項目確實失控了，需要外部援助，緊急救火。

但不管出于怎樣的原因，接手這種項目，一定要慎之又慎，因為“背鍋”還是“救火”，是功還是過，真的是一念天堂，一念地獄！

無與倫比的“爛”項目

這個項目，我愿稱之為“無與倫比的爛”。

我說一下當時接手該項目時的場景，大家感受一下就知道了：

有一天，我領導喊我到辦公室，開門見山地告訴我，后面要交給我一個項目，這個項目，他跟事業部的負責人已經聊過一次了，只知道個大概情況，各種資料文檔統統沒有。

然后呢，我領導跟我又溝通了大概半個多小時，所有的信息，總結一下的話，大概有這么幾條：

1. 這個項目，我們屬于丙方，然后需要以乙方的身份，去甲方那邊駐場開發；（真的是孫子。。。）

2. 駐場地址xxx，駐場人員目前有ABC，由于公司業務調整，后續我需要帶著DEF過去和之前的人交接；（第一次溝通的時候，DEF是誰都還沒確定。。。）

3. 按照事業部負責人的說辭：“這個項目的功能已經開發的差不多了，派個PM過去盯著，收收尾就行了。”（功能都有什么，壓根都不知道，開發的差不多了，咱也不知道差多少。。。）

4. 我們跟乙方簽訂的有一份合同，但乙方跟甲方還未簽訂，后續我們跟乙方的合同，有可能會重簽。

意思就是，前期合同簽訂的有些粗略，不能作為交付驗收的依據。。。

按照事業部負責人的說法，目前簽訂的這份合同，如果哪天跟乙方鬧掰的話，打官司的時候會有用。。。

（一個項目，已經開發了兩三個月了，合同還沒敲定，你們敢信？）

好了，項目的所有信息，基本上就是以上4條了，項目情況看起來比較模糊，其實一點也不清楚。。。

總結一下，這個項目我接手的時候，大概有這么幾方面的特征：

1. 沒有任何資料；

2. 項目進度不清楚；

3. 何時交付不清楚；

4. 交付標準不清楚；

5. 甚至連資源（主要是人力資源）都不清楚。。。

在此，我想問一下大家，有沒有人遇到過，比我這還爛的項目了。。。

接手這個項目，真的就像是開盲盒一樣，啥啥都不知道，然后“背鍋”與“救火”，真的是就在一念之間啊，一念天堂，一念地獄。。。

遇到這種情況，該怎樣避免背鍋呢？

項目管理有專業的方法論，正所謂理論指導實踐，以下這張圖，在整個項目過程中，真的給了我很大的幫助。

然后呢，我從實踐的角度，做了幾方面的事情，目前來看，基本上能和“背鍋”兩個字說拜拜了，而且接手了差不多一個月，領導也準備給我這個月的績效打個A。

好了，今天就把這些“防背鍋”小妙招，總結一下，分享給大家。

項目正式接手前

項目先別著急接手，正式接手之前，先把這幾件事情給搞清楚了，說明白了，再接手也不遲。

且也不要害怕別人會說，你不服從安排什么的，咱又不是不接，接之前，有一些疑問提出來，想確認一下，這個總沒毛病吧~

1. 定性

讓我接手這個項目，木得問題，但得先把我接手的這個性質，咱們講清楚，說明白。

這個時候，就得拉著PM領導、事業部領導以及技術部領導，來一個三方會談了。

（具體拉上哪些人，大家可以根據自己公司的情況決定，反正最好是拉上能夠互相制約的幾個人，或者是有話語權的第三方公證人）

項目本身就已經這么爛了，讓我接手，是來解決問題的，不是背鍋的。

而且大概估算了一下，目前項目進展已經幾個月了，加上前期的商務成本以及駐場的開發成本，都已經快跟合同額持平了，這個“成本管理”肯定是管不了了，就算是以后項目爛尾了，或者是賠錢了，這個肯定不能算到我頭上。

2. 定權責

正所謂，將在外，君命有所不受！

讓我接手這個項目，那么駐場的這些個人員，肯定都得聽從我的安排。

但只有口頭授權，往往是不夠的，最直接有效的辦法，就是把這些人的考核權，牢牢把握在自己手里。

試想，如果連考核的權利都沒有，獎錢罰錢，都不是你說了算，那誰會聽你的。

而且，這個事情，也一定要同步到項目所有成員，我當時是這么干的：

第一步：和相關的領導們開了個會議，會上口頭確認了一下這個事情；

第二步：我自己整理了一下會議紀要，把這個結論給記錄了一下，往所有項目成員都在的群里面給丟了一下；

第三布：群里面@所有人，明確告知，后續現場人員的考核，由PM全權負責！

這里再多說一點，溝通管理是項目管理里面的一項重要內容，其中溝通里面占比最多的就是會議溝通，有很多人不喜歡記會議紀要，覺得麻煩或者沒必要。

這就大錯特錯了，會議紀要真的是非常有必要：

一方面，會議紀要是大家會議溝通那么長時間，最終達成共識的一個結論性的東西，整理成文字，還可以檢驗這個結論有沒有偏差；

另一方面，后期如果出現不認賬的情況，那么會議紀要自然就成了強有力的證據；

最最重要的是，作為一個整理會議紀要的人，在整理的時候，必然會帶著一些主觀的色彩，說白了，就是將自己認為合理的內容記上去，或者是按照自己認為合理的方式記上去，當然，跟大家的結論不能夠有太多的偏差，不然肯定還得修改。

3. 找隊友

正所謂，天下沒有永遠的敵人，也沒有永遠的朋友，只有永遠的利益。

可以從三個不同的視角，來確定不同場景下，隊友都是誰：

• 從公司內部的視角來看：我們PM是一個資源池，服務于不同事業部的不同項目，所以我跟我領導肯定是隊友，事業部的人，屬于對立面，我們之間肯定是要劃清責任的；

• 從整個項目的視角來看：那么我們公司的人，肯定就是隊友了，簽合同的乙方以及甲方，那就是對立面了；

• 從項目交付的視角來看：和我們簽訂合同的乙方，也有可能是隊友，因為有很多時候，甲方會提出很多無理的或者是額外的需求，這個時候乙方也是想盡快交付項目，拿到錢的，所以乙方也會想辦法推掉這些亂七八糟的。

分清敵友，能夠在不同場景下，讓各個角色之間相互制約，更好地推動項目進展~

項目正式接手后

項目正式接手后，才是真正的考驗。

很多人面對一個項目，不知道該怎么入手，就跟我們做產品設計一樣，初級的作圖仔仔，很容易一頭就扎到細節里面，這樣的話，接下里的工作會反反復復，無窮無盡。

所以說，打蛇打七寸，項目的七寸主要在于以下幾個方面，把這幾個方面給管理好了，那這個項目就成功了一大半了。

1. 范圍邊界管理

我們要干哪些事情，以什么為驗收標準，這個是項目開始之前，就必須要搞清楚的事情啊。

也不知道這個項目是咋搞的，都已經幾個月了，連驗收標準都不知道，現場甲方爸爸讓干啥就干啥。。。

而且這個問題，一定不能含糊，對方如果和稀泥，那就一定要有打破砂鍋問到底的精神。

就比如，我向乙方這個負責人發出的奪命5連問，我感覺都已經給他問的快懷疑人生了：

2. 干系人管理

想要順利地推動項目進展，一定要知道各個角色都有哪些權責。

舉個簡單的例子，一款考勤產品，肯定是公司的老板買單，你如果一直滿足員工的需求，比如搞了個方圓100公里都能夠打卡的功能，那這個項目肯定會爛尾。。。

拿我接手的這個“爛”項目舉例，最起碼能夠列舉出這么幾類干系人：

1）公司內部干系人

決策者：事業部領導、PM領導、技術部領導。

也就是說如果后期項目爛尾了，或者是賠錢不想干了，這三個領導拍板就行了。

當然，日常匯報，不管是有什么進展，或者有什么困難，比如資源協調什么的，干系人也是這三位。

執行者：駐場的開發，這些就不一一介紹了，全是磚，哪里需要哪里搬的那種。。。

2）公司外部干系人

乙方對接人：和我們簽合同的乙方的對接人，反正乙方的其他人我也從來沒見過，跟乙方溝通，或者是需要乙方跟甲方出面溝通的話，找這一個就行；

甲方對接人：現場直接對接的甲方人員，說白了，就是現場找了倆人，盯著我們干活的，有啥小事，找這倆人就行，但大事，比如項目驗收什么的，這倆人肯定沒這個權利；

甲方決策者：項目想要驗收，還得把這個人搞定。

但現實往往是，這種決策者，總會提一些亂七八糟的需求，比如我在這個爛項目中遇到的，甲方決策者提的：“產品界面能不能做的簡約一點，但界面展示的內容能不能豐富一點”，我當時一口老血，差點就吐在他臉上了。。。

最后再多說一點，畢竟我是中途接手的這個爛項目，就簡單列了一下這些干系人，如果是一個新項目，或者大家想做一個專業點的干系人管理，可以參考以下這個表格：

3. 問題與風險管理

之前這個項目是一個開發人員負責的，完全沒有問題與風險意識。。。

我還和我們PM領導討論一下，開發人員的思維應該是這樣的：

“客戶提出問題，我得想辦法解決啊，如果把問題反饋給領導，領導肯定會覺得我水平不行，前期自己先想想辦法，后期如果實在兜不住了，到時候再說吧。。。”

但實際情況很有可能，問題與風險越積越多，項目最終就失控了。。。

有問題不可怕，可怕的是，領導們連有問題都不知道，還以為項目都進展的很順利呢，就比如事業部領導剛開始跟我說的，項目都快收尾了，大概率就是聽這個開發負責人匯報的片面之詞。。。

有問題及時反饋，領導們及時了解項目現狀，也會想方設法幫忙解決問題的，因為領導們也是需要向老板匯報情況的，也是希望項目早點結束，拿到匯款的。

再來普及兩個概念，有誰知道，“風險”跟“問題”都是什么意思么？

我來直接說答案吧~

風險：是指還未發生的，但我們可以提前預測到的，對應的是預案，需要避免風險的發生。

就比如這個項目的交付標準不明確，等到后期驗收的時候，肯定會扯不清，這就是風險，而預案肯定就是，前期想方設法跟乙方以及甲方明確交付標準。

問題：是指已經發生的，對應的是解決方案。

在這個項目當中，我遇到了一個特別“搞笑”的問題，當時笑的我都差點哭了。。。

我接手的時候不是說項目的功能都已經快做完了么，但實際了解了一下，他喵的，里面的核心功能，還存在技術難點，也就是OCR這部分內容，現場的開發人員搞不了。。。

其他的增刪改查的功能，做的再完美，有個毛用啊。。。核心功能不能用，這個項目交付個毛線。。。

于是，我緊急跟公司的技術領導溝通了一下，找了其他的技術資源，趕緊支撐了一波。。。

4. 進度管理

進度跟第一項范圍邊界，是息息相關的，搞清楚了范圍邊界，才能談進度。

對于進度管理，我是分了兩個層面，一個是項目的整體進度，另一項是每周現場每位人員的進度，從宏觀到微觀，也就是這兩張表。

第一張表：可以看到整個項目的進展情況

第二張表：可以看到每周各個任務，以及每個人員的工作情況

兩張表結合，即可實現對于項目的管控~

5. 溝通管理

及時匯報，及時匯報，及時匯報，重要的事情說三遍！

匯報工作這件小事，我敢打賭，80%的PM，甚至是80%的職場人，可能都不會。

溝通管理的意義，在前面“問題與風險管理”當中，已經說過了，這里重點說一下，我在這個項目中，是怎樣做好溝通管理的。

因為該項目的干系人稍微有點復雜，于是我一口氣建了5個群。。。

1）項目群

里面包含我們公司項目的所有成員，用于同步項目信息，以及日常的溝通交流。

2）管理群

只有領導的群，包括前面說的，事業部領導、PM領導、以及技術部領導，有些話不方便對所有人說，這個群也是很有必要的。

3）只有項目成員的群

同樣，有些話，也不方便對領導說，所以建一個只有項目成員所在的群，說一些悄悄話，也是挺有必要的。

而且這么整的話，也能讓現場干活的人，感覺到，你們都是一條賊船上的~

4）有所有項目成員以及乙方的群

乙方那個對接人，老是微信單獨給我發信息，還經常下班給我打微信電話，我一度以為，那個老家伙，貪圖我的美色。

然后呢，我先是正常溝通，讓他在群里發信息，這樣直接同步所有人，省的我再次傳達了。

后來發現，并沒有什么卵用，還是各種單獨給我發信息，于是乎，他單獨給我發，我就群里給他回。。。

建這個群的目的，還是乙方如果提的有什么奇形怪狀的要求時，也能讓我們領導知道，共同想辦法對付他~

5）有所有項目成員以及甲方的群

現場也是需要同步信息的，比如我們制定一個計劃，或者確認的需求，反正就是各種結論性的東西，都往群里丟一下，省的后期部認賬~

6. 要想馬兒跑，就得給馬兒喂草

項目進展過程中，避免不了各種突發情況，比如甲方爸爸提了一些腦殘需求，導致反復更改，或者是為了趕進度免不了加班的情況。

除了權利層面的約束之外，想讓大家好好干活，小恩小惠自然也是少不了的。

我從兩個不同的層面，給馬兒們整來了草，其中第一層面，還用了陽謀！

層面一：

當然是向公司申請費用了。

把一個爛項目丟給我，我申請頓飯錢，一點都不過分吧？

其實我剛開始想的是，等項目有一定成績了，再申請個“慶功宴”，后來想想，項目后面咋樣還不好說呢，先帶大家吃頓好的再說。。。

而且我申請的方式，讓領導無法拒絕！

還記得我們建的第一個群，項目群么，我當時在群里是這樣申請的：

這么一段話，往群里一發，如果領導領導們不批這頓飯錢的話，隱藏的有三個后果：

• 后果1：我都拉著甲方一起加班了，如果不請他們吃頓飯，后面甲方不配合了，可不能賴我啊；

• 后果2：現場的小伙伴們，最近也都得加班，如果不請他們吃頓飯，后面這群人不配合加班了，這也不能賴我啊；

• 后果3：我是為現場的小伙伴們申請福利了，領導們不批，那是領導們的問題了，可不能說跟著我累死累活，連一點好處都沒有啊~

妥妥的陽謀，領導們不批都不行，哈哈哈！

層面二：

中午跟大家伙一起吃飯，時不時給大家整杯蜜雪冰城喝一喝，別看只是一杯幾塊錢的飲料，這可是我自掏腰包請大家喝的。

而且，這只是一杯飲料嗎？這可是我們彼此之間，深厚的革命友誼啊。

結語

通過以上這些手段，反正項目現在正在逐步步入正軌，作為管理者，我把工作理順，安排完之后，就在客戶現場天天打醬油就行了，但所有人都說我工作干的不錯。。。

本文來自微信公眾號：曉莊同學產品筆記，作者：曉莊同學

一群人比一個人走得更遠，掃碼加入產品經理共學交流群，資源、方法、工具全都有。