Discussing Agile Management Practices

敏捷式(Agile)這個概念，其實源自於軟體工程。因為一個軟體在實做出來之前總是有很大的想像空間。如果軟體開發的結果不符合客戶或市場需求，那麼從前面的系統分析、系統設計，到程式撰寫、測試等等所花費的時間，最後可能又會重工，所以才會發展出敏捷式開發的做法。

了解敏捷式開發之前，我們先很快的來回憶一下常見的專案管理方法，也就是所謂的瀑布式(Waterfall)專案是怎麼管的。如果各位對孟華的專案管理協作平台ezteamwork很熟悉的話，首先會聯想到系統呈現的甘特圖。整個瀑布式專案的概念，就是希望盡可能、盡早地把專案計畫時程(Scheduling)排出來，而且希望專案計畫越精準越好，因為我們要依此時程計畫做成專案的Baseline基準，將來在執行這個專案的時候，我們要根據這個基準時程，來衡量專案的執行是否符合基準? 是超前或是落後? 也就是說在一個瀑布式專案裡面，它的源起都來自一個理想的計畫時程，而且計畫愈詳細越好，而我們最常使用的工具，就是大家非常熟悉的WBS (工作分解結構) 及甘特圖，所以WBS還有甘特圖是瀑布式專案裡面最常用的工具。

敏捷式管理

回到敏捷式管理這個主題，在討論其作法前，首先必須先談一下敏捷的宣言，敏捷的宣言其實有四個重點 :

  1. 互動大於流程
  2. Working software，也是就是可以正常運作的軟體，比寫一大堆文件來得更重要
  3. 跟客戶的協同合作會重於合約跟協商
  4. 我們要能夠回應變化，而不是一成不變的照計畫來做

上面第二個重點，是指開發出能正常運作的軟體，比花時間製作詳盡的文件來得更重要。如前面所提到，敏捷的概念源自於軟體工程，早期常常花了很多時間進行系統分析、設計，做了Prototype，而等到整個軟體開發出來之後才發現並不是符合客戶的要求。因此，第二個重點是強調，與其一開始花很多時間寫文件，最後把文件改掉重寫，還不如盡快把這個軟體雛形先做出來和客戶溝通討論來得更重要，因為我們知道在開發的過程，需求會不斷的修改、變化，所以才會有第四個宣言，也就是我們要回應變化，而不是像在一般傳統專案管理裡面，要透過繁雜的計畫變更程序才能回應變化，因為這樣的流程反而是沒有效率的。

Agile/Scrum/Adaptive Methodology

一個敏捷式專案要怎麼管？敏捷式的管理方法有很多種，最常被多數人採用的方法，就是建立一個產品的待辦清單，也就是我們常聽到的 Product Backlog。Product Backlog通常會用User Story的方式來呈現。那接下來，我們會把專案裡的Product Backlog透過建立一個或多個迭代去執行，當然這個Product Backlog裡面的待辦清單是需要經過排序的，通常我們會把最優先、最必要的待辦清單放到第一個迭代裡面去，從每一個迭代裡面去做一個增量式的進展，而每一個迭代就會有其待辦的產出交付。正如前面的敏捷宣言中提到，可用的產品比文件更重要，因此每一個迭代的交付就要透過產品使用者來做驗證，也就是為何我們需要透過跟客戶或使用者的密切互動，來驗證產品、得到回饋，把得到的產品回饋投入下一個迭代進行持續改善。一個敏捷式的專案是以這樣的概念來進行，而不是花很長一段時間規劃設計、經過很幾個階段後才做出一個大的交付。

正如前面的敏捷宣言中提到，可用的產品比文件更重要，因此每一個迭代的交付就要透過產品使用者來做驗證，也就是為何我們需要透過跟客戶或使用者的密切互動，來驗證產品、得到回饋，把得到的產品回饋投入下一個迭代進行持續改善

敏捷和迭代

