專案經理小李接手了乙個前專案經理離職的電子商務平台專案進入專案後，小李立即著手檢視了前專案經理交接的文件，然後在專案成員中調查發現： •
客戶的需求經常變化，且隨著專案的深入，每天都有新的需求出現。 •
前專案經理每天疲於應付解釋需求範圍不能變更，但是客戶認為不滿足新需求，電子商務平台可能落後於對手，堅持要求增加新需求。 •
專案合同中沒有涉及到客戶提出的新需求，客戶堅持沒有成本和資金的追加。 •
軟體**因為客戶提出的需求問題，經過了
5**的修改，**的功能版本凌亂。 •
專案團隊有人申請離職或者離開專案組。 •
找不到任何客戶提出變更的記錄，也沒有使用者需求評審的記錄。
小李面對這種情況，不知道如何是好？
這個案例大家看到了這是因為需求開發無效和需求管理失控造成的專案過程混亂，沒有標準答案，但是處理這個案例的方式包括：
第一步，小李要迅速建立專案變更的管理機制，要趕緊分析專案干係人，識別決策專案變更的ccb（控制變更委員會）的成員，不管提10個需求也好，1000個也罷，分析完對專案進度、成本、資源、質量的影響後，都要通過ccb進行決策。
第二步，要安撫好專案的團隊成員，詢問他們離職和離開專案組的真正原因，然後把問題反饋給高層領導。
第三步，重新梳理需求狀態。這一步比較麻煩，但是很關鍵和必須，列出需求清單，然後檢查每個需求現在的狀態（提出，已評審，已設計，已開發，已測試等）。
第四步，判斷需求的穩定性。哪些需求比較穩定，哪些需求變化很快，哪些需求是新提出來的問題？分析造成這種局面的原因。大致會分成：
1.業務流程不成熟，需要流程再造。
2.新業務，客戶了解的不多。
3.需求「鍍金」（過度的開發需求）。
4.需求遷移。（客戶不滿足於功能有無，需要功能公升級）。
5.干係人識別不全。
6.利益方需求衝突。
第五步，根據需求變化的原因，採取對應的措施，深度開發需求。
需求對應措施處理表
序號需求變化原因處理措施責任人
1業務不成熟
召集業務部門人員開會，討論流程方案
業務部門代表、專案經理
2新業務
對標標桿
培訓與諮詢
購書自學
業務顧問
3需求鍍金
編排需求優先順序
專案經理
4需求遷移
分析必要性，ccb決策
專案經理、ccb
5干係人識別不全
對利益大並且權力大的干係人重新識別
對利益大權利小的干係人識別出代表
專案組全體人員
6利益方需求衝突
焦點小組會議，跨部門協調會議，引導式研討會等
專案經理
第六步，做好需求的確認和版本管理工作。每乙個提出的需求，應該都能追蹤到是誰提出的，什麼時間提出的，並且要和提出人進行溝通和確認，隨口說的需求不能做為專案開發的依據。必須的，必要的，非做不可的需求才能寫進需求說明書。需求說明書應該要標註版本，每次修訂都應該有修訂記錄。設計和開發人員用的是哪一版需求，可以追溯。不僅是每次都給乙個最新的版本給大家，而是需要正式通知大家目前應該遵循的標準是哪個版本。對於歷史版本也要妥善儲存，以備不時之需。
第七步，專案經理要積極和公司內部的商務人員進行溝通，講需求變更的真實原因說清楚，整理好哪些原因的變更應該由客戶承擔責任，哪些原因應該內部承擔，有理有據的公布狀態。商務人員可能會走合同變更。
第八步，認真做好需求的評審工作，將評審的結果要及時通知各方，監控各人員的態度和反應。
小陳是乙個移動化軟體開發專案的專案經理，他現在目前的專案狀況是： •
客戶對未來的軟體產品需求不是太清楚，希望小陳能夠給出一些設計方案可供選擇，但是每次提供的設計方案，客戶代表都覺得不滿意，但是會根據小陳的設計方案提出非常多有別於過去想法的新需求。 •
小陳在一次匯報會議上講解了一套最新得到客戶代表默許的設計方案，但是客戶方的領導當即就表示出該設計方案不滿意，要求重做。 •
專案組的成員也對小陳感到不滿，認為付出了工作量，但是客戶不認可的原因是因為小陳溝通做的不好，客戶提出的一些「鍍金」功能可以不必理會。
這時，公司領導詢問小陳專案狀態，小陳應該如何處理？
案例三：小黃做一名自動化生產專案的專案經理，專案3
月份開始時，對專案工期和成本進行了估算，認為專案工期至少要6個
月、7人、30
個人月才能完成。
但是客戶方提出專案必須在8月
1號上線，小黃認為如果按照合同範圍，這是不可能提前乙個月完成的工作。
另外，小黃從人事部獲悉，專案組要求的
7個人，目前還有
4個招聘任務沒有完成，且不知道是否能夠在
4月份召齊小黃需要的專案人員。
但這時，公司領導對小黃下了行政命令，要求小黃加班也要提前上線。
小黃應該如何處理這種情況？
小張原本是名技術人員，因為公司有乙個臨時緊急的專案而被任命為專案經理，公司領導認為小張技術紮實，客戶需求並不複雜，小張完全可以勝任。
小張對使用者進行了兩輪調研後，發現情況和領導說的一樣，順利的通過了設計評審和內部測試，但是讓小張萬萬沒有想到的是進入使用者驗收測試時，發生了如下情況： •
使用者對小張專案組開發的系統功能並不滿意，並且提出了很多新的需求。 •
有使用者告訴小張，因為公司內部有些業務調整，所以你必須把變更的業務流程重新做一遍才能驗收。 •
客戶方的領導對小張專案組表示不滿意，認為小張專案組開發的系統沒有達到他們當初設想的管理要求。
小張覺得非常委屈，請問小張專案的問題到底出在**？
小王是名有
3年工作經驗的專案經理，在一次開發實施類的專案啟動時，小王做了非常細緻的計畫，尤其是擔心客戶不配合專案工作產生拖延，制定了一套客戶方和專案組臨時的管理組織結構，並對每個角色都寫了詳細的工作責任說明。
小王在專案的執行過程中，發現客戶並不是按照之前承諾的工作職責履行自己的工作，經常按照自我的理解完成工作任務，這給專案組帶來了很多意想不到的麻煩，很多既定的計畫不能按期完成。小王儘管重申了多次客戶方的專案職責必須履行義務，但是遭到了客戶方高層領導的批評，認為小王只要做好自己份內的事情就可以了。
小王覺得非常委屈，但是也不知道問題到底出在**，也不知道該如何解決。
上海消保委 餓了麼多等5分鐘邏輯有問題
9月9日凌晨，外賣配送平台餓了麼發文官宣會盡快發布新功能 在結算付款時增加乙個 我願意多等5分鐘 10分鐘 的小按鈕。如果你不是很著急，可以點一下，多給騎手一點點時間。餓了麼還表示，餓了麼會為使用者一些回饋，可能是乙個小紅包或者吃貨豆。餓了麼會對歷史信用好 服務好的優秀藍騎士，提供鼓勵機制，即使個別...
專案執行 專案中問題
多部門，多人員參與 1.確定專案總負責人，及時協調各方任務和人力 2.晨會溝通當天任務，同步專案進展 15min，晨會不做小組討論 3.同步專案進度和風險，已知風險確定解決方案或解決時間 下班前 前期調研不足，開發延期 專案已啟動，開發中期發現前期調研不足，不能按時交付測試 提測質量較差 bug堆積...
專案問題細節
最近專案很有問題，關於客戶需求，我們表現出來的就是很沒有經驗，很不專業。1.客戶要求的急，需要24小時不停的解決，但是由於人數有限，不可能不讓人睡覺，在這種高度緊張的條件下，發布的版本的質量也可想而知。2.客戶發現乙個問題就出版本，然後測試，又發現了新的問題，又出版本，這樣頻繁的折騰，最後只會像電腦...