rogersnotes 20200206：Roger老師Zoom限量100人_大型敏捷應用及成功案例 & 帶領專案管理團隊管理專案團隊的實務心得

更多rogersnotes, 請至bk.pm-abc.com.tw........ 訂閱/瀏覽

若您不願意收到rogersnotes，請點按此處進行退訂:http://www.pmsuccess.net/subscriber.asp 或直接回覆本信件通知我們為您處理。

【敏捷社群Zoom讀書會預告，歡迎加入敏捷社群以參加活動】

主講人:周龍鴻

分享日期:2020/2/12(三)21:00 @ZOOM

分享主題：大型敏捷應用及成功案例

你想要知道大型敏捷如何推動嗎?如果你的團隊是Scrum是4-8個團隊，可以採用LeSS。如果是8個團隊以上甚至是超過百人到上千人，則可使用LeSS Huge。

許多人常常會問到敏捷開發是以小規模團隊3-9人為1個團隊進行開發專案，但大多數人經歷的專案規模都很大，專案團隊的成員也很多，那麼還能用敏捷嗎? 答案是可以的。延續2019/11/27 Roger老師分享如何推動，這次Roger老師要分享三個不同產業的大型敏捷實際案例:BMW如何用LeSS開發電動車及無人駕駛車、華為如何用LeSS開發高度競爭力的5G電子產品、PMI-TW如何用LeSS翻譯PMBOK為繁體中文，這些成功產品都以精簡規則的方式創造團隊責任的最大化。

這種方法在許多大型公司驗證是可行的。本次演講分享三個不同產業的大型敏捷實際案例，BMW如何用LeSS開發電動車及無人駕駛車、華為如何用LeSS開發高度競爭力的5G電子產品、PMI-TW如何用LeSS翻譯PMBOK為繁體中文，這些成功產品都以精簡規則的方式創造團隊責任的最大化。

本線上讀書會並未對外部社群開放，若要參加活動, 歡迎用手機點以下連結加入敏捷社群

http://line.me/ti/g/LJ-VW1tKmm

FB活動連結，歡迎轉分享：https://www.facebook.com/events/465009237521763/

帶領專案管理團隊管理專案團隊的實務心得

前言：

我的工作是位於西方價值觀、東方價值觀的交會點，關於這篇專案管理實務心得分享，是受教於長宏教授群的啟發，整理出過去、現在從事大型專案管理工作「實務上」的深刻體會和心得。整理的順序是約略依照專案的五大流程組，按起始、規劃、執行、監控、結束的順序來敘述，以下分別來說明。

一、客戶是衣食父母，需求難道不能改：先訂好需求逐步完善程序

和客戶、重要利害關係人交換完名片後，我們期待利用蒐集需求程序，讓客戶的需求明確化，發展成需求文件、需求追溯矩陣，用來作為後續專業服務工作的依據，免得做白工、重工，必要時，作為增加經費的依據。客戶也不是省油的燈，不想將它明確形諸文字，萬一現在講得太清楚，將來要改變主意不就留個把柄給人家?被廠商拿來當作補償、爭訟的依據?

這個問題想來很有趣，因為很大一部分的專案管理顧問是客戶(甲方、買方、業主)請來的專案管理顧問，責任是在保護客戶的利益。身為專案經理，我們究竟該不該將客戶的需求明確化?還是協助客戶保持模糊，俗話說不把話說死，讓將來商業環境改變時留有緩衝解釋餘地?實務經驗上，我的體會是，客戶的確有改變想法的權利，因為沒看到半成品，客戶很難想像會買到什麼樣的產品或服務。因此，專案進行到一半時，客戶改變原先的主意幾乎是接近常態，見怪不怪。特別是我們是客戶請來的專案管理顧問，需要保護客戶的權利，幫客戶把黑的說成白的，說不成白的，只少是灰色的。

這時候，就要在專案一開始訂好一個逐步完善的蒐集需求程序，在專案最前面的階段蒐集初步的需求，並雙方約好，在專案進度到某一個里程碑時，再進行檢討一次已蒐集的初版需求。當然，蒐集需求不能一直進行到案子快結束還在蒐集需求，甲乙雙方需找到一個平衡點，讓需求的蒐集是一個逐步完善的動態程序，避免雙方在執行階段產生履約爭議。

二、任務認知的落差：範疇、範疇說明必須沒有模糊空間

客戶和其服務廠商90%以上多會簽訂契約。但契約僅是文字化甲乙雙方的「協議」，加上談契約的人往往不是甲乙雙方的負責人，因此，層層轉知之下雙方對於專案服務範疇的原意旨往往偏離文字的撰寫內容，加上契約文字透過雙方解讀，又將偏離x2(不好的狀況)或將偏離/2(好的狀況)。好的狀況當然沒問題，若是不好的狀況，雙方各自對於契約文字的認知偏離甚大，又不明說(特別是東方人的特性)，就往往是雙方履約爭議的肇因。