以手機APP的開發為例子，大家是否有注意到APP經常在改版，或許有人會想：為什麼APP開發者不一次做好，而是隔一段時間就會發布一些新功能，或是一些新修正呢? 其實現在市面上多數的APP開發都是使用敏捷式的概念來發展，我們認為的為什麼不一次做好、做完整的這個概念，是一個永遠不存在的理想，所以還不如趕快做出讓使用者可以看得到、可以使用的功能，然後以蒐集使用者的回饋來持續改善，這樣的作法比傳統的作法來得更實際有效。

更進一步探討，敏捷式專案管理的方法是透過一個一個迭代去滾動執行。在迭代與迭代之間，以及每一個迭代的裡面，團隊人員之間、以及和客戶之間都需要做很密切的互動，因此敏捷式專案團隊需要一個可視化的工具，看板(Kanban 或 Board)是敏捷式管理中最常用來進行人員溝通互動的工具。

敏捷團隊

敏捷團隊到底包含哪些角色? 根據敏捷的精神，敏捷團隊是一個扁平化的組織，和一般傳統瀑布式專案團隊組成有所不同。首先，敏捷團隊會有一個產品負責人(Product Owner)，產品負責人是最了解這個專案或產品需求的人，其次是開發團隊(Developer)，最後是促進者 (Facilitator)，這個角色在不同的敏捷方法裡也可以叫做Scrum Master，接著來看這些不同角色做什麼事情。

前面所提到的產品待辦清單Product Backlog，主要是由Product Owner和Developer共同自訂，重點是共同自訂，而不僅是由Product Owner自己訂定。

這些Product Backlog裡面會包含不同的工作項目，而且也需要依其重要性、必要性做排序，優先排序的待辦清單Work Items則會先指派給開發團隊來執行。同時，每一個迭代的Work Items和產出，同樣要由產品負責人來做確認驗收。因此，產品負責人和開發團隊，是整個敏捷團隊裡面非常重要的兩個角色。
至於團隊的促進者或是Scrum Master，在孟華專案管理協作平台ezteamwork裡叫做迭代管理者(Iteration Master)。這個角色顧名思義，就是促進整個團隊運作的一個角色，這個角色的任務，可以說是為了確保在整個執行過程、及團隊溝通是非常有效率地向前推進，這和一般瀑布式專案管理中的專案經理角色有所不同。

迭代管理

其次，迭代的執行過程中會有一個Daily Standup Meeting，也就是每天的站立會議。這裡用Standup是強調團隊成員是站立著開會，因為希望每一個會議是小而精簡，大家站著希望比較能夠聚焦、專注，所以Daily Standup Meeting 通常是個十五分鐘左右的小會議，最長不會超過三十分鐘。

最後，我們來談一談在一個迭代裡面要怎麼樣來進行管理。首先，在每個迭代的開始會有一個迭代的規劃，又叫做Iteration Planning，主要是根據Product Backlog裡面的所有待辦清單 (或工作項目)去做排序，排序優先的就會進入該迭代要執行的工作項目。

在這個會議之中，團隊成員建立微承諾 (Micro Commitment)，也就是說，每一天會議中，團隊成員接收新的指派工作項目或既有項目執行上的回饋時，代表是一個短時間內可以承諾或完成執行的。

接著，當一個迭代結束時，會做這個迭代的Demo，也就是展示迭代的成果。最後，會做一個迭代的檢討(Review)和回顧(Retro)，檢討和回顧中所產生的工作項目，會再回饋到新的迭代，如此滾動需求、持續回饋改善。
至於團隊的促進者或是Scrum Master，在孟華ezteamwork平台裡叫做迭代管理者(Iteration Master)。這個角色顧名思義，就是促進整個團隊運作的一個角色，這個角色的任務，可以說是為了確保在整個執行過程及團隊溝通是非常有效率地向前推進，這和一般瀑布式專案管理中的專案經理角色有所不同。

歡迎分享文章至

近期文章

/by

Manage project issues well and turn crises into opportunities.

如大家所知的Project Management，就是要能夠準確的管理Scope（範圍）、Schedule（時間）、Budget（預算）、和Quality（品質）這四項要素，在可以接受的變動差異下，完成整個專案並交付預期的成果。而專案經理或專案主持人就是要在動態的環境下，利用種種手法盡力讓這件事發生。

