分類
Project Management

人不能管理,只能領導

在我剛當上主管時,我非常迷戀管理,我管理團隊、管理人、管理資材、管理事、管理物,任何東西,我都管理,我要把人、事、物,在我的管理下,有條不紊的運行。


在我剛當上主管時,我非常迷戀管理,我管理團隊、管理人、管理資材、管理事、管理物,任何東西,我都管理,我要把人、事、物,在我的管理下,有條不紊的運行。

而在模糊中,我的心中也有領導一詞,我有時候也會用領導來取代管理,但我並沒有深究其中的差異。直到有一天,我讀到《僕人:修道院啟示錄》這本書時,書中的一句話宛如當頭棒喝,一棍子打醒我,我才發覺其中的巨大差異。

而在模糊中,我的心中也有領導一詞,我有時候也會用領導來取代管理,但我並沒有深究其中的差異。直到有一天,我讀到《僕人:修道院啟示錄》這本書時,書中的一句話宛如當頭棒喝,一棍子打醒我,我才發覺其中的巨大差異。

書中寫到:管理是管理事和物,人不能管理,人只能領導。

看到這句話,我豁然開朗。在我過去無所不管理的時代,我隱然覺得當我把對團隊、對人,改為領導時,似乎比較順理成章,而且是比較對的事。當我知道 「人不能管理,只能領導」 時,我開始徹底去分析其間的差異。

首先,事與物是死的,不論如何被人擺布,都不會有意見,所以可以任由人「管理」。而人的管理,不同的做法,就會產生不知的效果,端看人如何做而定,事與物是不會有所不同的。

可是人是不同的,人有心、有感覺,對不同的人、不同的做法,會有所回應,會有所互動,而其結果,也都會產生不同的效果。所以人不同於事和物,不會任由人來擺布、來管理,如果用錯了管理的方法,就會得到意想不到的效果。

一般而言,團隊與人對於上級主管的作為,最基本的有 3 種不同的回應: 消極的配合,正常的配合以及積極的配合 ,這 3 種回應方式會得到完全不同的結果。

如果團隊及部屬對主管的作為不認同,採取了消極的應付態度,那工作的成效是有限的,僅能得到勉強可接受的成果。

如果是正常的配合,成果會好一些,但也不會得到最佳的成果;惟有團隊積極的全力投入,配合主管的作為時,才會得到最佳成果,甚至會有意想不到的效果。

而人會用什麼方式來回應主管的作為呢?這完全要看主管是什麼人?主管用什麼態度來對待部屬?

如果主管是一個可被信任的人,主管的理念、價值觀被認同,那麼主管就是一個可以信賴的人。

而主管的作為如果正確,會用正確的方法去影響團隊成員,讓他們願意去做主管想做的事,而且是自動自發的去做,那就是積極的全力配合,會得到最佳成果。

有信任的主管,再用正確的方法去引導團隊做事,這就是「領導」,而一個有心、有感覺、有想法的人,就只能被領導。如果對人用管理,絕對不可能得到最佳的結果。

從此之後,我嘗試「領導」人,而「管理」事和物!

資料來源:https://www.managertoday.com.tw/columns/view/57806

分類
Project Management

工具技術組 PMBOK 第 6 版

項目管理工具和技術
專案管理工具和技術

PMBOK 第 6 版根據其目的對工具和技術進行分組。組名描述了需要做的事情的意圖。組中的工具和技術代表了實現意圖的不同方法。

專案管理工具和技術組

PMBOK 第 6 版有七組 132 種不同的專案管理工具。以下列表根據它們的組列舉了這些工具的細分。

  • 09 –數據收集工具
  • 27 – 數據分析技術
  • 15 –數據表示工具和技術
  • 02 – 決策技巧
  • 02 – 溝通技巧
  • 17 – 人際關係和團隊技能
  • 60 – 未分組的工具和技術

數據收集工具

數據收集工具和技術用於從各種來源收集數據和信息。以下列表列舉了九種數據收集工具。

  • 基準測試
  • 頭腦風暴
  • 檢查表
  • 清單
  • 專門小組
  • 採訪
  • 市場調查
  • 問題和調查
  • 統計抽樣

數據分析技術

數據分析工具和技術用於組織、評估和評估數據和信息。有27種數據分析工具。以下段落列舉了重要的數據分析技術。

  • 質量成本
  • 成本效益分析
  • 決策樹分析
  • 掙值分析
  • 自製或外購分析
  • 過程分析
  • 回歸分析
  • 風險概率和影響評估
  • 根本原因分析
  • SWOT分析
  • 趨勢分析
  • 方差分析
  • 假設情景分析

另請閱讀:七種基本質量工具 PMP 考試指南

數據表示工具和技術

數據表示工具和技術以可視化格式表示數據和信息。有 15 種數據表示工具。以下列表列舉了一些重要的數據表示工具。

  • 親和圖
  • 因果圖
  • 控製圖
  • 流程圖
  • 直方圖
  • 思維導圖
  • 概率和影響矩陣
  • 散點圖
  • 利益相關者參與評估矩陣
  • 利益相關者映射/代表。

另請閱讀: 質量控制數據表示工具

決策技巧

決策技術用於從不同的備選方案中選擇行動方案。以下是兩種決策技術。

  • 多準則決策分析
  • 表決

溝通技巧

溝通技巧是用於在不同專案利益相關者之間傳遞信息的工具。以下是兩種溝通技巧。

  • 反饋
  • 演示文稿

人際關係和團隊技能