範疇保持模糊以求取最大利益，是台灣(或東方人)特有的風俗民情。發現問題不直說、有被點到再說、沒被發現就不說、等到要結案沒出包再說。這樣的專案管理模式讓西方人認為東方人是一個不勇敢、不直率、不坦誠的民族，也因為這樣，台灣人的事業總是(誇飾法修辭，一般來說是這樣)做不大，適合作中小企業，適合作代工。

三、執行階段，管好兩個人：人資、利害關係人

專案管理工作要做好，專案經理要花很多時間在協調事情上，我的經驗也是，花大概80%的時間在協調。有人才有事，協調事情其實就是在協調人，內部有人力資源要協調、對外有利害關係人要關注。而達到這樣的工作目標，就是在做管理溝通的工作。管理溝通其實也就是向利害關係人報告的流程，平時有議題要記錄，在適當的時機向利害關係人報告重要議題。別忘了，專案是替客戶提供服務或產品，最後由客戶進行驗收，搞定客戶溝通，才是提升專案品質的王道。

四、每個人其實都是好人：是專案溝通出了問題，報告藝術要修鍊

在夜深人靜的時候，仔細想想，專業者經過各自的專業訓練，都是一時之選，為什麼處理同一個專案卻會有衝突?除了特殊的道德狀況之外，其實是專案溝通出了問題。專案的溝通必須基於溝通的需求，特別是關係人的溝通需求，who/when/how，制定溝通方式、計畫(規劃溝通管理)，確定關係人的信息需求、類型、格式、價值，促進專案有效率溝通，並進一步作為管理專案團隊、進行衝突管理的媒材，而專案經理特別是需要修鍊：報告的藝術。

五、內驗外確，產品被接受的關鍵在客戶開心

有些事情沒上課不知道，交付標的被接受的關鍵不是品質，是客戶開心。當然，客戶開心不是指專案經理不務正業，而是必須提醒自已，專案經理除了對內控制專案品質之外，很大一部分責任是在對外代表專案管理團隊，和客戶及利害關係人保持密切、良性的互動。

而千萬記住，我們面對的是「客戶、客戶授權的中階主管、客戶的承辦人、利害關係人」這樣一個組織關係，而客戶的承辦人、客戶的中階主管絕對不代表客戶。身為專案經理，溝通的層級一定要到達客戶本身(盡量吧)。很多專案經理一直不懂，我的專業素養這麼高、專案品質這麼好，為什麼不被客戶接受?真是懷才不遇，天理不明，有志難伸，天妒英才。其實，把利害關係人搞清楚，利害關係人和你的專案產出能不能被接受有密切關係。

結語：

很多專案是工程，但專案管理絕對不是工程，而是管理，更絕對不只是工程師的頭頭。這是上完Roger和長宏老師的課後，給工程出身的自己的一段Lessons Learned，激發了自己對於專案管理的重新認知，也因此了解，管理人、時、錢、品質，並且作整合和風險控管，發揮專案經理的管理藝術，是專案管理的核心。

作者：林威宇,PMP

作者簡介：林威宇,PMP，美國美商誠國際股份有限公司台灣分公司主任技師，長年專注於專案管理、土地開發規劃與都市規劃設計專業，為美國科羅拉多大學丹佛分校都市設計碩士，並為台灣註冊都市計畫技師、台北市都市計畫技師公會會員。

有一種職場中的教練「Scrum Master (SM)」，

如同龍舟的擊鼓者，面向團隊、鼓舞士氣、激勵團隊成員，邁向目標，

他能帶領團隊自主、能創造相互信任、協同合作的工作環境。

他願意引導，不怕團隊犯錯、追求逐步完善......，

他是創造商業利益與企業價值的關鍵人物，參加Scrum Master讀書會，

讓你有深刻務實的啟發體驗，學習正確敏捷的觀念，

讓你可以成功引導團隊成員自我「提升生産力」，視團隊產能倍增。

運作: 每月第一週三21:00舉辦線上Zoom讀書會, 邀請SM高手為您分享

加入方法, 請用手機點連結: http://line.me/ti/g/LJ-VW1tKmm

讀書會免費原因: 推動敏捷市場長達五年,

與大陸CST合作培育台灣過半數約500位CSM,

已占台灣一半的市場的人數, 此社群為SM搖籃

＜＜上一則 rogersnotes　　回 rogersnotes 主選單　　下一則 rogersnotes＞＞

rogersnotes 無償分享筆記, 歡迎分享給好朋友. 分享檔案著作權屬 rogersnotes®所有,
欲在公開場合使用rogersnotes® 著作請按此下載使用同意書.roger 連絡Email: PMSuccess@gmail.com
非常滿意　滿意　普通　不滿意　非常不滿意　
退訂或推薦您的朋友共享rogersnotes, 請由此進入