所謂的「Project Management」其實可以用很科學的手段達成，而一個好的專案管理軟體工具能夠讓專案在進行的過程中透明的列出所有需要被執行的任務、各任務明確的完成時間，記錄整合專案所有的相關資訊並讓專案成員清楚的知道自己的工作分配。

在專案的時程管控和資源分配上多數的專案經理人會運用一些專案管理軟體工具像MS的Project、……來管理和記錄。但是針對專案進行的過程中，許許多多的會議討論和大大小小的議題（Issue）及交辦的追蹤及管理，大多數的人只用Excel和Email來做紀錄和追蹤。實際上，議題不只是發生在專案的過程，它們亦發生於各種企業營運活動中，例如問題、客訴、品質缺失、機台故障維修等都是常見的議題型態。所有的議題都是計畫外（不預期）的事件，我們都知道風險管理強調的就是管理不預期的事件，以避免負面風險的發生，或是在風險事件發生前採取適宜的行動，將企業的風險暴露性降至最低甚至把風險轉變為商機。通常專案會搞到失火，或是時間不夠用，問題往往出在整個專案進行過程中工作之間的「不透明」，以及問題管理的不及時或不確實。

Issue Tracking總是佔據專案經理很多的時間，若是專案團隊具備好的Issue Management的能力，則專案成功的機率也較高。

使用Excel和Email做Issue Management有幾個潛在的問題：

一、進度不透明、溝通不即時，導致時程延誤

管理Issue List（Excel）的人經常需要花很多的時間找相關的人問進度，或是透過很多的Email來了解處理狀況再去更新在Issue List上。使用Email來來回回往往浪費了許多寶貴的時間，如果在Email的往來中有人因為出差或請假而無法即時回覆Email，整件事的進展就又延緩下來了，所以這樣的工作模式無法即時的反應工作事項的執行狀態，而造成專案或企業工作進度不透明、不明確，參與人員需要花很多的時間在溝通上，因此導致專案時程與進度延誤的風險。

二、容易被忽略、造成專案資源配置風險

在一個專案或企業中多數時候可能同時有幾十個待處理事項（Issue），單用Email很難決定哪個待處理事項有急迫性需要優先被執行。同時在長串的Email往來中，議題是哪個人在負責的，也很容易被眾多的討論給模糊掉了。在專案的執行階段這會讓專案管理人員很難妥善的分配資源，而造成專案在資源配置不當的風險（不僅僅在人力，在工具、機具等等的使用調度上也有相同的風險）。

三、議題處理過程與經驗不易傳承

每個事件的處理過程及脈絡，都藏在眾多往來的Email中，一旦事件結束了，這些寶貴的經驗就深深埋沒在信箱中了。對於沒參與過這些事情的處理過程的人，至多只能從某些歷史報表得知曾發生過的事件及其結果，卻無從得知問題的處理過程，將來即使發生類似的問題，被交辦的負責人也不易參考前人的經驗，而必須重新摸索解決方案。

四、機密資料難以管控，有外洩的疑慮

如果是機密的事項討論，在Email中 CC者一大堆，如何分得清楚誰有權知道、誰無權知道這一串信裡面提到的執行事項？所以透過Email進行溝通有資訊洩密的疑慮，對企業和專案會有IP的考量和風險。
由這一連串的問題整理下來，我們可以清楚的發現Emai & Excel對Issue tracking & Management 其實很不夠用。本公司在輔導客戶建置專案管理系統時經常發現，Issue Tracking總是佔據專案經理很多的時間，若是專案團隊具備好的Issue Management的能力，則專案成功的機率也較高。因此客戶經常希望能有一個輔助Issue管理的工具，從定義-分析-檢討-留存來完整管理議題的生命週期，它能被用於幫助公司和專案團隊記錄、追蹤、管理工作中的議題，包括：AR追蹤、BUG測試、客訴管理、行銷活動、任務安排、需求管理……等。藉由這個工具來快速控管專案的road blocker，使其對專案的影響降至最低，而且這個管理工具能有效的記錄追蹤Issue的處理解決過程，讓他們公司能藉由歷史的經驗幫助他們企業更快速的解決議題，省下更多時間專注於核心工作。

