在產品經理的工作中，除了需求調研、需求分析、畫原型等，項目管理也是產品能否成功上線的關鍵。本文作者總結了產品經理可能會遇到的7個項目管理問題，希望能給你帶來一些幫助。
進入職場後，筆者才深刻感受到，需求調研，需求分析，畫原型等只是產品經理工作的一小部分內容。項目管理也是產品是否能成功上線的關鍵。部分組織結構比較細分的公司會將產品經理和項目經理兩個職位劃清界限，但是筆者了解到的大多數企業都要求產品經理擁有項目管理的能力。
畢業後筆者的第一份工作的崗位名稱叫「需求分析工程師」，歸為項目部，平常對外對接工作時統一作為項目經理的身份，但我們實際的工作內容卻涵蓋了產品經理+項目經理的所有職責。因此除了學到如何更好地設計系統產品之外，我也在項目管理的過程中一步步升級打怪，逐步成長起來。
接下來筆者將從一個產品小白的視角講述在項目管理過程中遇到的七大問題，並結合工作經驗及閱讀的相關書籍以及pmp備考過程中學到的知識對這七大問題進行解讀並給出建議。
其中主要涉及到的書籍除了《PMBOK》外還有「IT項目管理案例解析」《知易行難：58個IT項目管理案例解析》。如果有時間的話大家可以看看劉羚的《知易行難：58個IT項目管理案例解析》，書中的每個案例均由「案例故事」、「案例分析」、「小結」三部分組成。案例類型豐富，從單項目到多項目、從乙方項目到甲方項目、從個人到組織，全方位、多角度地揭示了項目成敗的原因。
下文案例提到的相關角色統一用「項目經理」，但這些同樣可能是產品經理會遇到的問題。
其中包括：應該遵循何種工作邏輯、如何接手新/半截項目、不懂技術怎麼辦、如何搞清需求、進度落後怎麼辦、客戶需求頻繁變更怎麼辦、客戶要求壓縮進度怎麼辦。
一、應該遵循何種工作邏輯
項目中出現的所有問題項目經理都有責任解決。但同一個問題交給不同的項目經理處理很可能出現截然不同的結果。造成這個現象的因素有很多，其中包括項目經理的項目管理經驗、溝通協調能力、資源分配能力、遵循的工作邏輯等等。而對於小白來說，經驗及能力需要通過時間及項目的沉澱才能獲取，而能較為快速學習到的就是正確的工作邏輯（頂層工作邏輯）。
工作邏輯分為底層工作邏輯和頂層工作邏輯。
什麼是底層工作邏輯？
就是項目經理在面對各種項目管理的相關問題時，會主要從項目的視角出發，為滿足項目足額回款、高質量交付、客戶滿意等關鍵指標，在項目實施交付過程中的一系列管理計劃與監控控制。
什麼是頂層工作邏輯？
就是項目經理在面對各種項目管理的相關問題時，會主要從公司戰略的視角出發，識別項目的核心目標（利潤/客情/經驗/人才/試點/其他戰略目標）,深刻理解本項目對公司的核心價值是什麼，再從對應角度尋找合適的解決辦法。而不僅僅只是為滿足項目足額回款、高質量交付、客戶滿意等關鍵指標來進行決策。
筆者接下來將用自身的經歷來展示遵循不同工作邏輯的人會分別如何處理工作中的問題。
1. 案例背景
筆者的公司為一家專門為政府提供IT服務的企業，2022年8月與政府簽訂了某項目合同，負責一個市級系統的建設工作，預計2022.11月上線。而在9月中下旬，客戶突然提出變更需求，原因是省級系統已經先一步建設完成，為防止重複建設，市政府要求停下所有開發工作，讓公司派人重新進行調研新需求，代替原本合同里規定的模塊。但此時公司對於原項目的開發進度已經接近70%，若按照客戶的意思，此項目將帶來巨大虧損。
突如其來的變動讓公司的人都措手不及。為使得項目不虧損，公司的市場人員多次與客戶協商，希望其能繼續開發，重複建設的系統可用來做數據回流，方便本地管理數據，但客戶對此建議並不滿意。但政府對於此項目的撥款已申請下來，若要再縮減預算流程也及其複雜繁瑣，所以客戶希望公司再次進入政府其他部門進行調研，設計一些新的系統代替原擬定的功能系統。為滿足項目足額回款，似乎只能這麼做，但是這將花費更多的人力資源及時間，總的來看還是虧損的。兩邊僵持不下，項目眼看就要爛尾。
2. 解決方案
在將此事上報給領導後，領導帶著我一起拜訪了客戶方項目的決策者。在長達兩個小時的交談後，客戶滿意地將我們送出門，並表示希望了解更多公司的項目，以後可以多加合作。
那這兩個小時裡到底發生了什麼致使客戶的態度發生這麼大的變化，又是什麼讓本來大概率會爛尾的項目成了公司未來獲取更多業務機會的基礎呢？
在這兩個小時裡，前面大概有一半的時間領導都在和客戶聊天，當然不是普通的嘮家常，更多的是跟客戶了解其內部有哪些業務處理起來不夠高效，急需通過系統線上化的需求。在了解他們痛點的同時，再介紹我們公司涵蓋的產品線有哪些是可以解決這些問題的。
當時公司的研發部正在研發一套人工智慧的新技術，研發已經步入最後階段，但是由於暫時沒有客戶，所以技術可能存在部分未察覺的漏洞，急需進行試點進而優化產品，而這項新技術正好能解決客戶部分監管的需求。領導表示可以免費為客戶提供此試點服務，並且可以再額外幫客戶新增功能模塊解決新需求，這些新的內容無需變更到合同里，都是免費為客戶做的。但是原合同里的建設內容也希望繼續按流程走下去，最後的驗收也按照原來的計劃進行。
客戶聽了很是心動，同時也問道：「這樣你們不是虧了嗎？」領導笑笑說這都是應該的。客戶很是滿意，同時主動要求我後面整理一份詳細介紹公司現有項目的文檔發給他們，表示後續有很多其他業務需求想和我們溝通。
3. 結果
之後項目便依據此次交談的結果有條不紊地進行著。最後項目成功驗收、公司的新產品得到試點反饋、公司得到了客戶的高度評價。
如果僅僅從項目成本及回款來看，此項目是虧損的。但真的是虧損的嗎？
在了解了工作的頂層邏輯後，我們很容易看出領導此次交談主要從公司戰略的視角出發，將項目的核心目標定為客情和試點，最大程度地讓客戶滿意，減少對利潤的關注。在了解客戶需求的前提下，推薦公司對應試點產品。這一舉無疑是成功的。
也是因為這件事，我更加深刻地明白了評判一個項目的成功與否不僅僅可以從利潤的角度，主要看工作的指導核心是什麼。例如：
A項目：最終項目盈利20%，客戶滿意度低，項目經驗沒有提升。
B項目：最終項目虧損20%，客戶滿意度高，項目做了新的試點創新。
如果以利潤率為工作指導核心，A項目顯然更成功；但如果以項目持續性發展的眼光來看，顯然B項目更成功；
雖然關於公司項目的頂層戰略主要是高層決定的，但項目經理和產品經理工作時也應了解不同項目的核心目標，用頂層工作邏輯看待問題，解決問題。
二、如何接手（新的/半截的）項目
新人在入職後，在了解公司業務之後必定就要開始接手項目了。那麼只有兩種結果，要麼是獨立負責一個0-1的全新業務，要麼是半截接手一個項目。兩者本質上是一樣的，即都要面對一個全新的業務，一個全新的團隊，這很考驗項目/產品的能力。
那麼職場新人很可能在接觸新業務的時候面臨頭疼的問題，面對不同的問題，筆者給出了一些建議。
問題1：項目流程複雜，涉及到的人員居多，很難短時間搞清楚項目的邏輯細節
解決方案：
1）自上而下思考問題
接觸一個新項目的初期很容易陷入細枝末節中，這時就需要及時抽離，做到自上而下思考問題。同時尋找各部門經理+各業務關鍵人物訪談就是一個好辦法，能夠很好地從宏觀角度了解項目，發現問題，從而制定方案解決問題。
2）承認「術業有專攻」
有些項目經理，在技術這一環節上就會糾結半天，有的人不能容忍自己對項目的技術有不懂的地方，花很多的時間去攻堅，結果技術還沒學會，項目失控了。所以，我們要明白懂技術是產品和項目的加分項而不是必須項，可以在業餘時間花時間學習，但在項目管理過程中要發揮項目經理的職責而非開發人員的工作職責。
問題2：半截接手的項目很可能存在很多上一任項目經歷留下的隱患，如何識別並解決呢？
解決方案：
1）全面了解項目的情況，將項目當前的狀況、存在的問題，以及可能出現的風險，向相關領導寫個詳細的報告。
2）後續的項目過程中格外注意和領導、客戶的及時溝通，一方面這是項目的管理需要；另一方面也是讓領導知曉項目狀態，日後可減輕些自己的壓力。
3）溝通要有閉環。很多項目對程序bug的管理比較散漫，在溝通方面極易產生嚴重漏洞。一個問題從提出到記錄到分析到解決，一般會涉及至少3個人及環節，所以問題登記一定要規範才行。為了避免推諉扯皮，環式溝通是最合適的，如圖1所示。而很多項目中採用如圖2所示的鏈式溝通是不合適的。
圖1 環式溝通
圖2 鏈式溝通
三、不懂技術怎麼辦
在項目實施過程中，經常會出現一些技術和商務問題是項目經理不太懂、不了解的情況，這很正常。這時要樹立威信的關鍵是項目經理要懂得尊重內行，充分挖掘員工的才能與潛力，而且能夠安排信得過的技術人才做自己的左膀右臂，在技術專家的輔助下選擇出最佳方案，這就可以贏得屬下的認可。
項目經理不能僅限於自己日理萬機、埋頭苦幹，必須花時間、花精力，通過項目例會、技術研討會、項目評審等面對面的交流形式，以及各類項目技術文檔、管理文檔等方式和大家溝通交流。對於無法每周開例會的情況下，就要把精力集中在技術文檔上，力求開發人員能通過文檔全面透徹地了解需求。但不定時的反饋以及會議還是有必要的。
四、如何搞清需求
筆者上一個公司主要做電子政務項目，不同城市，甚至是同一個城市不同區的政府對於同一類業務的流程要求都是不一樣的，因此項目一般都是定製化開發的系統。而定製化開發的應用系統，由於其需求的特殊性，個性化要求高，會受到使用者的思想、觀念、期望和偏好的影響，以及領導風格的制約。其中具有相當部分的感性含量，很難進行量化描述，加大了需求獲取與準確理解的難度。
因此在需求調研過程中可以注意以下幾點：
1）搞清楚關鍵決策人是誰，特點是什麼，到底要什麼
如前面所述，電子政務項目個性化要求高，會受到使用者的思想、觀念、期望和偏好的影響，以及領導風格的制約。很可能一把手的一句話就會影響到整個項目的方向，因此在需求調研之前需要先搞清楚關鍵決策人是誰，特點是什麼，到底要什麼。
2）制定溝通計劃
為方便日後的工作高效進行，在正式開始需求調研之前可以先進行一些基於系統的培訓，讓參與調研的客戶對系統有個大體印象，不能天馬行空地去談；對需求的管理也應該有一個知識的引導，讓大家知道需求不是想什麼就說什麼，而是基於合同範圍框架下的溝通，不能超出一定範圍；或者將調研時需要提問的問題整理成問卷，提前下發；或者在現場根據問卷逐步進行引導。需求調研不能一上來就去找主要負責人，而是先在合同或技術協議範圍內，自下而上，從粗到細，循序漸進地進行。
3）文檔約束
要特別注意，對於在項目前期尚未確定，或存在一些日後極有可能變化的需求因素，要在用戶需求說明書（或需求規格說明書）的「假設與前提」條款中明確做出描述；對於限制系統實現的外部環境，包括資金、人才、資源、條件、政策等約束條件，也應該進行必要的調查與分析；對於系統的外部接口、資料庫、並行操作、通信協議等方面可以給出特定技術的限制。這些內容都是日後進行技術設計和系統測試驗收時的重要評判依據。
4）了解項目的隱性需求信息
包括了解客戶的組織結構和機制，了解客戶當前存在的問題和改進的可能性，在調研需求前先搜集資料，做足功課，不能盲目把寶壓在對方某個人身上，確保客戶、最終用戶和開發人員達成共識
5）了解清楚系統的性能指標
在進行應用系統建設的需求分析時，不能僅關注用戶的功能需求，還要關注業務功能之外的如性能、安全、接口等其他方面的需求。這些方面用戶往往在介紹業務需求時不會提到，一般人也意識不到，可以說它們是潛在的。只有在系統在聯調和運行時，它們的影響才會暴露出來，而且很可能是引發系統故障甚至崩潰的關鍵因素
6）先演示後開發
在項目前期需求不能明確的情況下，建議開發商先不要急於開發正式的系統，而是採用快速構建原型系統的方法，將抽象的用戶需求、操作界面和未來真實系統的運行情況，用原型系統和虛擬數據模擬表現出來，以此作為和用戶進行溝通的有效媒介。
將抽象的概念變成看得見、摸得著的對象，讓最終用戶直觀地看到系統的「模樣」。這樣可有效增加用戶對日後產品的感性認識，引發他們提出更深層次的功能與性能要求。由於對原型系統的修改與調整比較方便、快捷，即使反覆修改幾次投入的資源也相對較少。在雙方對需求達成共識後再以此為藍本開發正式系統，可以有效降低項目風險和投入成本，避免返工，並加快項目整體的實施進度。
五、進度落後怎麼辦
項目管理過程中難免會遇到工作進度和當初的計劃不一致的情況，無論是工作提前完成還是進度落後，一開始的進度計劃都脫不了干係（工作提前完成並不代表項目沒有問題，這反而說明項目一開始的進度計劃是不科學的，安排的工作計劃不飽和，浪費了人力）。而相對於工作提前完成，大家對於進度落後會更加有恐慌感，那麼如果項目進度已經落後了，項目經理該怎麼辦呢？
1）調整自身心態，穩定團隊情緒
項目經理是項目團隊的核心，是靈魂人物。一旦調整進度不可更改必須執行的話，項目經理自己不能產生動搖，至少不能在團隊成員面前表現出畏難情緒，最糟的就是和組員一起抱怨客戶，抱怨公司。在調整好自身心態的同時，也要帶領團隊團結一致向目標努力。進度嚴重落後時項目組成員很可能要面臨加班，那麼對於他們可以做到以下幾點：
- 強調項目完成對於公司的重大意義，激發組員的責任心和榮譽感。
- 鼓勵大家超越自己，如項目正常完工，公司範圍內進行宣傳和表彰等。
- 調整計劃時，特別注意發揮骨幹的作用，讓其感受重用和信任。
- 開展一些遊戲類的比賽和集體聚會，建立團隊中和諧溫馨的人際關係。
- 技術層面，優化進度計劃有很多方法，如識別活動之間的依賴關係、分析關鍵路徑、優化資源組合等。
總之，項目經理要做的事情很多，首先自己要調整好心態，其次要做一些努力並鼓勵團隊成員一起為項目付出努力。
2）不能盲目增加人手
進度落後首先考慮到的應該是計劃的制定，人員分工，項目例會幾個部分有沒有做好，並做相應的調整。若盲目增加人手，還會存在新人學習業務並上手的成本，並且如果此時整個項目的計劃分工及跟進本來就存在問題，那麼後面只會帶來更多問題，使進度更加落後。
六、客戶需求頻繁變更怎麼辦
1）制定需求變更書面規範
首先，應要求針對所有的項目問題和需求，必須提供書面的登記。可以使用公司的問題登記系統，或者是Excle表，兩者取其一（考慮有些項目現場上網不方便）。無論哪種方式，每個問題都必須有編號，且唯一。在登記過程中，幾個關鍵欄位是要寫清楚的，如「問題序號」「問題提出人」「現場分析人及建議」「開發意見及回復」等。
2）客戶需參與需求的第一輪分析
無論什麼問題，項目經理必須組織客戶參與第一輪分析，組織客戶內部的定期問題歸納，評審；邀請客戶的業務經理和提出問題的客戶一起先內部評審，這一審不要緊，發現很多問題他們自己就「槍斃了」，也會讓很多隨便提問題的客戶引以為戒。一定要引導客戶審慎地考慮問題，提些有見解、有水平的問題。
3）內部評審
就問題和初步意見進行評審。項目經理、開發經理都必須在場，對問題匯總表中歸納的問題，無論大小都逐個過一遍，分清楚問題的類別、輕重緩急，然後形成會議紀要，簽字確認，納入開發計劃。會議結論不能輕易更改，必須保證評審結論的嚴肅性。
4）優先級劃分
很多不重要的問題，排到產品版本發布計劃里，還有很多好的需求和共性需求，納入標準產品研發計劃，開發出來客戶也滿意；對於有些技術難度的，或者必須推遲的，往後放一放，大家彼此理解，不能眉毛鬍子一把抓。
這幾步下來，能夠使雙方的分歧都在會上充分交流，通過這種方式大大降低踢皮球現象及拖延推諉的現象。在過程中，項目總監應全程參與，保障會議的嚴肅性。
七、客戶要求壓縮進度怎麼辦
1）與客戶溝通，告知最壞結果
如果客戶突然提出壓縮進度，例如5個月的項目周期要提前1個月，等於是提前了20%，假如原先的進度計劃是合理的，這個進度壓力就太大了。而公司又不能增加人手，那麼，項目經理就應該主動找客戶一起分析可能出現的各種後果，就像到醫院做手術，病人家屬都要簽字說明自己了解手術的可能後果，然後由病人家屬決定是否手術。
現實中，IT項目經理很難讓客戶簽一個類似的「知情同意書」，那麼這時候就要看項目經理的溝通表達能力了。筆者還原了下工作中遇到此問題的對話場景。
在告知客戶公司資源不足，無法很好地壓縮進度之後。
客戶：「資源不足不是我的問題，你應該找你領導反饋。我這邊的要求就是提前1個月完成，沒有人你自己想辦法。」
項目經理：「嗯我很能理解您的立場。是這樣的，我們公司的資源都是根據業務線提前按照計劃安排好的，我們也提前考慮到面對緊急情況該怎麼應對，如果時間壓縮的力度不大，相信我們，我們一定能很好地按照原來的風控計劃處理好。但由於這次周期壓縮了10％，比一般情況都要措手不及且棘手，當然我們也會最大程度地調用資源來儘量完成原目標，但以為咱們這個項目負責任的角度出發，我這邊就是要提前告知您之後可能會出現的最壞的結果，您可以評估一下，您方也可以提前準備一些應對措施，這樣咱們兩邊攜手起來，項目肯定會往更好的方向發展的。」
這段話包含幾個點，並且層層遞進：
- 肯定對方一些點
- 表示出對項目的重視程度，委婉表示對方的要求不太合理
- 告知風險
- 表達出需要對方的協調幫忙，大家是一個team
- 最後是一定的積極承諾，當然不要太死太具體，以免實現不了打臉
這樣溝通下來客戶一般都會按照項目經理的思路來走。
但如果公司領導支持客戶壓縮工期的要求，但是資源不夠。亦或者領導並未表態，問題也是得解決，壓縮工期是一定的了，即使達不到壓縮的力度，我們也要積極尋求解決辦法。
2）調整心態
項目突然有工期要求的變動，項目經理的壓力會變大，此時項目經理要先調整好心態，不能影響到團隊成員。
3）嘗試修改項目範圍
項目管理核心的幾個要素——範圍、時間、成本、質量是互相影響、互相牽制的。如果進度提前，在成本和質量不變的情況下，項目範圍是否可以也隨之做些調整？一些非核心的放到二期實現。
4）技術層面進行調整
技術層面，優化進度計劃有很多方法，如識別活動之間的依賴關係、分析關鍵路徑、優化資源組合等。
以上就是產品小白七大常見問題的場景及解決辦法，由於筆者認知的局限性，可能不是最優解，歡迎大家批評指正。
本文由 @是阿妹呀 原創發布於人人都是產品 經理，未經許可，禁止轉載。
題圖來自Unsplash ，基於 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平台僅提供信息存儲空間服務。