項目經(jīng)理個個看起來威風凜凜，無所不能。上與老板講管理，下與員工談代碼，中間還能忽悠用戶。
可是真實情況是，項目經(jīng)理大多數(shù)情況下只能是“拳打南山敬老院，腳踢北海幼兒園”。別說遇到苛刻的老板了，遇到點比較難纏的用戶也是“帥不過三秒”，立馬現(xiàn)出屌絲原形，分分鐘被碾壓成渣。
情景一
當項目經(jīng)理和用戶討論系統(tǒng)時，用戶要求加入他所想的功能。
項目經(jīng)理：“根據(jù)對項目需求分析，這個功能不太符合系統(tǒng)業(yè)務邏輯。”
用戶：“這個功能，我就要！我就要！”
項目經(jīng)理：“根據(jù)項目風險評估，這個功能可能會對系統(tǒng)產(chǎn)生不良影響。”
用戶：“這個功能，我就要！我就要！”
項目經(jīng)理：“根據(jù)項目進度安排，這個功能會造成項目延期。”
用戶：“這個功能，我就要！我就要！”
項目經(jīng)理：“相比于你提的新功能，我們有更好的替代方案。”
用戶：“這個功能，我就要！我就要！”
項目經(jīng)理最終無奈地根據(jù)用戶要求添加了可能對系統(tǒng)產(chǎn)生不良影響的功能。
情景二
用戶所要求的功能添加后，系統(tǒng)使用不暢，用戶要求修改。
項目經(jīng)理：“現(xiàn)在對系統(tǒng)進行修改會影響項目進度。”
用戶：“我不管！我不管！系統(tǒng)必須馬上改！”
項目經(jīng)理：“當初的功能設計是你們的要求進行建設的，修改系統(tǒng)需要進行重新評估。”
用戶：“我不管！我不管！系統(tǒng)必須馬上改！”
項目經(jīng)理：“這個功能不涉及核心業(yè)務，需要放置在其他功能完成后再進行變更。”
用戶：“我不管！我不管！系統(tǒng)必須馬上改！”
用戶的訴求鬧到了領導處，為平息用戶的牢騷，領導決定讓項目經(jīng)理進行用戶需求的變更，項目經(jīng)理郁悶地接受了任務。
情景三
用戶準備休假，想要項目盡快完成，限定項目經(jīng)理提前完成項目。
項目經(jīng)理：“你限定的完成時間比項目合同規(guī)定完成時間提前太多。”
用戶：“限定期前完成，就立馬開始驗收程序。”
項目經(jīng)理：“有額外的項目變更，項目工作量有所增加。”
用戶：“限定期前完成，就立馬開始驗收程序。”
項目經(jīng)理：“項目開發(fā)人手不夠，沒有額外的資源調(diào)配。”
用戶：“限定期前完成，就立馬開始驗收程序。”
PMO部門了解用戶提出的提前驗收承諾，于是要求項目經(jīng)理在用戶規(guī)定期限前完成項目，但是僅提供了有限的資源支持。趨于崩潰的項目經(jīng)理帶著開發(fā)人員，沒日沒夜的苦逼加班，終于在用戶規(guī)定期限前完成了項目。
頂著黑眼圈的項目經(jīng)理滿懷期盼的找到用戶，要求開始驗收程序。誰知用戶雙手一攤：“驗收的事情歸領導管，有什么事情等我休假回來再說。”
項目經(jīng)理終于被逼瘋了。
看了上面的場景，你還覺得項目經(jīng)理是個牛X的職業(yè)嗎？如果你真的像上面的項目經(jīng)理那樣被逼瘋，建議你還是進行一下PMP培訓。
要還是不行，那我也沒轍了。不信，你試試？