Issue 管理工具的需求

迅速定義Issue的交辦人、完成期限、風險：

意即會議舉辦後即可馬上透過系統發出會議紀錄，並根據不同Issue指定交辦人選，根據會議決議進行結案功能。

自動追蹤提醒，輕鬆了解目前進度：

為避免同仁因工作繁多而遺漏某些工作項目，系統可於工作指派時自動發出Email通知負責人員。系統亦可根據Issue的應處理期限，設定提醒通知規則，以提醒相關負責人工作即將到期；若是工作已逾完成期限，亦可設定規則通知專案經理及其它管理人員。

分層嚴密管控資訊安全，保障企業智慧財產：

資料授權可分多種，並且根據不同授權等級提供資料閱讀及存取，企業僅需在一開始設定授權種類與等級，就可保障機密資料安全。

彈性化自訂欄位，量身打造專屬需求：

企業可自行分類問題，並自訂各種Issue類型及其對應之欄位（類型、來源、等級），依據類別新增需求欄位，彈性化創建符合企業需求的表格。

知識累積管理，關鍵字進階檢索：

可集中管理所有會議、Issue相關檔案，記錄完整的會議、Issue資訊，可勾稽Issue與Issue間的關聯性或Issue與會議間的關聯性，掌握問題處理脈絡，保留專案經驗和企業知識經驗資產。同時提供搜尋功能，可快速依照關鍵字、時間、內容或負責人搜尋所需會議、交辦或Issue。

如何做好專案議題管理? 專案議題常見管理工具效益比較

結論

依據上述的需求，孟華科技已經成功的將 Issue Management System整合到的專案管理資訊系統中(ePM專案管理系統)，並達到以下的效益：

一、清楚的反映Issue、提供彈性應變

讓客戶知道在他們的企業現在總共有多少Issue？有多少專案工作受到影響？投入多少人力在處理？處理進度為何？風險等級為何？在企業裡每一天都有無數的Issue在發生，若能在問題發生初期，就能及早因應，跟專案利害關係人充分溝通，就可能把危機轉變為商機！

二、問題化繁為簡、改進溝通流程，縮短工作時間

清楚的定義問題讓公司來辨識風險、追蹤交辦、了解問題的來源，確保問題在沒有嚴重影響目標前，就能夠有順序和即時的解決。工作中最耗費精神的往往是不著邊際的追蹤與交辦處理，透過系統應用，讓使用者不需要依靠記憶來處理交辦，企業可直接透過Issue Tracking平台指派工作，並透過自動追蹤功能，輕鬆掌握工作進度。

三、掌握問題處理的脈絡，有效落實知識管理

企業所面臨的狀況錯綜複雜，試圖解決一個問題的起因時，經常又會牽扯出另一個或多個有待解決的問題，透過Issue關聯的設定，精準地掌握問題的脈絡，達到企業決策目標，而且所有關於Issue交辦與結案的歷史記錄都會存放在知識庫中，提供未來企業參考，更大幅減少企業重覆作業及教育訓練的時間。

Issue Tracking總是佔據專案經理很多的時間，若是專案團隊具備好的Issue Management的能力，則專案成功的機率也較高。

歡迎分享文章至

近期文章

/by
專案管理資訊系統 PMIS

Project Management System: Common Applications and Implementation Key Points

專案管理資訊系統 (Project Management Information System，簡稱PMIS)，提供管理者、執行者與外部成員於同一平台，共享即時資訊以落實高效溝通，並確保專案團隊分工協作，共同實現專案目標。

PMIS系統 常見的應用

營建工程專案：整合時程與現金流管理

在所有類型的專案中，工程專案可說是對專案管理應用最成熟的領域，但工程專案最普遍的管理工具仍是排程軟體加上試算表。相較於其他類型的專案，工程專案的工期較長，而所需要的資金也遠高於一般專案，因此現金流(Cash Flow)管理就很重要了。專案的現金收入(Cash-in)主要來自跟業主請款，而現金支出(Cash-out)則是為支付下包廠商的款項，以上二者都跟工程進度有密切的關係，但單純依賴排程軟體與試算表，並無法即時掌握進度，也需要大量的資料處理才能計算金流預測。對動輒數億預算的工程專案而言，一個百分點的落差，就可能影響數百萬元的財務規劃，而我們在導入PMIS時，著重在即時的進度管理，並整合估驗請款之規劃與執行，以提供管理者最即時之財務資訊。

