上一條微頭條，老黃嘮叨了一個發生在身邊的專案故事，沒來得及寫專案改進建議，不過意想不到的是，在評論區上看到了網友熱情地提了不少專業的意見，專案管理中的質量、範圍、溝通、組織等層面都提及到了，老黃也高興地長了一下姿勢了！
在此老黃也簡要提幾點建議，希望能助有緣人應對此類專案（專案緊急、領導關注，工作量大），書本上能找到的方法如PMP的質量管理、變更控制、風險管理、團隊管理，CMMI 5的過程改進，人月神話中的“焦油坑”等等，此處一律不提，老黃就來說些俗氣點的心得：
1.搞定人，你就搞定了專案
專案緊急有很多原因，但是如果往本質原因找的話，或許可以總結成三個字：
“人”、“事”、“物”。
”物“
即就是資源，資源不足導致不緊急的專案都變緊急了。如果專案緊急、領導重點關注，那資源這一塊基本上領導會盡可能的滿足你，當然如果資源不足得提前說，好讓領導有個心理預期，所以這一方面暫不多談。
”事“
即是特定的事件（如ZF要求的限期制改之類的），這種情況一般是沒有退路的，更不用多談。
”人“
：以老黃多年經驗總結，這可能是唯一能討價還價的領域，也是導致大部分專案緊急的原因。專案越是緊張的時候，對專案負責人的溝通能力要求越高，越需要儘快識別並搞定以下這
”三個人“。
一號人物：真實的”客戶“
有時候你以為給公司下訂單、講解需求的就是你的真實客戶，這時候你就很可能被坑得很慘。（專案外包就是最明顯的例子）。你接觸的客戶講解的需求，很可能只是他自已對需求的理解，或者是他認為這樣可以討好他的領導（不少專案就是為了領導而設的）。
因此條件允許情況下，儘可能識別並接觸、理解真實”客戶“，透過溝通控制他們的期望值，縮小專案範圍，否則可能進入無限返工模式。
二號人物：你的領導
一般領導只要客戶爽了，領導掛個功績就完事了，這個一般不難搞定，因此不多談。
三號人物：技術Leader（能幫你梳理整個開發體系的人）
專案緊急的時候，專案負責人一般很難分精力將技術管理好，特別是突然增派大量人力的專案。 條件允許情況下，這時候需要識別並授權一個技術Leader（國內不少專案只能專案負責人頂上，不容易阿）。
技術Leader需要將專案開發體系梳理好，制定好相關技術相關標準約定，識別需求、計劃層面未考慮的技術問題和關聯性問題，這時候投入的開發人力才能真正發揮出作用，否則投入的人數越多，專案延期可能越嚴重。
、人倒了，專案能不掛嗎
2.虛實結合，別把客戶、市場、產品人員吹的牛逼當需求
有個友人跟老黃說了這麼一個事件：曾經有一家公司接到一個大專案，專案負責人是一個少年班出身的牛人， 接專案時跟客戶吹了的各種雲計算、大資料（那時候這塊技術還未真實做起來）。在專案落地時，還真按之前吹的那樣幹，最終因為專案穩定性、應用效果太差，專案流產了。另一家公司接手後，用傳統的叢集技術重構後，保持十多年穩定執行。
這個故事讓老黃想起了同事一個類似悲劇的專案：一個內部使用後臺管理系統，使用者量不足1萬，竟然搞出了40、50個微服務，各種裝逼技術，搞得團隊叫苦連天，客戶心裡存了N只草泥馬。（不知道這世界上有多少被這樣坑過的網友）
老黃說：
上例就是明顯的虛實不分，自坑。雖然說現在這時代，查個數據庫都得吹個雲計算、大資料，要不然都不好意思跟客戶說話，但是客戶要的是效果，才不管你用的什麼東西。
一般開發轉管理的專案負責人有個”好習慣“就是一提到需求，第一時間想到了如何實現，甚至老老實實的按著使用者需求來幹了。這個”好習慣“有時候確實是有用的，會讓客戶覺得你很專業。但是最好注意”虛“的東西吹吹就算了，別當真，要不然老闆給你一個億都做不完一個內部後臺管理系統。
虛實結合、裝逼不累
3.不變應萬變
（手中有糧心裡不慌）
專案緊張的時候正是考驗團隊實力的時候，考驗團隊日常能力積累的時候。專案再多變 ，基礎性的東西是不變的，這些都是可以提前做積累好的（例如基礎技術框架、團隊技術能力、安全框架等等）。專案負責人日常注意積累這些不變的東西，做好佈局，才能做到手中有糧心裡不慌。
寫在最後，作為專案負責人系統學習專案管理知識，深度思考和總結各專案成功與失敗經驗是必須的啦。保持鎮定、理智，出來吹個牛唄
——————————————-
寫個文章自娛自樂，悶騷的老黃輕輕飄過……
福利
