分類: Project Management
專案管理相關知識
摘要
1.教新人是管理基本功，但對忙碌的主管來說，這項差事卻可能費時費力，成效不彰。
2.教導例行性工作時，要先確認對方的程度，由主管演示一遍，再請對方操作一遍，確認要注意之處。
3.本文整理了例行性工作教學的理想步驟，以及教學時須注意的2個觀念。
王主任最近的心情不太美麗。公司新進幾位員工，每一個都非常難帶。
像是昨天，王主任拿了一本手冊要新人A影印：「20頁到25頁，你去幫我印18份。」印完一看，頁面沒有置中，紙張一對摺，左半頁的字就被切掉。「你要細心一點啊！這是給客戶的資料，很多人會把資料對摺再看，印的時候手冊裝訂處要對準中央，懂嗎？印了18份都不能用，快去重印！」
A一臉委屈地走了，過了5分鐘，他回來，王主任又一頓罵：「中間都變黑，字看不清楚啊！還有些字都扭曲變形了，你印的時候，要把書完全攤開用力壓住啊！」
好不容易印好18份影本，會議開始後⋯⋯王主任又跑出會議室：「喂，多來了兩個客戶，你再去印兩份來。啊？你不知道原稿在哪？這不是你剛才印的嗎？你怎麼都不會用點心？」
經過一陣折騰，王主任決定改變作法。今天，同份會議資料，他請新人B去印。這次，他給了詳盡指示，他把B帶到影印機旁，一邊講解、一邊把影印機的按鍵操作全部一次，印出一份完美影本。
他拍拍B的肩膀：「好了，你接著做吧！」結果B僵在原地，一副不知所措的樣子。
「我剛不是教過一次了嗎？」王主任很納悶。
主管們，別讓你的員工「思考外包」
王主任做錯了什麼？錯在他沒有先釐清兩位新人對影印工作的上手程度。王主任幾乎天天影印，但新進年輕員工，可能平時都用電腦，用筆寫字的機會都少，何況使用影印機。
教導例行性工作時，建議先問下屬：「我想請你去做這件事，你會嗎？」這句話不只能夠釐清對方對工作的熟悉度，也能引導對方提問，避免下屬陷入明明不懂、卻不敢問的情況。
人類有個不可思議的習性，當身邊有人仔細教學時，就會產生「反正我不想，他也會幫我想」的偷懶想法，變得不願思考。凡事幫下屬打點妥貼的主管，因此可能帶出「思考外包」的下屬。
理想的教學步驟，是在確認對方程度後，先示範操作一次，接著讓對方做一次，中途不插嘴、不插手，看到有錯也要忍住，留時間給對方檢查錯誤。等到對方說「我覺得應該可以了」，再一起檢查，逐一告知要注意的地方。確認對方正確操作一次後，先行離開，告訴對方「做完再叫我」，讓他獨立完成工作。
當主管不在場了，下屬遇到困難，就不會直接開口問，反而會回想主管示範的步驟、自己剛才操作的過程。記憶更深刻，重複幾次後，自然會做得更有效率。
你可以這樣做
1.別急著給答案
承上，凡事幫忙想好答案的主管，只會帶出被動、不愛動腦的下屬。作為主管，給出明確指示確實重要，但也要留下一些素材給下屬思考。
以王主任來說，若新人來問「要印幾份？」他可以回：「預計18人參加，不過有時也會有人不請自來，你覺得怎麼辦才好？」
新人可能會答：「不然我多印3份？」
這時可以繼續引導：「是不錯，但萬一用不到那3份，會很浪費紙。」
盡量提供思考線索，新人可能就會想到「不然我先帶著原稿，開會前再確認一次人數，份數不夠再補印。」
2.忍住「自己來比較快」的念頭
獨當一面的下屬，可以讓主管更輕鬆，但培育要花時間。自身能力強的主管，尤其容易因為下屬動作太慢而火大，因此萌生「與其交給他，不如自己做比較快」的念頭。
但，如果王主任很急躁，往後遇到影印問題，都決定自己處理。那他的行事曆，勢必排滿各種緊急卻不重要的任務。
主管之所以為主管，是因為擔負著管理的工作：規劃、組織、領導、控制。處理文書、操作機具、外部聯繫，這些都不是管理的工作。身為主管，要有管理自覺，耐住性子、放手練兵，才能帶出獨當一面的下屬。
＊本文經整理參考自《給主管的教科書》（商周出版）
資料來源：https://www.businessweekly.com.tw/management/blog/3008084?utm_source=facebook.com&utm_medium=social&utm_content=bw&utm_campaign=content&fbclid=IwAR2n2Qb_6oDdKwIgLcJvYp9CiPxWpdAO9pBv2TmxHoYlmRSZuyjH3I1MJLE
在我剛當上主管時，我非常迷戀管理，我管理團隊、管理人、管理資材、管理事、管理物，任何東西，我都管理，我要把人、事、物，在我的管理下，有條不紊的運行。
在我剛當上主管時，我非常迷戀管理，我管理團隊、管理人、管理資材、管理事、管理物，任何東西，我都管理，我要把人、事、物，在我的管理下，有條不紊的運行。
而在模糊中，我的心中也有領導一詞，我有時候也會用領導來取代管理，但我並沒有深究其中的差異。直到有一天，我讀到《僕人：修道院啟示錄》這本書時，書中的一句話宛如當頭棒喝，一棍子打醒我，我才發覺其中的巨大差異。
而在模糊中，我的心中也有領導一詞，我有時候也會用領導來取代管理，但我並沒有深究其中的差異。直到有一天，我讀到《僕人：修道院啟示錄》這本書時，書中的一句話宛如當頭棒喝，一棍子打醒我，我才發覺其中的巨大差異。
書中寫到：管理是管理事和物，人不能管理，人只能領導。
看到這句話，我豁然開朗。在我過去無所不管理的時代，我隱然覺得當我把對團隊、對人，改為領導時，似乎比較順理成章，而且是比較對的事。當我知道 「人不能管理，只能領導」 時，我開始徹底去分析其間的差異。
首先，事與物是死的，不論如何被人擺布，都不會有意見，所以可以任由人「管理」。而人的管理，不同的做法，就會產生不知的效果，端看人如何做而定，事與物是不會有所不同的。
可是人是不同的，人有心、有感覺，對不同的人、不同的做法，會有所回應，會有所互動，而其結果，也都會產生不同的效果。所以人不同於事和物，不會任由人來擺布、來管理，如果用錯了管理的方法，就會得到意想不到的效果。
一般而言，團隊與人對於上級主管的作為，最基本的有 3 種不同的回應： 消極的配合，正常的配合以及積極的配合 ，這 3 種回應方式會得到完全不同的結果。
如果團隊及部屬對主管的作為不認同，採取了消極的應付態度，那工作的成效是有限的，僅能得到勉強可接受的成果。
如果是正常的配合，成果會好一些，但也不會得到最佳的成果；惟有團隊積極的全力投入，配合主管的作為時，才會得到最佳成果，甚至會有意想不到的效果。
而人會用什麼方式來回應主管的作為呢？這完全要看主管是什麼人？主管用什麼態度來對待部屬？
如果主管是一個可被信任的人，主管的理念、價值觀被認同，那麼主管就是一個可以信賴的人。
而主管的作為如果正確，會用正確的方法去影響團隊成員，讓他們願意去做主管想做的事，而且是自動自發的去做，那就是積極的全力配合，會得到最佳成果。
有信任的主管，再用正確的方法去引導團隊做事，這就是「領導」，而一個有心、有感覺、有想法的人，就只能被領導。如果對人用管理，絕對不可能得到最佳的結果。
從此之後，我嘗試「領導」人，而「管理」事和物！
資料來源：https://www.managertoday.com.tw/columns/view/57806
PMBOK 第 6 版根據其目的對工具和技術進行分組。組名描述了需要做的事情的意圖。組中的工具和技術代表了實現意圖的不同方法。
專案管理工具和技術組
PMBOK 第 6 版有七組 132 種不同的專案管理工具。以下列表根據它們的組列舉了這些工具的細分。
數據收集工具
數據收集工具和技術用於從各種來源收集數據和信息。以下列表列舉了九種數據收集工具。
- 基準測試
- 頭腦風暴
- 檢查表
- 清單
- 專門小組
- 採訪
- 市場調查
- 問題和調查
- 統計抽樣
數據分析技術
數據分析工具和技術用於組織、評估和評估數據和信息。有27種數據分析工具。以下段落列舉了重要的數據分析技術。
另請閱讀：七種基本質量工具 PMP 考試指南
數據表示工具和技術
數據表示工具和技術以可視化格式表示數據和信息。有 15 種數據表示工具。以下列表列舉了一些重要的數據表示工具。
- 親和圖
- 因果圖
- 控製圖
- 流程圖
- 直方圖
- 思維導圖
- 概率和影響矩陣
- 散點圖
- 利益相關者參與評估矩陣
- 利益相關者映射/代表。
另請閱讀： 質量控制數據表示工具
決策技巧
決策技術用於從不同的備選方案中選擇行動方案。以下是兩種決策技術。
- 多準則決策分析
- 表決
溝通技巧
溝通技巧是用於在不同專案利益相關者之間傳遞信息的工具。以下是兩種溝通技巧。
- 反饋
- 演示文稿
人際關係和團隊技能
人際關係和團隊技能包括用於領導專案團隊的 17 種不同技術。以下列表列出了一些重要的人際交往能力。
- 積極傾聽
- 衝突管理
- 文化意識
- 做決定
- 情商
- 便利化
- 影響
- 領導
- 動機
- 談判
- 名義組技術
- 政治意識
未分組的工具和技術
該組包含 60 種不同工具的詳盡列表。以下列表描述了該類別中一些最重要的專案管理技術。
結論
總而言之，PMBOK 第 6 版中描述的 132 個專案管理工具是可用於成功交付專案的良好實踐。PMBOK 中的附錄 X6 將所有 132 種工具與其流程和相應的知識領域進行了映射。有關這些技術的完整列表，請參閱專案管理知識體系，第 6 版®。
資料來源：https://milestonetask.com/tools-techniques/#.YPdiThMzbMJ
PMBOK 第 6 版根據其目的對工具和技術進行分組。組名描述了需要做的事情的意圖。組中的工具和技術代表了實現意圖的不同方法。
項目管理工具和技術組
PMBOK 第 6 版有七組 132 種不同的項目管理工具。以下列表根據它們的組列舉了這些工具的細分。
數據收集工具
數據收集工具和技術用於從各種來源收集數據和信息。以下列表列舉了九種數據收集工具。
- 基準測試
- 頭腦風暴
- 檢查表
- 清單
- 專門小組
- 採訪
- 市場調查
- 問題和調查
- 統計抽樣
數據分析技術
數據分析工具和技術用於組織、評估和評估數據和信息。有27種數據分析工具。以下段落列舉了重要的數據分析技術。
另請閱讀：七種基本質量工具 PMP 考試指南
數據表示工具和技術
數據表示工具和技術以可視化格式表示數據和信息。有 15 種數據表示工具。以下列表列舉了一些重要的數據表示工具。
- 親和圖
- 因果圖
- 控製圖
- 流程圖
- 直方圖
- 思維導圖
- 概率和影響矩陣
- 散點圖
- 利益相關者參與評估矩陣
- 利益相關者映射/代表。
另請閱讀： 質量控制數據表示工具
決策技巧
決策技術用於從不同的備選方案中選擇行動方案。以下是兩種決策技術。
- 多準則決策分析
- 表決
溝通技巧
溝通技巧是用於在不同項目利益相關者之間傳遞信息的工具。以下是兩種溝通技巧。
- 反饋
- 演示文稿
人際關係和團隊技能
人際關係和團隊技能包括用於領導項目團隊的 17 種不同技術。以下列表列出了一些重要的人際交往能力。
- 積極傾聽
- 衝突管理
- 文化意識
- 做決定
- 情商
- 便利化
- 影響
- 領導
- 動機
- 談判
- 名義組技術
- 政治意識
未分組的工具和技術
該組包含 60 種不同工具的詳盡列表。以下列表描述了該類別中一些最重要的項目管理技術。
資料來源：https://milestonetask.com/tools-techniques/#.YNlAGRMzbMI
戰略
組織戰略通常包括一系列旨在實現長期目標和實現願景和使命的舉措。
戰略投資組合
一個專案可能在三種情況下進行管理：作為一個獨立的專案（投資組合或計劃外），一個內部程序，或內組合。（PMBOK 6th）
商業案例
- 一個商業案例評估舉措替代的可行性，成本和效益方面。
- 證明計劃合理的已批准業務案例會將其轉變為由專案發起人讚助並由專案經理管理的專案。
專案生命週期
專案是為創造獨特的產品、服務或成果而進行的臨時努力。
專案生命週期是專案從開始到完成所經歷的一系列階段。這些階段可以是連續的、迭代的或重疊的。專案的生命週期可以是預測性或適應性。
資料來源：PMBOK 6th
開發生命週期
在專案生命週期內，通常有一個或多個與產品、服務或成果的開發相關的階段。這些被稱為開發生命週期。開發生命週期可以是預測的、迭代的、增量的、自適應的或混合模型。
資料來源：PMBOK 6th
敏捷思維
敏捷是一種思維模式，它專注於通過一系列預定義的原則和經過驗證的實踐來頻繁地創造和交付價值。
管理
專案管理
專案管理是將知識、技能、工具和技術應用於專案活動以滿足專案要求。
專案管理使組織能夠有效和高效地執行專案。
資料來源：PMBOK 6th
原始出處: Project Management 101
責任分配矩陣[1] （RAM），也被稱為RACI矩陣[2] 或線性職責表[3] （LRC），描述了通過各種參與角色在完成任務或交付用於項目或業務流程。RACI是首字母縮寫詞，它是從最常用的四個主要職責衍生而來的：負責，負責，諮詢並告知。[4] 用於澄清和定義跨職能或部門項目和流程中的角色和職責。[5] RACI模型有很多替代方案。
RACI模型中的主要責任角色[編輯]
角色區分[編輯]
角色和個人識別的人之間有一個區別：角色是一組相關任務的描述；角色是一組相關任務的描述。可能由很多人表演；一個人可以扮演許多角色。例如，一個組織可能有十個人可以擔任項目經理，儘管傳統上每個項目在任何時候都只有一個項目經理。能夠擔任項目經理的人也可能能夠擔任業務分析員和測試員的角色。R =負責人（也是推薦人）那些完成任務的工作。[6]至少有一個角色是負責任的參與類型，儘管可以委派其他角色來協助所需的工作（另請參見下面的RASCI，以分別標識參與支持角色的人員）。A =負責（也是批准人或最終批准人）一個人最終負責正確，徹底地完成可交付成果或任務，一個人確保滿足任務的先決條件，並將工作委託給負責人。[6]換句話說，負責人必須簽字（批准）負責人提供的工作。這裡必須只有一個負責為每個任務或交付指定。[7]C =諮詢（有時是顧問或律師）徵求意見的人，通常是主題專家；與之進行雙向交流。[6]I =知情的（也是被告）那些僅在完成任務或交付時就保持最新狀態的人員；與之只有一種單向的溝通。[6]
很多時候，這是角色負責的任務或交付也可能是負責完成它（在由具有角色的任務或交付的矩陣表示負責的，但沒有任何作用負責其完成，也就是說，它是隱含的）。除此例外之外，通常建議項目或流程中每個任務的每個角色最多只接受一種參與類型。在顯示了多個參與類型的情況下，這通常意味著參與尚未完全解決，這可能會妨礙此技術在闡明每個角色對每個任務的參與上的價值。
資料來源：https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
Agile 跟 Scrum 兩個差別是什麼 ？
1. 導入敏捷就會開發很快嗎？
不會。就是這個翻譯沒翻好，員工真的會被「敏捷」這兩個字害死。
老闆最愛說：我們不是在敏捷嗎？應該可以做很快吧！（不是疑問而是肯定）
如果去把敏捷方針拿出來讀的話，沒有一個快字 。導入敏捷會讓你的團隊知道目前以及未來要幹嘛，可以更有彈性的去迎接臨時的改變、頻繁的交付，可以想像是所有人有規律的划船，無論前方有小波大浪大家不會驚慌失措。
2. 導入敏捷要全員都參與，不是產品經理或工程師在自嗨
很重要也是大家時常犯的致命錯誤，測試一直沒歸納到敏捷開發實行的一環。工作這幾年，真的時常覺得測試是產品做後把關的守門員，卻在產品改動或是各種 flow 制定把測試忘記，這樣產品的品質以及專案的估時都不會準確。
每日的晨會務必大家都要參與，並且快速同步，昨天做什麼（確定到一個任務而不是大範圍的，不然一個禮拜都聽到 RD 說在修 Bug, 也不知道目前 Bug 的情況）、今天預計做什麼以及遇到什麼問題，而主持會議的 scrum master 在會議上要知道大家進度，並且幫忙解決問題或是找到可以解決問題的人。
3. 敏捷只是一個精神，不是素描本拿來造抄
很多人開始敏捷一定從他的推廣者傑夫．薩瑟蘭的《Scrum：用一半的時間做兩倍的事》那本書開始讀起，讀完開始覺得人生好光明。但跟你打賭能夠真的跑起來得 10% 不到。
把大的東西拆小，小到可以可開發可測試可發佈。聽起來很容易，真的做起來工程師說不能這樣拆，設計師說又想改一些細節、測試跟你說沒有及時的 data 讓他測試怎麼辦…等等。如果你為了要達成「為了跑 scrum 而先去做把所有內外在環境設定好」的想法，不到一個月就會放棄。
先做再去優化吧！
把敏捷的精神不只投入到專案，也投入到你正在實行的敏捷。所以說每個 Sprint 結束的回顧會議是非常重要的。
敏捷就是快？什麼樣的公司可以跑敏捷？ Agile 跟 Scrum 兩個差別是什麼 ？
相信看了幾十篇文章後，好像還是一知半解。Agile（敏捷）是一種精神，而 Scrum 是一實現 Agile 的一個方法，還有其他的方法，例如常常拿來跟 Scrum 做比較的 Kanban （看板）；所以 Agile 跟 Scrum 是不同層級的東西。
1. 導入敏捷就會開發很快嗎？
不會。就是這個翻譯沒翻好，員工真的會被「敏捷」這兩個字害死。
老闆最愛說：我們不是在敏捷嗎？應該可以做很快吧！（不是疑問而是肯定）
如果去把敏捷方針拿出來讀的話，沒有一個快字 。導入敏捷會讓你的團隊知道目前以及未來要幹嘛，可以更有彈性的去迎接臨時的改變、頻繁的交付，可以想像是所有人有規律的划船，無論前方有小波大浪大家不會驚慌失措。沒受過財務訓練，要如何著手編列預算？2堂課，看數字、懂盈虧，掌握獲利！延伸閱讀
2. 導入敏捷要全員都參與，不是產品經理或工程師在自嗨
很重要也是大家時常犯的致命錯誤，測試一直沒歸納到敏捷開發實行的一環。工作這幾年，真的時常覺得測試是產品做後把關的守門員，卻在產品改動或是各種 flow 制定把測試忘記，這樣產品的品質以及專案的估時都不會準確。
每日的晨會務必大家都要參與，並且快速同步，昨天做什麼（確定到一個任務而不是大範圍的，不然一個禮拜都聽到 RD 說在修 Bug, 也不知道目前 Bug 的情況）、今天預計做什麼以及遇到什麼問題，而主持會議的 scrum master 在會議上要知道大家進度，並且幫忙解決問題或是找到可以解決問題的人。
3. 敏捷只是一個精神，不是素描本拿來造抄
很多人開始敏捷一定從他的推廣者傑夫．薩瑟蘭的《Scrum：用一半的時間做兩倍的事》那本書開始讀起，讀完開始覺得人生好光明。但跟你打賭能夠真的跑起來得 10% 不到。
把大的東西拆小，小到可以可開發可測試可發佈。聽起來很容易，真的做起來工程師說不能這樣拆，設計師說又想改一些細節、測試跟你說沒有及時的 data 讓他測試怎麼辦…等等。如果你為了要達成「為了跑 scrum 而先去做把所有內外在環境設定好」的想法，不到一個月就會放棄。
先做再去優化吧！
把敏捷的精神不只投入到專案，也投入到你正在實行的敏捷。所以說每個 Sprint 結束的回顧會議是非常重要的。
敏捷開發不只是專案管理法，而是整個組織的變革！拆解 7 大變革要素
所以敏捷不好嗎？
好，以實行到整個企業的話，前置作業很多，但至少要做到大家（從老闆到各個團隊的團員，甚至到跨團隊成員）都要有敏捷的知識（很重要），大家瞭解最簡可行產品 MVP（minimum viable product），有自動化測試（可以慢慢規劃），團員有顆開放適應改變的心…等等
。
我的心得是在一個產品的發布流程來說，其實有些是適合傳統瀑布的開發方法，比如穩定需求非常大的工業領域，並非一位的追求敏捷開發適應到所有的產業；但團隊內部每日工作是可以跑敏捷方法，小至個人的人生規劃。
資料來源：https://www.managertoday.com.tw/articles/view/62640