工程專案的另一個特性，是圖文及品質紀錄(抽查驗、檢試驗等)的數量非常龐大。工程專案的圖文可能高達數千甚至上萬份，再考慮進版歷程，則檔案數量更為可觀，如果又分散於為辦公室與工地現場的儲存裝置，無論是在檔案管理、版本管理、資料檢索與搜尋，都是管理者的一大挑戰。

我們協助導入的個案包含預算數千萬到上百億的工程案，圖文數量也有數萬份，透過將專案管理ｅ化，已大幅提高管理品質與決策的效率。

了解更多>>工程管理解決方案：整合管理進度、品質、圖說、財務的工程管理系統

研發專案：考量資源規劃與資訊安全

研發專案的時程延誤，除了技術問題需要突破之外，往往問題的源頭是一開始的規劃就沒有考量資源的可用性，導致基準時程僅是理想狀況下的排程結果，而在執行時才發現人力無法到位、設備無法取得，在這樣左支右绌的情況下，時程自然是一延再延了。我們在協助客戶建立研發管理流程時，經常協助客戶建立資源規劃模式，雖然這常牽涉到經驗法則，但隨著資料的累積做持續的修正，可使資源需求的資訊越趨透明與正確，由於PMIS背後的資料庫會包含所有專案的資源規劃，所以排程時亦將資源的規劃與實際使用情形納入，使所排時程更為合理。

對於研發過程的產出管理，則攸關商業機密與企業競爭力，在追求達成專案目標的同時，萬一心血結晶外流，甚至面臨訴訟與求償，豈不白費工夫？孟華在整體的解決方案設計中，包含了多層次的權限管控，從組織、專案、工作、文件、甚至欄位，皆可層層把關，並可搭配資安政策，來做有效的安全管控。

了解更多>>產品研發管理：整合研發時程、文件管控及知識管理

軟體工程：運用敏捷管理、重視品質管理

軟體開發專案的不確定性非常高，所以敏捷(Agile)開發的精神與方法更為適用。通常從計畫的角度，未必能預先進行很詳盡的規劃，而在執行面，則需能夠快速彈性調整。雖然敏捷開發的概念，是根據產出物預計提供的價值，來決定下一迭代的工作優先次序，但目前多數業主尚無法完全接受這樣的作業方式，所以我們也推薦採取混合(Hybrid)的做法：在一開始規劃時，初步界定高階需求與範疇，並從時程管理的角度，定義對應的里程碑(Milestone)，例如本月份完成A模組、下月份完成B子系統、三個月後進行系統整合等等，而每個里程碑的細部工作項目則以敏捷方式推進；為了確保里程碑的達成，品質管理相當重要，我們結合了軟體測試的方法論，並透過PMIS把里程碑、時程、品質等進行整合管理。

通常一個軟體專案需要運用許多不同的工具，例如架構管理(Configuration Management)、軟體塑模(Modeling)、整合開發環境IDE、測試工具、工時管理等，但大部分軟體工程所使用的工具，是從軟體工程師的角度切入，而許多軟體專案的利害關係人，例如軟體使用者與高階管理者，則未必是軟體專業人士。我們在實際導入經驗中，會建議不同的使用者適當搭配不同的軟體開發工具與PMIS，並使PMIS成為所有利害關係人的共同管理工具。

了解更多>>ePM全方位專案管理工具

歡迎分享文章至

近期文章

/by

Key Factors for Successful Implementation of PMIS

導入PMIS，代表著一場企業變革轉型之路即將展開，它不僅將改變許多作業習慣，更意味著流程與制度的調整，甚至將衝擊原有的企業文化。欲有效完成這場變革，並使之成為企業轉型成功的關鍵，有三種人扮演著極重要的角色，分別是：
1. 企業高階主管
2. 主要的系統使用者, 包括專案經理與專案成員
3. 協助導入之顧問

