當主管從來不是一件容易的事. 說不容易最主要是不像 工程 , 可以有很明確的規則和評量方法, 知道是否有把事情做好. 擔任主管並不一定是技術能力最好的人, 但通常需要溝通能力較好的人. 因為主管, 最主要的工作應是管理, 讓人把事情做好, 擔任 分配資源, 指派工作, 溝通協調, 監督查核, 評估績效 等工作.
只要是和 人 有直接相關的事, 就會面臨不同人反應不同的問題. 在前一個團隊可行的方法, 換到另一團隊可能就會變得滯礙難行. 想用同一套方法就不出問題, 除非是管理的團隊成員一直不變才有可能. 不過在現在人員流動的狀況下, 這種假設太過理想化.
要如何做管理與領導呢? 摘要幾個重點
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月21日 星期日
格式工廠 - 影片格式轉換的免費工具程式
在電腦中存放許多的影片檔, 有些是自己 DV 拍回來的, 有些是別人提供的的影片檔, 之前又因為老婆堅持用大電視, 不願意在電腦前的小螢幕前看. 所以我特別去買一個 RMVB 的播放器, 可以播 RMVB/AVI/MPG/MOV/WAV/MP3... 等多種影音格式. 只是那個播放器的晶片還是有點問題, 對影像檔只有 RMVB 和 MPG 播放較順, 播其他格式有時會時間軸異常或跳格. 所以就去尋找了一個可以快速轉換格式, 而且品質可以接受的轉檔程式.
最後我使用的是這一套免費授權的 格式工廠(FormatFactory), 到現在已經出到 v2.20 (2009-11-26), 支援多國語文介面
主畫面如下, 這套軟體會自動測目前使用的語言
可從 DVD 轉換成指定的影片格式
All to MP4/3GP/MPG/AVI/WMV/FLV/SWF.
Format Factory's Feature:
1 support converting all popular video,audio,picture formats to others.
2 Repair damaged video and audio file.
3 Reducing Multimedia file size.
4 Support iphone,ipod multimedia file formats.
5 Picture converting supports Zoom,Rotate/Flip,tags.
6 DVD Ripper.
7 Supports 50 languages
OS requirements: All 32 windows OS
最後我使用的是這一套免費授權的 格式工廠(FormatFactory), 到現在已經出到 v2.20 (2009-11-26), 支援多國語文介面
主畫面如下, 這套軟體會自動測目前使用的語言
可從 DVD 轉換成指定的影片格式
也可以合併影片檔案
官方網站
Format Factory is a multifunctional media converter.
Provides functions below:All to MP4/3GP/MPG/AVI/WMV/FLV/SWF.
All to MP3/WMA/AMR/OGG/AAC/WAV.
All to JPG/BMP/PNG/TIF/ICO/GIF/TGA.
Rip DVD to video file , Rip Music CD to audio file. MP4 files support iPod/iPhone/PSP/BlackBerry format.
Supports RMVB,Watermark, AV Mux.
1 support converting all popular video,audio,picture formats to others.
2 Repair damaged video and audio file.
3 Reducing Multimedia file size.
4 Support iphone,ipod multimedia file formats.
5 Picture converting supports Zoom,Rotate/Flip,tags.
6 DVD Ripper.
7 Supports 50 languages
OS requirements: All 32 windows OS
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專案管理認證指南在看, 有時間再把一些心得寫下來與大家分享.
--
2010年3月11日 星期四
加速執行效能的 Gavotte RAM Disk
雖然早在 DOS 時代, 就已經有 RAM Disk 存在, 但在進入 Windows 時代後, 就比較少人使用到這項技術, 大部份的記憶體都被 Windows 系統本身, 和日趨肥大的應用程式給佔用了, 那裏還有多少空間可以把 RAM 當做 磁碟機 來用.
現在記憶體越來越便宜, 很容易就可以在主機上加上 4G, 8G 的RAM. 不過大多數的使用者(包括我自己), 其實一般在使用時, 並不會直的用到這麼大量的記憶體, 看到 RAM 的空間使用量經常不到一半, 你會不會想要拿來好好的運用呢?
提供 RAM Disk 這個功能的軟體有好幾家, 分享一下我使用的方式. 現在使用在 NB 的Vista 環境, 安裝 Gavotte ramdisk (Freeware), 主要是將 TEMP 資料夾, Internet 暫存檔 等設定到 RAM Disk 中, 以加速上網 Cache 的讀寫速度.
Gavotte ramdisk 的官方網站我沒辦法確認是那一個, 不過我這從這個位置取得
說明網頁
http://www.mydigitallife.info/2007/05/27/free-ramdisk-for-windows-vista-xp-2000-and-2003-server/
下載位置
http://depositfiles.com/files/916161
我的 NB配備如下圖
在 IE 中可以從 工具 / 網際網路選項 / 一般 / 瀏覽記錄歷程 設定 / 移動資料夾 去設定存放的CACHE的位置, 我是設定 60MB 存放到 R:\TEMP\ 目錄下.
在 控制台 / 系統 / 進階 / 環境變數 中可以將 TEMP 和 TMP 也都指定到 R:\TEMP
現在記憶體越來越便宜, 很容易就可以在主機上加上 4G, 8G 的RAM. 不過大多數的使用者(包括我自己), 其實一般在使用時, 並不會直的用到這麼大量的記憶體, 看到 RAM 的空間使用量經常不到一半, 你會不會想要拿來好好的運用呢?
提供 RAM Disk 這個功能的軟體有好幾家, 分享一下我使用的方式. 現在使用在 NB 的Vista 環境, 安裝 Gavotte ramdisk (Freeware), 主要是將 TEMP 資料夾, Internet 暫存檔 等設定到 RAM Disk 中, 以加速上網 Cache 的讀寫速度.
Gavotte ramdisk 的官方網站我沒辦法確認是那一個, 不過我這從這個位置取得
說明網頁
http://www.mydigitallife.info/2007/05/27/free-ramdisk-for-windows-vista-xp-2000-and-2003-server/
下載位置
http://depositfiles.com/files/916161
我的 NB配備如下圖
我沒在 x64 的環境執行, 若是使用 64位元的Windows 環境, 需要另外下載, 我這邊就不介紹了.
執行畫面如下, 我是分割出 128MB 的記憶體當成磁碟機 (R:)使用.
在 控制台 / 系統 / 進階 / 環境變數 中可以將 TEMP 和 TMP 也都指定到 R:\TEMP
訂閱：
文章 (Atom)
