軟體專案管理中10大知識領域中（整合、範圍、時間、成本、質量、人力資源、溝通、風險、採購、干係人）專案資源不足的情況，或許是最常見，但卻最棘手。但其實，廣義上講還有如下資源不足的情形：
1、權力不足以掌控專案全域性？
因為很多公司，專案經理沒有實權。專案立項的時候沒有任命和宣佈。專案啟動的時候沒有授權和介紹。就這樣你在無形之中成為了PM，和產品經理一起做需求分析、系統規劃設計。而且很多時候，連產品經理都沒有，你既是PM又是產品經理。沒有權利，而這個專案又有太多的專案干係人需要你去協調和驅動：需要將那些未建立健全的專案流程制度落地規範起來，需要將那些模稜兩可的系統邏輯、規則明確統一起來，需要將那些使用者並不是很清楚的需求引導梳理出來......不一而足。這樣的過程中，很多小白一樣的干係人，總會抬起無辜的眼神，憤憤不平地問：這件事情分配給我做的理由？如果真要分配請郵件抄送我的直屬上級。這是一個無正解的話題。干係人不屬於專案團隊成員，你沒有權利要求他做任何一件與你現在負責的系統產品有關的任務，即便這樣的工作任務明明是在他的職責範圍之內。如果有這樣的情況，那是你的方式錯了。在職場上事不關己高高掛起是一種普遍現象，你不能期望所有的人都想你一樣熱心地忠誠於自己的職責。所以，專案經理不是萬能的英雄，該需要請BOSS來分配的工作任務，就不要怕麻煩他。因為你權利不夠啊。
2、時間不足以制定周密的計劃？
凡事預則立，不預則廢。專案計劃的重要性不言而喻。但需求在變，計劃總是趕不上變化。如果你之前做過開發，根據專案任務評估出的計劃還基本靠譜；如果沒有，那隻能和開發人員溝通交流，通常沒有人願意把真實的評估時間彙報出來，開發設定冗餘時間，一方面是為了防止意外，另一方面是為了避免加班成災。所以你的計劃永遠都有拍腦袋的成分在裡面，無法周密，也無法嚴謹。“計劃趕不上變化”，恩，這意味著專案經理的大部分工作應該是培養團隊處理不可預料的變化的能力，而不是參與日常編碼和架構決策。那麼當系統上線的時間定了，你還能做些什麼來調整專案的計劃呢？
3、人力資源不足以支援專案的難度和強度？
任何一個公司都會存在資源不足的問題，但不是領導不重視。一個新規劃的專案立項和啟動的時候快到年底了，招聘會相對變的艱難很多，而且應聘者的技能和綜合素質都需要嚴格把關。在做軟體專案時，我們也不想一次就弄得自己精疲力竭。我們需要保持一個穩定的工作進度。可持續發展的團隊就像是在跑馬拉松而不僅僅是在衝刺。
如何應對？
很多專案經理習慣性地認為會哭的孩子有奶吃，一方面可以得到領導的重視，另一方面資源充足的團隊就相對輕鬆一些。就會說，要明確現狀，獲得理解和支援。但這是一句廢話，沒有任何的驅動意義，也沒法以結果為導向實現專案的交付。而且，你的潛臺詞還在說，領導眼瞎。拜託好不好，一個專案的規劃和實施，你的上司比你心裡更清楚。他不是看不到這樣的現狀，而是人力資源缺乏的現狀並不是他一時半會就能立馬解決的問題。所以，你的預防針變成溫馨提醒和進度彙報就足夠了。重要的是，基於這樣的現狀，作為專案經理能做點什麼，或者應該做點什麼讓這眼前的濃霧散開，可以窺得見一縷美好的Sunny呢。這樣的情況下，專案經理需要站在企業的角度去思考問題，要學會為企業分擔問題不足的資源可以透過培訓、外部推薦尋求資源等等。但核心的思路是在於，使用靈活而變通的思想簡化專案管理。包括但不侷限於：
1、簡化專案的解決方案，對專案功能塊和功能點進行裁剪，關注系統核心的和關鍵的功能；
也許你從一開始就設計了比較完善或者完美的專案建議書。這裡麵包含了一個巨大的專案工作範圍，你的SOW和WBS可能也寫的很詳盡。但此刻，你的團隊裡只有2個後端開發人員，沒有前端工程師、沒有資料庫開發工程師，也沒有測試人員來保證專案的質量。這是一個多麼悲傷的話題啊，就像你選定好了要演奏的曲目，確定了音樂會的時間和場地，但僅有2個音樂師能夠出席。所以，那個音樂指揮家在心裡揮舞著指揮棒想，可不可以把這場音樂演奏會變成音樂獨奏會。
這樣的時候，你依然需要淡定地把你的專案方案建議書和需求規格說明書重新審視一遍。結合使用者需求思考和權衡，哪一些功能是目前比較關注的，而哪一些功能是未來系統需要關注的。這個其實並不難，如果你有和使用者開放地溝透過，專案功能的輕重緩急，你都心裡有數。所以，很有必要在他們基礎之上，整理出專案一階段的需求規格說明書來。不要一味的喊叫資源不足，這樣的方式只會加重領導對你做事能力的看法，而不能解決根本問題。
2、對核心功能和關鍵任務進行優先等級排序
關於個人工作效率的經典之作《高效能人士的七個習慣》那本書裡依據縱座標（重要性）和橫座標（緊急性）來劃分任務，有如下四種組合：
1、重要且緊急，迅猛龍式的出擊；
2、重要但不緊急, 準備好未來的方案、策略和計劃；
3、不重要但緊急，學會說不，拒絕任何承諾；
4、不重要也不緊急，可以研究下隔壁的妹紙為何每次遇見你都會笑的很好看；
一個大型的專案，干係人會很多。常常會有很多年輕而對專案管理知識無知的干係人會從方便個人利益的角度出發，突然過來很莫名地給你講，XX報表要放在你的系統裡實現而且某大BOSS非常重視。這樣的時候，你需要做的就是果斷拒絕，不要給任何承諾。很明顯，這是不重要也不緊急的事情。因為凡是重要且緊急的任務，大BOSS都會在需求討論會上明確地強調多次。專案經理心裡要有一杆秤，那些人的需求是需要理會的，那些人的需求是不用多關注的。
整理完核心功能和關鍵任務的優先順序列表後，你會發現專案一半的範圍進行了裁剪。這是一個好的趨勢和結果。因為專案管理，縮減和明確專案範圍，永遠對專案的如期交付是有利的。而一個專案的實施，10個人有10個人的計劃和結果，2個人也有2個人的計劃和結果。當你無法爭取標配的資源獲得對這個專案的足夠支援時，關注核心功能、在核心功能範圍內進行任務優先排序。之後，通常困難都是一時的，規劃良好的迭代實施計劃，講縮減至一半的專案範圍，持續地補充完善起來。透過持續漸進、裁剪和分解的方式最終實現專案的成功。
3、制定持續可行的迭代計劃和週期
迭代這個單詞很氾濫，但很多人都不明白需要迭代什麼。首先要明確，在那些核心的和關鍵的功能清單中，有哪些是需要放在持續的迭代計劃當中的。不是專案所有的功能都需要迭代。成熟的功能基本都是一次開發就落地實現，如果你說要迭代設計登陸和退出功能就顯得非常逗比和無知。通常需要迭代的任務都是那些比較複雜的，業界技術不是很明確或者使用者未來期望也不是很明確的功能，比如許可權體系、報表體系等等。
迭代週期不要過短（團隊HOLD不住，時間都會浪費在程式碼分支合併衝突檢測、各種測試、bug修復、上線釋出中），也不要太長（否則失去了敏捷開發的意義），為了給不成熟的團隊留出充分的容錯時間，所以需要具體情況具體分析。這時作為專案經理的你，需要和開發探討每個里程碑實現程度。
4、設計前瞻而靈活性高的系統架構和開發框架
如果你有幸遇到一個有全域性觀、有前瞻性的系統架構師專案會順利很多。系統的架構就像交通工具的骨骼。你需要和架構師進行密切的溝通。開發未動，架構先行的準則是保證系統未來不會宕機和崩潰的重要準則。所以你不要期望“老牛破車”的架構和框架之上，能繼續朝裡面新增或者迭代什麼功能，也無需指望它能夠跑的有多快，有多遠。甚至，更多的可能是，你在專案功能進行迭代的時候，它已經無法相容和承受這麼多的“負荷”，變得支離破碎，牽一髮而動全身，瞬間就宕機掛起。系統架構和框架的前瞻性、靈活性、相容性是分散式開發、多使用者併發環境裡必須要考慮的重點和難點問題之一。
5、快速高效驅動業務方明確系統關鍵邏輯和規則
前面已經很明確了，留給開發團隊僅有的2個人員的開發時間沒剩下多少啦。如果你還不主動出擊，驅動關鍵業務方，明確系統邏輯和規則。就會導致後續再多的開發人員都需要無休止地熬夜加班。儘早地確定系統邏輯和規則，本質上是為了給開發、測試人員節省更多的時間，來保證系統的質量和效能。系統邏輯和規則的確認，最好的方式是最終都能夠用正式的郵件確認和統一過。業務方不會明確地告訴你，業務規則和邏輯是什麼樣子的。所以需要你主動牽引，按照需求會議的討論內容、結合你對業務的理解、對使用者的研究整理出符合當前的系統邏輯和規則，並最終請業務關鍵人員進行確認回覆。因為只有明確統一了邏輯和規則，你才正真地為開發人員掃除了顧慮和障礙，才能在有限的時間內，聚焦在業務邏輯和規則的實現當中，而不是寫一行程式碼出現一個的疑問，然後朝你問十萬個為什麼。然後僅有的時間又會浪費的解釋和思考當中。所以一個合格的專案經理，對專案的思考和規劃需要是最全面的，並且都能夠是前瞻性的，至少比團隊單中任何一個人都需要有超前思考。
最後，專案經理需要調整心態，控制好自己的情緒。無論是什麼原因造成的資源不足，作為專案經理你一旦接受了專案，無論出於什麼原因、目的，你都必須想辦法把事情做好，把專案做成功；另一方面，專案經理不需要委屈求全，專案經理必須學會最大限度保障自己的利益。你不可能令所有的干係人都滿意，但你能做到的是，讓自己的努力讓自己滿意，用心平衡內心就好。
軟體專案管理中10大知識領域中（整合、範圍、時間、成本、質量、人力資源、溝通、風險、採購、干係人）專案資源不足的情況，或許是最常見，但卻最棘手。但其實，廣義上講還有如下資源不足的情形：
1、權力不足以掌控專案全域性？
因為很多公司，專案經理沒有實權。專案立項的時候沒有任命和宣佈。專案啟動的時候沒有授權和介紹。就這樣你在無形之中成為了PM，和產品經理一起做需求分析、系統規劃設計。而且很多時候，連產品經理都沒有，你既是PM又是產品經理。沒有權利，而這個專案又有太多的專案干係人需要你去協調和驅動：需要將那些未建立健全的專案流程制度落地規範起來，需要將那些模稜兩可的系統邏輯、規則明確統一起來，需要將那些使用者並不是很清楚的需求引導梳理出來......不一而足。這樣的過程中，很多小白一樣的干係人，總會抬起無辜的眼神，憤憤不平地問：這件事情分配給我做的理由？如果真要分配請郵件抄送我的直屬上級。這是一個無正解的話題。干係人不屬於專案團隊成員，你沒有權利要求他做任何一件與你現在負責的系統產品有關的任務，即便這樣的工作任務明明是在他的職責範圍之內。如果有這樣的情況，那是你的方式錯了。在職場上事不關己高高掛起是一種普遍現象，你不能期望所有的人都想你一樣熱心地忠誠於自己的職責。所以，專案經理不是萬能的英雄，該需要請BOSS來分配的工作任務，就不要怕麻煩他。因為你權利不夠啊。
2、時間不足以制定周密的計劃？
凡事預則立，不預則廢。專案計劃的重要性不言而喻。但需求在變，計劃總是趕不上變化。如果你之前做過開發，根據專案任務評估出的計劃還基本靠譜；如果沒有，那隻能和開發人員溝通交流，通常沒有人願意把真實的評估時間彙報出來，開發設定冗餘時間，一方面是為了防止意外，另一方面是為了避免加班成災。所以你的計劃永遠都有拍腦袋的成分在裡面，無法周密，也無法嚴謹。“計劃趕不上變化”，恩，這意味著專案經理的大部分工作應該是培養團隊處理不可預料的變化的能力，而不是參與日常編碼和架構決策。那麼當系統上線的時間定了，你還能做些什麼來調整專案的計劃呢？
3、人力資源不足以支援專案的難度和強度？
任何一個公司都會存在資源不足的問題，但不是領導不重視。一個新規劃的專案立項和啟動的時候快到年底了，招聘會相對變的艱難很多，而且應聘者的技能和綜合素質都需要嚴格把關。在做軟體專案時，我們也不想一次就弄得自己精疲力竭。我們需要保持一個穩定的工作進度。可持續發展的團隊就像是在跑馬拉松而不僅僅是在衝刺。
如何應對？
很多專案經理習慣性地認為會哭的孩子有奶吃，一方面可以得到領導的重視，另一方面資源充足的團隊就相對輕鬆一些。就會說，要明確現狀，獲得理解和支援。但這是一句廢話，沒有任何的驅動意義，也沒法以結果為導向實現專案的交付。而且，你的潛臺詞還在說，領導眼瞎。拜託好不好，一個專案的規劃和實施，你的上司比你心裡更清楚。他不是看不到這樣的現狀，而是人力資源缺乏的現狀並不是他一時半會就能立馬解決的問題。所以，你的預防針變成溫馨提醒和進度彙報就足夠了。重要的是，基於這樣的現狀，作為專案經理能做點什麼，或者應該做點什麼讓這眼前的濃霧散開，可以窺得見一縷美好的Sunny呢。這樣的情況下，專案經理需要站在企業的角度去思考問題，要學會為企業分擔問題不足的資源可以透過培訓、外部推薦尋求資源等等。但核心的思路是在於，使用靈活而變通的思想簡化專案管理。包括但不侷限於：
1、簡化專案的解決方案，對專案功能塊和功能點進行裁剪，關注系統核心的和關鍵的功能；
也許你從一開始就設計了比較完善或者完美的專案建議書。這裡麵包含了一個巨大的專案工作範圍，你的SOW和WBS可能也寫的很詳盡。但此刻，你的團隊裡只有2個後端開發人員，沒有前端工程師、沒有資料庫開發工程師，也沒有測試人員來保證專案的質量。這是一個多麼悲傷的話題啊，就像你選定好了要演奏的曲目，確定了音樂會的時間和場地，但僅有2個音樂師能夠出席。所以，那個音樂指揮家在心裡揮舞著指揮棒想，可不可以把這場音樂演奏會變成音樂獨奏會。
這樣的時候，你依然需要淡定地把你的專案方案建議書和需求規格說明書重新審視一遍。結合使用者需求思考和權衡，哪一些功能是目前比較關注的，而哪一些功能是未來系統需要關注的。這個其實並不難，如果你有和使用者開放地溝透過，專案功能的輕重緩急，你都心裡有數。所以，很有必要在他們基礎之上，整理出專案一階段的需求規格說明書來。不要一味的喊叫資源不足，這樣的方式只會加重領導對你做事能力的看法，而不能解決根本問題。
2、對核心功能和關鍵任務進行優先等級排序
關於個人工作效率的經典之作《高效能人士的七個習慣》那本書裡依據縱座標（重要性）和橫座標（緊急性）來劃分任務，有如下四種組合：
1、重要且緊急，迅猛龍式的出擊；
2、重要但不緊急, 準備好未來的方案、策略和計劃；
3、不重要但緊急，學會說不，拒絕任何承諾；
4、不重要也不緊急，可以研究下隔壁的妹紙為何每次遇見你都會笑的很好看；
一個大型的專案，干係人會很多。常常會有很多年輕而對專案管理知識無知的干係人會從方便個人利益的角度出發，突然過來很莫名地給你講，XX報表要放在你的系統裡實現而且某大BOSS非常重視。這樣的時候，你需要做的就是果斷拒絕，不要給任何承諾。很明顯，這是不重要也不緊急的事情。因為凡是重要且緊急的任務，大BOSS都會在需求討論會上明確地強調多次。專案經理心裡要有一杆秤，那些人的需求是需要理會的，那些人的需求是不用多關注的。
整理完核心功能和關鍵任務的優先順序列表後，你會發現專案一半的範圍進行了裁剪。這是一個好的趨勢和結果。因為專案管理，縮減和明確專案範圍，永遠對專案的如期交付是有利的。而一個專案的實施，10個人有10個人的計劃和結果，2個人也有2個人的計劃和結果。當你無法爭取標配的資源獲得對這個專案的足夠支援時，關注核心功能、在核心功能範圍內進行任務優先排序。之後，通常困難都是一時的，規劃良好的迭代實施計劃，講縮減至一半的專案範圍，持續地補充完善起來。透過持續漸進、裁剪和分解的方式最終實現專案的成功。
3、制定持續可行的迭代計劃和週期
迭代這個單詞很氾濫，但很多人都不明白需要迭代什麼。首先要明確，在那些核心的和關鍵的功能清單中，有哪些是需要放在持續的迭代計劃當中的。不是專案所有的功能都需要迭代。成熟的功能基本都是一次開發就落地實現，如果你說要迭代設計登陸和退出功能就顯得非常逗比和無知。通常需要迭代的任務都是那些比較複雜的，業界技術不是很明確或者使用者未來期望也不是很明確的功能，比如許可權體系、報表體系等等。
迭代週期不要過短（團隊HOLD不住，時間都會浪費在程式碼分支合併衝突檢測、各種測試、bug修復、上線釋出中），也不要太長（否則失去了敏捷開發的意義），為了給不成熟的團隊留出充分的容錯時間，所以需要具體情況具體分析。這時作為專案經理的你，需要和開發探討每個里程碑實現程度。
4、設計前瞻而靈活性高的系統架構和開發框架
如果你有幸遇到一個有全域性觀、有前瞻性的系統架構師專案會順利很多。系統的架構就像交通工具的骨骼。你需要和架構師進行密切的溝通。開發未動，架構先行的準則是保證系統未來不會宕機和崩潰的重要準則。所以你不要期望“老牛破車”的架構和框架之上，能繼續朝裡面新增或者迭代什麼功能，也無需指望它能夠跑的有多快，有多遠。甚至，更多的可能是，你在專案功能進行迭代的時候，它已經無法相容和承受這麼多的“負荷”，變得支離破碎，牽一髮而動全身，瞬間就宕機掛起。系統架構和框架的前瞻性、靈活性、相容性是分散式開發、多使用者併發環境裡必須要考慮的重點和難點問題之一。
5、快速高效驅動業務方明確系統關鍵邏輯和規則
前面已經很明確了，留給開發團隊僅有的2個人員的開發時間沒剩下多少啦。如果你還不主動出擊，驅動關鍵業務方，明確系統邏輯和規則。就會導致後續再多的開發人員都需要無休止地熬夜加班。儘早地確定系統邏輯和規則，本質上是為了給開發、測試人員節省更多的時間，來保證系統的質量和效能。系統邏輯和規則的確認，最好的方式是最終都能夠用正式的郵件確認和統一過。業務方不會明確地告訴你，業務規則和邏輯是什麼樣子的。所以需要你主動牽引，按照需求會議的討論內容、結合你對業務的理解、對使用者的研究整理出符合當前的系統邏輯和規則，並最終請業務關鍵人員進行確認回覆。因為只有明確統一了邏輯和規則，你才正真地為開發人員掃除了顧慮和障礙，才能在有限的時間內，聚焦在業務邏輯和規則的實現當中，而不是寫一行程式碼出現一個的疑問，然後朝你問十萬個為什麼。然後僅有的時間又會浪費的解釋和思考當中。所以一個合格的專案經理，對專案的思考和規劃需要是最全面的，並且都能夠是前瞻性的，至少比團隊單中任何一個人都需要有超前思考。
最後，專案經理需要調整心態，控制好自己的情緒。無論是什麼原因造成的資源不足，作為專案經理你一旦接受了專案，無論出於什麼原因、目的，你都必須想辦法把事情做好，把專案做成功；另一方面，專案經理不需要委屈求全，專案經理必須學會最大限度保障自己的利益。你不可能令所有的干係人都滿意，但你能做到的是，讓自己的努力讓自己滿意，用心平衡內心就好。