首先來看企業高階主管所扮演的角色，他通常是這個導入案的贊助者(sponsor)，也是這場企業變革的推手。

我們常說高階主管的支持很重要，但高階主管要如何來展現他的支持？

第一，在導入開始的啟動(kick-off)會議，高階主管是否展示對這個導入專案的決心？是否明確宣示未來PMIS在企業營運的重要性？若高階主管未出席啟動會議，而交由評估單位或使用單位的主管來發言，甚至連單位主管都未現身，可以想見對參與導入的人員而言，這就只會是一項工作(assignment)，而不是一項必達的使命(mission)了。

第二，在導入過程，高階主管的參與極其重要，包含導入過程的掌握以及上線驗收的投入，我們通常會安排使用者在完成教育訓練的一段時間後，由他們直接對高階主管做成果展示，這時就是高階主管檢視初步成效的最好時機，也可讓使用者們，有在短時間學習、熟悉系統操作的動力。

第三，系統上線後，高階主管本身的習慣也要改變，他不應該再沿用舊的管理思維與模式，還是依賴專案經理做出漂亮的專案報告，而是讓系統說話；這不代表從此專案經理不需做專案報告，或是誤以為PMIS是一個把專案報告自動化的工具，而是報告中的所有數據，都應以專案管理系統為本，專案經理應對各項數據提出詮釋與說明，而所有人自然漸漸會養成使用PMIS的習慣。

“高階主管本身的習慣也要改變，他不應該再沿用舊的管理思維與模式．．．而是讓系統說話”

Free Consultation

建立專案團隊對PMIS的正確認知

專案經理及專案成員將是系統的主要使用者，但在推動PMIS的過程中，卻發現往往也是阻力最大的一群，這通常是因為以下幾個不必要的擔心所造成的排斥：

第一，擔心增加自己的工作負擔；
第二，資訊一旦太過透明，擔心個人自由就降低；
第三，一旦建立起ｅ化的工作環境與資料庫，是否個人的經驗就得公開，而擔心自己在公司的重要性將漸漸失去？

為什麼說這些是不必要的擔心呢？首先大家應認知到，PMIS只是工具，它的價值在於使用的人，而不是工具本身。工具取代不了人的智慧，卻能幫助提高效率，能善用工具的人，可以把時間花在更有價值的智慧型工作上，而不是在繁瑣的作業層次；尤其現在都是打團隊組織戰，透過即時透明的資訊分享，團隊協同的效率更佳，個人績效亦得以彰顯，否則若每次的專案會議都只是行禮如儀，甚至人人自我防禦，這都不是組織發展所樂見的，對個人成長也是一點幫助都沒有。所以建立對PMIS正確的認知，是導入案中非常重要的關鍵。

“工具取代不了人的智慧，卻能幫助提高效率，能善用工具的人，可以把時間花在更有價值的智慧型工作上”

顧問引導與推動

而顧問通常是一個導入案的靈魂人物，前述高階主管、專案經理、專案成員的思維轉變，也都依賴顧問的引導。專業的顧問是從外來者的角度，將其多年的輔導經驗 ，協助企業突破現有作法的盲點，因應產業轉變和企業發展目標，建立或調整相對應的制度與流程，並透過ｅ化工具來加以落實。孟華的顧問訓練上，要求大家不僅是個好的傾聽者，更是好的建言者，我們的工作並不是幫客戶把office文書作業轉變為資料庫平台作業，而是協助客戶改變專案管理作法、以提升專案管理能力。

“我們的工作是協助客戶改變專案管理作法、以提升專案管理能力”

People, People, and People!

「人對了，事就成了」這句話經常反映在一個專案的執行上；而PMIS的導入專案，又何嘗不是如此? 要成功導入PMIS，只有一個關鍵，就是「人」：有了高階主管的支持、專案團隊的認同、再加上顧問的從旁協助，使PMIS成為工作環境的一部份，導入PMIS自然就成功了。

延伸閱讀：專案管理資訊系統 PMIS

歡迎分享文章至

近期文章

/by