人際關係和團隊技能包括用於領導專案團隊的 17 種不同技術。以下列表列出了一些重要的人際交往能力。

  • 積極傾聽
  • 衝突管理
  • 文化意識
  • 做決定
  • 情商
  • 便利化
  • 影響
  • 領導
  • 動機
  • 談判
  • 名義組技術
  • 政治意識

未分組的工具和技術

該組包含 60 種不同工具的詳盡列表。以下列表描述了該類別中一些最重要的專案管理技術。

結論

總而言之,PMBOK 第 6 版中描述的 132 個專案管理工具是可用於成功交付專案的良好實踐。PMBOK 中的附錄 X6 將所有 132 種工具與其流程和相應的知識領域進行了映射。有關這些技術的完整列表,請參閱專案管理知識體系,第 6 版®。

資料來源:https://milestonetask.com/tools-techniques/#.YPdiThMzbMJ

分類
Project Management

工具技術組 PMBOK 第 6 版(Tools Techniques Group PMBOK 6th Edition)

PMBOK 第 6 版根據其目的對工具和技術進行分組。組名描述了需要做的事情的意圖。組中的工具和技術代表了實現意圖的不同方法。

項目管理工具和技術組

PMBOK 第 6 版有七組 132 種不同的項目管理工具。以下列表根據它們的組列舉了這些工具的細分。

  • 09 –數據收集工具
  • 27 – 數據分析技術
  • 15 –數據表示工具和技術
  • 02 – 決策技巧
  • 02 – 溝通技巧
  • 17 – 人際關係和團隊技能
  • 60 – 未分組的工具和技術

數據收集工具

數據收集工具和技術用於從各種來源收集數據和信息。以下列表列舉了九種數據收集工具。

  • 基準測試
  • 頭腦風暴
  • 檢查表
  • 清單
  • 專門小組
  • 採訪
  • 市場調查
  • 問題和調查
  • 統計抽樣

數據分析技術

數據分析工具和技術用於組織、評估和評估數據和信息。有27種數據分析工具。以下段落列舉了重要的數據分析技術。

  • 質量成本
  • 成本效益分析
  • 決策樹分析
  • 掙值分析
  • 自製或外購分析
  • 過程分析
  • 回歸分析
  • 風險概率和影響評估
  • 根本原因分析
  • SWOT分析
  • 趨勢分析
  • 方差分析
  • 假設情景分析

另請閱讀:七種基本質量工具 PMP 考試指南

數據表示工具和技術

數據表示工具和技術以可視化格式表示數據和信息。有 15 種數據表示工具。以下列表列舉了一些重要的數據表示工具。

  • 親和圖
  • 因果圖
  • 控製圖
  • 流程圖
  • 直方圖
  • 思維導圖
  • 概率和影響矩陣
  • 散點圖
  • 利益相關者參與評估矩陣
  • 利益相關者映射/代表。

另請閱讀: 質量控制數據表示工具

決策技巧

決策技術用於從不同的備選方案中選擇行動方案。以下是兩種決策技術。

  • 多準則決策分析
  • 表決

溝通技巧

溝通技巧是用於在不同項目利益相關者之間傳遞信息的工具。以下是兩種溝通技巧。

  • 反饋
  • 演示文稿

人際關係和團隊技能

人際關係和團隊技能包括用於領導項目團隊的 17 種不同技術。以下列表列出了一些重要的人際交往能力。

  • 積極傾聽
  • 衝突管理
  • 文化意識
  • 做決定
  • 情商
  • 便利化
  • 影響
  • 領導
  • 動機
  • 談判
  • 名義組技術
  • 政治意識

未分組的工具和技術

該組包含 60 種不同工具的詳盡列表。以下列表描述了該類別中一些最重要的項目管理技術。

資料來源:https://milestonetask.com/tools-techniques/#.YNlAGRMzbMI

分類
Project Management

專案管理基本功

戰略

組織戰略通常包括一系列旨在實現長期目標和實現願景和使命的舉措。

戰略投資組合

一個專案可能在三種情況下進行管理:作為一個獨立的專案(投資組合或計劃外),一個內部程序,或內組合。(PMBOK 6th)

商業案例

  • 一個商業案例評估舉措替代的可行性,成本和效益方面。
  • 證明計劃合理的已批准業務案例會將其轉變為由專案發起人讚助並由專案經理管理的專案。

專案生命週期

專案是為創造獨特的產品、服務或成果而進行的臨時努力。

專案生命週期是專案從開始到完成所經歷的一系列階段。這些階段可以是連續的、迭代的或重疊的。專案的生命週期可以是預測性或適應性。

資料來源:PMBOK 6th

開發生命週期

在專案生命週期內,通常有一個或多個與產品、服務或成果的開發相關的階段。這些被稱為開發生命週期。開發生命週期可以是預測的、迭代的、增量的、自適應的或混合模型。

資料來源:PMBOK 6th

敏捷思維

敏捷是一種思維模式,它專注於通過一系列預定義的原則和經過驗證的實踐來頻繁地創造和交付價值。

管理

專案管理

專案管理是將知識、技能、工具和技術應用於專案活動以滿足專案要求。

專案管理使組織能夠有效和高效地執行專案。

資料來源:PMBOK 6th

原始出處: Project Management 101

分類
CISM CISSP Project Management

責任分配矩陣

責任分配矩陣[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

分類
Project Management

Agile 跟 Scrum 差在哪?導入敏捷,開發就會變快?敏捷式管理的常見誤解

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