開會對組織來說, 是必要之惡. 不開會, 有許多事就不易溝通協調, 但是開會真的是很花費時間及人力成本的執行方式. 所以要如何有效的縮短開會時間及提升會議效率, 就是一門學問.
會議的型式有些區分, 基本上可以分成 2 大類. 第一種是 資訊型會議, 以訊息傳達為主, 例如定期的專案會議要檢視成員進度及佈達專案重點事項. 第二種是 決策型會議 , 目的是為了針對特定事件, 決定處理的方式. 要有效的加速會議的進行, 可以參考以下的方式
會議可以分成 4 個階段
1. 規劃會議
2. 會前準備
3. 進行會議
4. 會後跟催與執行
資訊型會議要考量的訊息的傳達
在規劃會議的階段就應確認參與的人員. 越多人參與的會, 時間就越不容易控制, 且溝通訊息的效率就會變低, 所以在規劃階段就要避免將不必要的人員也邀請參加會議.
會前可要求與會的人員, 先將要報告的事項提交會議記錄人員, 一則可以避免臨時遺漏報告事項, 再者也可以減輕記錄人員的負擔及誤解的可能. 那種在會議中的結論, 變成會議記錄缺東漏西, 甚至張冠李戴的問題, 就曾是令我頭痛的問題, 後來要求先提交報告事項, 這一點就改善非常多.
進行會議時最忌跑題, 有些人講話講著, 就會說到會議無關的主題去, 這時會議主持人應適時出面將話題拉回到主軸, 避免會議時間被無端拉長.
會後的跟催及執行, 最好是要有 工作追蹤列表, 尤其是對定期會議, 可以透過追蹤列表檢視各工作項的執行狀況, 可避免工作指派後卻被遺漏的問題.
決策型會議的目標通常就是要下決定
在規劃階段就要先確定, 解決問題的資源是否分散在幾個人手中, 會議結果的貫徹是否需要幾個人的承諾, 是否有需要調停的衝突觀點. 這些與要如何進行會議的形式有關, 要用腦力激盪法進行討論, 還是要用簡報法後進行投票, 或是用分類法進行分析. 要先規劃一個有效的會議模式及與會者, 這樣才能形成有效的決策.
會議準備最主要是讓與會者能明白會議主題, 並準備好相關的討論事項, 那種臨時拉人來開會要決定什麼事的會議, 通常都是說了半天什麼決定也做不了.
進行會議就看會議的型式, 不過一個好的會議主持人及記錄是不可或缺的.
會後執行一樣需要有指派人員進行跟催, 不然很容易發生大家討論了半天, 最後做出的決定確沒人去做, 這樣等於浪費了開會的時間和成本.
2010年4月6日 星期二
軟體專案的生命週期
一個軟體專案的生命週期, 大致如下
需求發展 --> 系統分析 --> 規格設計 --> 程式開發 --> 整合測試 --> 版本發行 --> 需求發展 --> 系統分析 --> 規格設計 --> 程式開發--> .... (如此循環, 直到產品不再銷售)
每一個階段, 都能用 一筆帶過 的方式處理, 也能用 吹毛求疪 的態度追求完美. 但是做事的方法, 通常就會影響到最後產出的品質. 但太過追求完美, 也有可能需要秏費大量的時間和人力, 甚至導致專案的失敗. 這時就要考驗專案經理人的拿捏.
大多數的軟體專案經理對 程式開發 和 整合測試 會比較注意, 因為這裏的工作產出, 程式碼 和測試結果 比較容看得到效益. 需求發展到規格設計這一段, 通常都是比較弱的地方. 但輕頭重尾的結果, 很容易讓一個軟體 "短命", 容易產生 "不符合客戶需要" 和 "後續維護不易" 的問題.
CMMI 的階段式模型, 則提供了一個可執行的規範, 對軟體公司而言, 沒有導入 CMMI 還是可以開發出好的軟體, 例如 Microsoft, Oracle 等巨型的軟體公司, 並無導入 CMMI, 因為當他們成功的開發出符合大多數人需求的軟體時, 根本就還沒有 CMMI 這種東西.
那 CMMI 有什麼用呢? 基本上可以將 CMMI 想像成是一套流程規範, 讓你生產出來的東西具有一定的品質. CMMI 不能告訴你怎麼做出 MS Office 或 Linux Kernel 這樣成功的產品, 但可以幫助你在軟體專案的進行中, 維持一定的水準. 透過制度避免開發中的風險. 這對一個已經有利基產品, 但苦於品質不穩定, 時程延遲等問題的研發團隊, 是一劑有效的藥方.
在軟體專案中, 透過 CMMI 各階段的要求, 就可以比較容易確保在各軟體專案生命週期的各個階段都有投入足夠的關心, 開發出一個品質與維護性都在水準以上的專案.
需求發展 --> 系統分析 --> 規格設計 --> 程式開發 --> 整合測試 --> 版本發行 --> 需求發展 --> 系統分析 --> 規格設計 --> 程式開發--> .... (如此循環, 直到產品不再銷售)
每一個階段, 都能用 一筆帶過 的方式處理, 也能用 吹毛求疪 的態度追求完美. 但是做事的方法, 通常就會影響到最後產出的品質. 但太過追求完美, 也有可能需要秏費大量的時間和人力, 甚至導致專案的失敗. 這時就要考驗專案經理人的拿捏.
大多數的軟體專案經理對 程式開發 和 整合測試 會比較注意, 因為這裏的工作產出, 程式碼 和測試結果 比較容看得到效益. 需求發展到規格設計這一段, 通常都是比較弱的地方. 但輕頭重尾的結果, 很容易讓一個軟體 "短命", 容易產生 "不符合客戶需要" 和 "後續維護不易" 的問題.
CMMI 的階段式模型, 則提供了一個可執行的規範, 對軟體公司而言, 沒有導入 CMMI 還是可以開發出好的軟體, 例如 Microsoft, Oracle 等巨型的軟體公司, 並無導入 CMMI, 因為當他們成功的開發出符合大多數人需求的軟體時, 根本就還沒有 CMMI 這種東西.
那 CMMI 有什麼用呢? 基本上可以將 CMMI 想像成是一套流程規範, 讓你生產出來的東西具有一定的品質. CMMI 不能告訴你怎麼做出 MS Office 或 Linux Kernel 這樣成功的產品, 但可以幫助你在軟體專案的進行中, 維持一定的水準. 透過制度避免開發中的風險. 這對一個已經有利基產品, 但苦於品質不穩定, 時程延遲等問題的研發團隊, 是一劑有效的藥方.
在軟體專案中, 透過 CMMI 各階段的要求, 就可以比較容易確保在各軟體專案生命週期的各個階段都有投入足夠的關心, 開發出一個品質與維護性都在水準以上的專案.
2010年3月29日 星期一
管理與領導
當主管從來不是一件容易的事. 說不容易最主要是不像 工程 , 可以有很明確的規則和評量方法, 知道是否有把事情做好. 擔任主管並不一定是技術能力最好的人, 但通常需要溝通能力較好的人. 因為主管, 最主要的工作應是管理, 讓人把事情做好, 擔任 分配資源, 指派工作, 溝通協調, 監督查核, 評估績效 等工作.
只要是和 人 有直接相關的事, 就會面臨不同人反應不同的問題. 在前一個團隊可行的方法, 換到另一團隊可能就會變得滯礙難行. 想用同一套方法就不出問題, 除非是管理的團隊成員一直不變才有可能. 不過在現在人員流動的狀況下, 這種假設太過理想化.
要如何做管理與領導呢? 摘要幾個重點
1. 分享願景(Vision). 雖然有些人覺得這種東西都是在打高空, 沒什麼實際價值. 不過在工作這麼多年後, 覺得有一個願景還是很重要的, 心有多大, 天地就有多大. 有時與員工聊聊對未來的期許, 一定比只看到眼前工作更能激發熱情.
2. 明確目標. 在指派工作時要給一個明確的預期結果, 包含時程和執行狀況. 這樣對負責那一項工作的人來說, 可以避免走很多彎路, 減少不必要的猜測, 可以降低額外的成本.
3. 溝通與查核. 把工作交派下去後, 最忌從此不聞不問, 就預期事情一定會做好. 除非是那種很制式化的日常工作, 大多的工作都會有一些需要合作、溝通、排程、做決定. 擔任主管除了交派工作外, 還應定期(或不定期)和相關人員溝通一下執行的方式及狀況. 雖然目標已經決定, 但達成的方式後少只有一種, 如何確保用好的方法完成, 需要團體的努力和必要的支持. 另外為了避免私人的因素影響整體, 所以主管與員工的溝溝也不限定是在工作方面, 有時聊聊工作以外的事, 有助於團體的磨合.
4. 適時回應成果. 一件工作完成後, 需要給相關的人員一些回饋, 可能是一句謝謝, 可能是一頓晚餐. 要儘量避免不聞不問. 以前也遇到過被交辦十萬火急的事, 拼命加班弄出來後交給老闆, 給果老闆就只是放著也沒其他的動作. 這種狀況就會令人為自己的努力不值. 對員工的努力成果要給予肯定, 這樣才能讓人覺得自己的工作, 自己的努力是有價值的.
只要是和 人 有直接相關的事, 就會面臨不同人反應不同的問題. 在前一個團隊可行的方法, 換到另一團隊可能就會變得滯礙難行. 想用同一套方法就不出問題, 除非是管理的團隊成員一直不變才有可能. 不過在現在人員流動的狀況下, 這種假設太過理想化.
要如何做管理與領導呢? 摘要幾個重點
1. 分享願景(Vision). 雖然有些人覺得這種東西都是在打高空, 沒什麼實際價值. 不過在工作這麼多年後, 覺得有一個願景還是很重要的, 心有多大, 天地就有多大. 有時與員工聊聊對未來的期許, 一定比只看到眼前工作更能激發熱情.
2. 明確目標. 在指派工作時要給一個明確的預期結果, 包含時程和執行狀況. 這樣對負責那一項工作的人來說, 可以避免走很多彎路, 減少不必要的猜測, 可以降低額外的成本.
3. 溝通與查核. 把工作交派下去後, 最忌從此不聞不問, 就預期事情一定會做好. 除非是那種很制式化的日常工作, 大多的工作都會有一些需要合作、溝通、排程、做決定. 擔任主管除了交派工作外, 還應定期(或不定期)和相關人員溝通一下執行的方式及狀況. 雖然目標已經決定, 但達成的方式後少只有一種, 如何確保用好的方法完成, 需要團體的努力和必要的支持. 另外為了避免私人的因素影響整體, 所以主管與員工的溝溝也不限定是在工作方面, 有時聊聊工作以外的事, 有助於團體的磨合.
4. 適時回應成果. 一件工作完成後, 需要給相關的人員一些回饋, 可能是一句謝謝, 可能是一頓晚餐. 要儘量避免不聞不問. 以前也遇到過被交辦十萬火急的事, 拼命加班弄出來後交給老闆, 給果老闆就只是放著也沒其他的動作. 這種狀況就會令人為自己的努力不值. 對員工的努力成果要給予肯定, 這樣才能讓人覺得自己的工作, 自己的努力是有價值的.
2010年3月24日 星期三
需求發展與時程預估的方法 - Delphi Method
這裏的 Delphi 和寫程式用的 Delphi 是同一個字, 要講的卻不相同. Delphi Method 是指一種特殊的會議進行方式. 一般會議的進行, 講究的是充份的溝通與討論, 進而凝聚共識. 而 Delphi Method 用的是一種不尋常的溝通技巧.
Delphi Method 要求參與會議的人員, 應該都是 專家 . 針對會議主題, 所以參與的專家都使用匿名的方式發表意見, 彼此之間不互相討論。主席(或公正第三方)在收集到專家們的意見後進行統計及歸納, 再將結果回饋給與會的專家們, 請他們再次進行分析, 透過 2~4 次後的循環, 應可匯集出專家們大體一致的看法, 即為會議的結論.
這個方法很適合用在軟體開發中的需求發展及時程預估.
對軟體產品的設計, 很重要的一個環節是需求來源, 最終會設計出什麼樣的產品, 會和一開始的需求有很大的關係. 對需求很明確的項目, 沒什麼可以爭議的, 但對在提出需求時, 有時會太過模糊, 提出需求的人員, 可能自己也講不清楚要做成什麼樣子, 甚至會說 "等你做出來我再告訴你和我想的一不一樣.", 在這種狀況下就可以用 Delphi Method 進行分析.
另一個是時程的預估. 傳統的方式是使用 WBS 進行切割後, 再加總需要的時間. 可是有些工作不容易細分, 尤其是研發新技術這一類的項目. 這時就可以使用 Delphi Method, 借助專家的經驗與分析, 比較準確的得到預估值.
這個方法的好處是簡單, 只要有好的專案人選, 透過簡單的幾個回合就可以得到答案. 但麻煩也在這裏, 何找尋找專家? 這個方法若是讓不熟悉會議主題的人來參與, 只會天馬行空的回答, 或是單純附和別人的說法, 這樣就不容易得到一個好的答案了.
Delphi Method 要求參與會議的人員, 應該都是 專家 . 針對會議主題, 所以參與的專家都使用匿名的方式發表意見, 彼此之間不互相討論。主席(或公正第三方)在收集到專家們的意見後進行統計及歸納, 再將結果回饋給與會的專家們, 請他們再次進行分析, 透過 2~4 次後的循環, 應可匯集出專家們大體一致的看法, 即為會議的結論.
這個方法很適合用在軟體開發中的需求發展及時程預估.
對軟體產品的設計, 很重要的一個環節是需求來源, 最終會設計出什麼樣的產品, 會和一開始的需求有很大的關係. 對需求很明確的項目, 沒什麼可以爭議的, 但對在提出需求時, 有時會太過模糊, 提出需求的人員, 可能自己也講不清楚要做成什麼樣子, 甚至會說 "等你做出來我再告訴你和我想的一不一樣.", 在這種狀況下就可以用 Delphi Method 進行分析.
另一個是時程的預估. 傳統的方式是使用 WBS 進行切割後, 再加總需要的時間. 可是有些工作不容易細分, 尤其是研發新技術這一類的項目. 這時就可以使用 Delphi Method, 借助專家的經驗與分析, 比較準確的得到預估值.
這個方法的好處是簡單, 只要有好的專案人選, 透過簡單的幾個回合就可以得到答案. 但麻煩也在這裏, 何找尋找專家? 這個方法若是讓不熟悉會議主題的人來參與, 只會天馬行空的回答, 或是單純附和別人的說法, 這樣就不容易得到一個好的答案了.
2010年3月19日 星期五
CMMI - 軟體能力成熟度整合模型
CMMI 是美國國防部, 委託卡內基美隆大學 (Carnegie Mellon University) 的軟體工程學院 (Software Engineering Institute, SEI) 所進行的一項研究成果再衍生出來的一套標準. CMMI 本身並沒有訂義出明確的軟體開發流程, 而是依軟體工程的角度, 訂定出各種要求. 只符合要求, 並通過 主任評鑑員的認定, 就可以宣稱符合 CMMI.
SEI 在制定這套標準時, 目標是提供一個具有共通性, 可以支援整合不同專業領域的通用架構, 評鑑是否通過的方法也有性, 可用連續式自行選定目標, 針對不同流程領域進行評鑑, 也可按照階段式的各階段規定進行評鑑. 另外也區分 開發方(develop) 和 採購方(Acquisition) 訂定執行標準.
在台灣好像沒看到有那個單位是使用 連續式 進行評鑑, 幾乎都是以 階段式 為主. 階段式共分成 5 個等級, 其中第一級不用評鑑, 或者說沒做過評鑑的通通都是第一級. 第二級到第五級都需要依規定進行評鑑, 而且每次的評鑑有效期只有 3 年, 時間到了必需重新評鑑才有效. 目前台灣通過的單位數也不多, 從 CMMI taiwan ( http://www.cmmi-taiwan.org.tw/ ) 公告來看, 到 2010-03-19通過的單位數如下
CMMI Level2 (78)
CMMI Level3 (46)
CMMI Level4 (3)
CMMI Level5 (3)
因為那個網站的算法是有拿到證書就算, 所以第二級、第三級都有進行評鑑, 就會被重覆計算到.
簡單列一下階段式各流程領域的要求, 想知到更進一步訊息可參考 CMMI taiwan 網站.
CMMI Maturity Level 2
- 建構管理(CM, Configuration Management)建立並維護藉由建構識別、建構管制、建構狀態記錄及建構稽核，使工作產品具完整性。
- 度量與分析(MA, Measurement and Analysis)發展並維護支援管理資訊所需的度量能力。
- 專案監控(PMC, Project Monitoring and Control)提供對專案進度的瞭解，使得當專案績效明顯偏離原先計劃時，能採取適當的矯正措施。
- 專案規劃(PP, Project Planning)建立並維護定義專案活動的計畫。
- 流程與產品品質保證(PPQA, Process and Product Quality Assurance)提供員工和管理階層，對於流程與相關工作產品客觀的觀察
- 需求管理(REQM, Requirements Management)管理專案產品與產品組件之需求，並且界定專案計畫、工作產品與需求這兩者之間，是否有不一致的情形。
- 供應商協議管理(SAM, Supplier Agreement Management)管理和專案有正式協議的供應商之產品與服務的採購。
CMMI Maturity Level 3
- 決策分析與解決方案(DAR, Decision Analysis and Resolut)於作決策時，使用結構化的方法，依照已建立的準則，評估各備選方案。
- 整合的專案管理(IPM, Integrated Project Management)，根據調適組織標準流程得的整合的已調適流程，建立並管理專案和其關鍵人員。它也涵蓋建立專案共同願景及整合團隊結構，以完成專案目標。
- 組織流程定義(OPD, Organizational Process Definition)建立並維護可使用的組織流程資產。
- 組織流程專注(OPF, Organizational Process Focus)建立並維護組織流程與流程資產的瞭解，並且界定、規劃及執行組織流程改善活動。
- 組織訓練(OT, Organizational Training)發展人員的技巧與知識，使他們能有效地執行其角色。
- 產品整合(PI, Product Integration)將產品組件組合成產品，確保產品已經整合、運作正常，並交付客戶。
- 需求發展(RD, Requirements Development produces)提供客戶、產品與產品組件的需求與分析，這些是發展與瞭解所需的。
- 風險管理(RSKM, Risk Management)界定風險發生前的潛在問題，使在達成目標之前的生命週期期間，在有需要時，能規劃風險處理活動，以降低不利的衝擊。
- 技術解決方案(TS, Technical Solution)用以發展、設計與實作對於需求的解決方案。解決方案、設計與實作，適當地涵蓋產品、產品組件以及產品相關單一或組合的流程。
- 驗證(VER, Verification)確保工作產品符合特定的需求。
- 確認(VAL, Validation)證明產品或產品組件，於特定的環境下，確實能發揮特定的功能。
CMMI Maturity Level 4
- 組織流程績效(OPP, Organizational Process Performance)建立並維護組織標準流程績效的量化了解，並提供流程績效的資料、基準與模式，以數量化管理組織的專案。
- 數量化專案管理(QPM, Quantitative Project Management)數量化管理專案的已調適流程，以達成該專案所建立的品質與流程的績效目標。
CMMI Maturity Level 5
- 原因分析與解決方案(CAR, Causal Analysis and Resolution)界定缺失的原因與其他的問題，並採取預防措施，避免這些缺失在未來再發生。
- 組織創新與推展(OID, Organizational Innovation and Deployment)選擇與推展漸進的與創新的改善活動，可度量地改善組織的流程與技術。這種改善，支援由組織經營目標所衍引的組織品質與流程績效目標。
SEI 在制定這套標準時, 目標是提供一個具有共通性, 可以支援整合不同專業領域的通用架構, 評鑑是否通過的方法也有性, 可用連續式自行選定目標, 針對不同流程領域進行評鑑, 也可按照階段式的各階段規定進行評鑑. 另外也區分 開發方(develop) 和 採購方(Acquisition) 訂定執行標準.
在台灣好像沒看到有那個單位是使用 連續式 進行評鑑, 幾乎都是以 階段式 為主. 階段式共分成 5 個等級, 其中第一級不用評鑑, 或者說沒做過評鑑的通通都是第一級. 第二級到第五級都需要依規定進行評鑑, 而且每次的評鑑有效期只有 3 年, 時間到了必需重新評鑑才有效. 目前台灣通過的單位數也不多, 從 CMMI taiwan ( http://www.cmmi-taiwan.org.tw/ ) 公告來看, 到 2010-03-19通過的單位數如下
CMMI Level2 (78)
CMMI Level3 (46)
CMMI Level4 (3)
CMMI Level5 (3)
因為那個網站的算法是有拿到證書就算, 所以第二級、第三級都有進行評鑑, 就會被重覆計算到.
簡單列一下階段式各流程領域的要求, 想知到更進一步訊息可參考 CMMI taiwan 網站.
CMMI Maturity Level 2
- 建構管理(CM, Configuration Management)建立並維護藉由建構識別、建構管制、建構狀態記錄及建構稽核，使工作產品具完整性。
- 度量與分析(MA, Measurement and Analysis)發展並維護支援管理資訊所需的度量能力。
- 專案監控(PMC, Project Monitoring and Control)提供對專案進度的瞭解，使得當專案績效明顯偏離原先計劃時，能採取適當的矯正措施。
- 專案規劃(PP, Project Planning)建立並維護定義專案活動的計畫。
- 流程與產品品質保證(PPQA, Process and Product Quality Assurance)提供員工和管理階層，對於流程與相關工作產品客觀的觀察
- 需求管理(REQM, Requirements Management)管理專案產品與產品組件之需求，並且界定專案計畫、工作產品與需求這兩者之間，是否有不一致的情形。
- 供應商協議管理(SAM, Supplier Agreement Management)管理和專案有正式協議的供應商之產品與服務的採購。
CMMI Maturity Level 3
- 決策分析與解決方案(DAR, Decision Analysis and Resolut)於作決策時，使用結構化的方法，依照已建立的準則，評估各備選方案。
- 整合的專案管理(IPM, Integrated Project Management)，根據調適組織標準流程得的整合的已調適流程，建立並管理專案和其關鍵人員。它也涵蓋建立專案共同願景及整合團隊結構，以完成專案目標。
- 組織流程定義(OPD, Organizational Process Definition)建立並維護可使用的組織流程資產。
- 組織流程專注(OPF, Organizational Process Focus)建立並維護組織流程與流程資產的瞭解，並且界定、規劃及執行組織流程改善活動。
- 組織訓練(OT, Organizational Training)發展人員的技巧與知識，使他們能有效地執行其角色。
- 產品整合(PI, Product Integration)將產品組件組合成產品，確保產品已經整合、運作正常，並交付客戶。
- 需求發展(RD, Requirements Development produces)提供客戶、產品與產品組件的需求與分析，這些是發展與瞭解所需的。
- 風險管理(RSKM, Risk Management)界定風險發生前的潛在問題，使在達成目標之前的生命週期期間，在有需要時，能規劃風險處理活動，以降低不利的衝擊。
- 技術解決方案(TS, Technical Solution)用以發展、設計與實作對於需求的解決方案。解決方案、設計與實作，適當地涵蓋產品、產品組件以及產品相關單一或組合的流程。
- 驗證(VER, Verification)確保工作產品符合特定的需求。
- 確認(VAL, Validation)證明產品或產品組件，於特定的環境下，確實能發揮特定的功能。
CMMI Maturity Level 4
- 組織流程績效(OPP, Organizational Process Performance)建立並維護組織標準流程績效的量化了解，並提供流程績效的資料、基準與模式，以數量化管理組織的專案。
- 數量化專案管理(QPM, Quantitative Project Management)數量化管理專案的已調適流程，以達成該專案所建立的品質與流程的績效目標。
CMMI Maturity Level 5
- 原因分析與解決方案(CAR, Causal Analysis and Resolution)界定缺失的原因與其他的問題，並採取預防措施，避免這些缺失在未來再發生。
- 組織創新與推展(OID, Organizational Innovation and Deployment)選擇與推展漸進的與創新的改善活動，可度量地改善組織的流程與技術。這種改善，支援由組織經營目標所衍引的組織品質與流程績效目標。
2010年3月16日 星期二
團隊合作
對使用者越來越簡單操作的電腦, 對設計的人來說就是越來越多的用心. 在軟體設計這個業待了10多年, 真的是時代不一樣的. 在10年前還有可能透過一個人的單打獨鬥模式做出一個能賣錢, 能合符合使用者需求的系統. 而現在取而代之的, 是透過團隊合作來開發系統.
在團隊中要如何協調個人能力的發揮和整體的協同運作, 真的是一門學問. 並不是將一堆人集合在一起工作, 就叫團隊. 已經看過很多運作不良的團隊, 或許個別人員的能力很強, 但因為協調問題搞得大家不愉快, 最後反而是將時間和資源都虛耗掉, 沒辦法達到專案的預期成果.
條列幾個自己認為重要的項目備忘, 也要提醒自己別犯相同的錯誤
- 流程的建立. 在專案中應該要建立那些表單, 執行那些事項, 什麼時候要出報告, 需求的判定和分析, 交付成果的驗證方式... 等, 這些在專案中必定會遇到的事情和作法, 都要在事先就建立好依循的流程, 讓專案成員在執行前, 就有概念要做那些事, 可以避免在指派工作時讓專案成員有措手不及, 或不知道下一步要做什麼的困擾.
- 人際溝通. 除了專案會議外, 專案經理也需要不定期的和成員溝通, 了解他們的狀況, 聽聽他們的意見, 並適時的給予鼓勵和回饋. 同時也要讓成員間有交流的機會, 儘量避免各做各的事. 非正式的交流, 像在茶水間碰到面時詢問一下個人的狀況, 或辦個團體聚餐, 都更能讓彼此更熟悉.
- 授權與分派. 在將工作指派出去的同時, 也要給予對應的權力, 不要事事橫插一手. 適時的關心進度與執行狀況是有必要的, 但也要能容忍犯錯. 以及容忍別人用不同的方法來完成事情. 另外要注意別老是將工作分派給看起來能力最好的人. 一來會造成資源排擠, 二來也是造成強者越強, 其他人缺乏鍛練的機會.
- 自省. 獨裁式的領導不適合我. 所以要自我檢視是否有聽取別人的意見, 言語是否會傷害到別人. 專案經理足夠的謙虛有助於團隊的認可. 不過也不是當 yesman, 分際要拿揘好.
在團隊中要如何協調個人能力的發揮和整體的協同運作, 真的是一門學問. 並不是將一堆人集合在一起工作, 就叫團隊. 已經看過很多運作不良的團隊, 或許個別人員的能力很強, 但因為協調問題搞得大家不愉快, 最後反而是將時間和資源都虛耗掉, 沒辦法達到專案的預期成果.
條列幾個自己認為重要的項目備忘, 也要提醒自己別犯相同的錯誤
- 流程的建立. 在專案中應該要建立那些表單, 執行那些事項, 什麼時候要出報告, 需求的判定和分析, 交付成果的驗證方式... 等, 這些在專案中必定會遇到的事情和作法, 都要在事先就建立好依循的流程, 讓專案成員在執行前, 就有概念要做那些事, 可以避免在指派工作時讓專案成員有措手不及, 或不知道下一步要做什麼的困擾.
- 人際溝通. 除了專案會議外, 專案經理也需要不定期的和成員溝通, 了解他們的狀況, 聽聽他們的意見, 並適時的給予鼓勵和回饋. 同時也要讓成員間有交流的機會, 儘量避免各做各的事. 非正式的交流, 像在茶水間碰到面時詢問一下個人的狀況, 或辦個團體聚餐, 都更能讓彼此更熟悉.
- 授權與分派. 在將工作指派出去的同時, 也要給予對應的權力, 不要事事橫插一手. 適時的關心進度與執行狀況是有必要的, 但也要能容忍犯錯. 以及容忍別人用不同的方法來完成事情. 另外要注意別老是將工作分派給看起來能力最好的人. 一來會造成資源排擠, 二來也是造成強者越強, 其他人缺乏鍛練的機會.
- 自省. 獨裁式的領導不適合我. 所以要自我檢視是否有聽取別人的意見, 言語是否會傷害到別人. 專案經理足夠的謙虛有助於團隊的認可. 不過也不是當 yesman, 分際要拿揘好.
2010年3月13日 星期六
部門主管與專案經理的差異
部門主管和專案經理, 都需要對所屬的人員、資源和工作進行指派與追蹤. 不過二者的型態還是有些差異.
部門主管所擁有的資源, 大致上不會有太大的變化, 人員隸屬於那一個部門, 雖然說也會有變動, 但很少單位會經常性的變更部門成員(當然那種離職率特高的例外也是有的), 算是公司的主要組成單位. 通常擔任部門主管, 也就是要每年幫員工打考績的那個人.
專案經理則是為了專案執行成存在, 專案會有一個明確的目標, 需要在指定的時程內完成某件事(所以才叫專案呀), 一般都是用任務小組的方式組成, 會從一個或多個部門內, 遴選出相關的成員並指派工作. 專案完成後一般就是解散, 或是視需要再重新組成小組.
在軟體開發這個領域, 基本上都是用專案的型式在工作. 每一套軟體就是一個專案, 設計出成品後進行後續維護也是一個專案, 產品銷售給客戶, 要幫客戶進行建置、佈署、教育訓練, 這又是一種不同的專案型態.
我待在資訊業已經10多年了, 在軟體開發專案的這部份, 每種角色都曾經擔任過, 當然現在比較多的比重是在擔任 部門主管 和 專案經理.
在部門主管的角色上, 比較多是日常工作, 像是工作指派, 文件表單的簽核. 對整體流程方面, 在提流程改善, 提升績效等預期執行方式往往會牽動到其他人員, 導致調整不易. 尤其是在部門人員已經被分派到多個專案中時, 更增加協調的困難.
專案經理在一開始就已經是從多個部門協調人員出來. 一旦最開始的人員和資源能確認後, 後續就比較不會受到干擾, 當然多個專案中共用資源也是會遇到關鍵資源發生排擠的狀況, 不過做資源撫平那又是另一門學問. 因為專案的生命週期較短, 也可實驗一些新的改善方法. 所以我個人是覺得專案經理的角色在執行面會容易些. 這個我個人的感覺, 在不同的單位或許會有不同的狀況.
前一陣子去上一門專案管理的課程, 微軟的專案管理講師主講, 當然內容有一部份是在介紹 MS 的 Project 系統在專案管理中的運用, 另外一部份則是在講專案管理的概念. 聽了之後讓我有衝動想去考 PMP , 買了一本 PMP專案管理認證指南在看, 有時間再把一些心得寫下來與大家分享.
--
部門主管所擁有的資源, 大致上不會有太大的變化, 人員隸屬於那一個部門, 雖然說也會有變動, 但很少單位會經常性的變更部門成員(當然那種離職率特高的例外也是有的), 算是公司的主要組成單位. 通常擔任部門主管, 也就是要每年幫員工打考績的那個人.
專案經理則是為了專案執行成存在, 專案會有一個明確的目標, 需要在指定的時程內完成某件事(所以才叫專案呀), 一般都是用任務小組的方式組成, 會從一個或多個部門內, 遴選出相關的成員並指派工作. 專案完成後一般就是解散, 或是視需要再重新組成小組.
在軟體開發這個領域, 基本上都是用專案的型式在工作. 每一套軟體就是一個專案, 設計出成品後進行後續維護也是一個專案, 產品銷售給客戶, 要幫客戶進行建置、佈署、教育訓練, 這又是一種不同的專案型態.
我待在資訊業已經10多年了, 在軟體開發專案的這部份, 每種角色都曾經擔任過, 當然現在比較多的比重是在擔任 部門主管 和 專案經理.
在部門主管的角色上, 比較多是日常工作, 像是工作指派, 文件表單的簽核. 對整體流程方面, 在提流程改善, 提升績效等預期執行方式往往會牽動到其他人員, 導致調整不易. 尤其是在部門人員已經被分派到多個專案中時, 更增加協調的困難.
專案經理在一開始就已經是從多個部門協調人員出來. 一旦最開始的人員和資源能確認後, 後續就比較不會受到干擾, 當然多個專案中共用資源也是會遇到關鍵資源發生排擠的狀況, 不過做資源撫平那又是另一門學問. 因為專案的生命週期較短, 也可實驗一些新的改善方法. 所以我個人是覺得專案經理的角色在執行面會容易些. 這個我個人的感覺, 在不同的單位或許會有不同的狀況.
前一陣子去上一門專案管理的課程, 微軟的專案管理講師主講, 當然內容有一部份是在介紹 MS 的 Project 系統在專案管理中的運用, 另外一部份則是在講專案管理的概念. 聽了之後讓我有衝動想去考 PMP , 買了一本 PMP專案管理認證指南在看, 有時間再把一些心得寫下來與大家分享.
--
訂閱：
文章 (Atom)
