發表文章

目前顯示的是 一月, 2006的文章

積極管理 有效開發

最近剛完成一個軟體專案,有些感想提出來分享。專案成功的因素,簡單來說八個字"積極管理,有效開發"。
專案經理對於專案的監控,應該要"積極管理",意思是說,除了定期召開專案會議(project review meeting)追蹤專案成員的工作進度;定期review milestone的產出是否符合預期;隨時留意專案監控值,包括專案scope、cost、schedule是否異常、另外,常被忽略的是,隨時注意專案成員的工作狀況,專案經理隨時要扮演溝通的角色,減少專案成員間溝通不良及衝突。佌外,專案經理的態度,對內應該嚴格而積極,對外應該態度微婉立場堅定。
至於專案的執行,應該與專案成員達成"有效開發"的共識,所謂有效,並非只要求要有效率,如果工作很快完成,但bug一堆,反而花費更多的人力在改bug。應該要在品質達成的前提下有效率的工作。前面提過,應該減少非專案的工作,把重心花在專案的工作(project work)上,以達到有效開發的目的。
雖然,專案經理負有專案成敗的責任,但一個專案的成敗只靠專案經理,絕對無法順利結案。專案成功的方程式:專案經理的積極管理 + 專案成員的有效開發 = 專案如期結案

del.icio.us提供Blog整合功能

Link rolls : 條列式列出文章
Tag rolls :以Tag歸類文章
Play Tagger : 在Blog上聽MP3? 還沒試出來

web2.0應用

這篇Blog整理了一些熱門的web2.0應用以及簡介,非常詳細

The Best Web 2.0 Software of 2005

More Great Web 2.0 Software

Less drive-bys, more project works

常常,我們發現專案成員常在做一些無關於專案本身的工作,例如修改之前系統發生的bugs;客戶抱怨系統效能不好,而花時間做performance tuning;花時間處理客戶新的需求....

如果在專案執行期間做好測試,上線後的bug就會控制在一定數量;系統設計及開發階段,就考慮到系統效能的問題,進而事先預防,也不至於在上線後花費人力做performance tuning;系統分析時,就已預先針對使用者的需求做整體的考量,並做好需求管理,就能解決大部分客戶需求變更的問題。

隨著專案時程的增加,這些非專案工作(drive-bys, non-project work)所耗費的時間與成本會呈等比級數的成長,因此Less drive-bys, more project works

Project Sponsor和Stackholder定義的釐清

這篇文章釐清了Project Sponsor和Stackholder的定義
給項目「發起人」和「關係人」正名
作者: 黃紹良  來源: www.csai.cn
任何項目經理在學習項目管理知識的過程中,都明白「Project Sponsor」(翻譯為「項目發起人」)及「Stakeholder」(翻譯為「項目干係人」)的重要性。但從我過去二十多年的項目管理經驗中,對這兩者的認識和在項目過程中需要建立的焦點,讓我感覺到一個項目管理應用的重大誤區。
我曾經在五月發表了一篇文章,內容主要說明我國軟件工程人員對需求的誤解,導致軟件行業未能有效把握客戶的「需求」,使我國的軟件缺乏創新。不期然,聯想到目前IT項目管理的應用,也因為一些錯誤的觀點,讓項目管理在IT企業中走上另一段冤枉路。
過去數年,項目管理在科技企業中漸漸被重視,企業希望利用項目管理的理念來強化項目的交付質量,最起碼也希望能夠讓項目可以如期完成交付,降低企業的交付成本,提升利潤。所以,很多從業人員誤以為只要考取了一個專業資格,便可以成為一個項目經理,有效執行項目管理的工作。
知識與體系的分別
要知道美國PMI項目管理的考試內容環繞著項目管理知識(PMBoK)的範圍,PMBoK不是一套體系(Methodology),它提供的是項目管理知識,但我們把Body of Knowledge 翻譯成為「知識體系」,讓我們誤會只要完成有關知識的學習,便可以有系統地直接實施。但往往在實際應用這些知識的時候,才發現無從入手。
「知識」讓我們知道「該做什麼」(What),而「體系」告訴我們「如何去做」(How)。缺乏一個體系,所有的知識只是理論,這也是為什麼國內的新進項目經理感嘆「不知如何把學習到的理論在實踐中應用」的主要原因。
為什麼一些基建項目,如蓋房子、修路、建水壩等項目,能夠有效利用項目管理的知識?那是因為這些項目的管理機制和實施流程比較成熟。項目在設計階段已經把建設的方法(Construction Processes)有效地融合到項目交付的流程和機制(體系)中。
科技項目所需的時間往往比較短,範圍變動也比較大,加上沒有一個實施的流程和管理機制,所以科技項目往往未能有效地把項目管理知識應用到實際的過程中。
國內企業缺乏自建管理體系
一些比較成熟的管理體系,包括歐洲國家單位及企業所選擇的Prince2 (Project in Cont…

測試是交付成功的優質的產品的保證

測試是交付成功的優質的產品的保證 (from www.csai.cn)
我們每個人,不會都是軟體測試人員,但都是某些軟體的用戶。缺省或默認情況下,用戶都會覺得買到的軟體是沒有問題的,一般不會去想這樣的軟體可能會有問題,用戶只要使用這些軟體來解決他們需要解決的問題就可以了。當他們發現問題的時候,甚至會感到震驚。
存在的問題很多都和測試的成效有關係,一般的軟體產品存在的問題確實比較少,但我覺得即使是以前買的正版的金山快譯2000都有著一些顯而易見的bug。如果測試不充分,那麼這些問題會潛伏在軟體中,等到用戶發現以後,再有開發人員進行維護,改正錯誤的費用一般是開發階段的40倍到60倍。
人們對測試存在著一些誤區,例如:

1 測試是想像到可能出現的問題,然後試圖驗證這些問題。
實際上能想像到的只是一部分的情況,隨意性太大,還要取決於開發人員的經驗,對業務的熟悉程度和他想像到的程度。

2 讓時間充裕的員工去做一些測試
表面上看這體現了管理的效率和靈活性,但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關係。測試工作人員應該是勤奮並富有耐心,善於學 習、思考和發現問題,細心有條理,總結問題,如果具備這樣的優點,做其他工作同樣也會很出色,因此這裏還有一個要求,就是要喜歡測試這項工作。
如果他是專職的,那麼肯定更有經驗和信心。國內的小夥子好像都喜歡做程式師,兩者工作性質不同,待遇不同,地位不同,對自我實現的價值的認識也不同,這是行業的一個需要改善的問題。如果只是為了完成任務而完成任務,或者發現了幾個問題就覺得滿意了,這在任何其他工作中都是不行的。

3 測試是相對簡單的工作。
實際上並非如此,要真正做好一件事都不容易。測試也有很多相關技術和工具。而對測試的輕視問題,也許要通過痛苦的經歷和結果才可能確切體會到。很多專家都在對測試的理論進行深入的探討和研究。
測試的基本知識
讓我們一起快速過一遍:
什麼是軟體測試:在軟體投入運行前,對軟體需求分析、設計規格說明和編碼的最終復審,是軟體品質保證的關鍵步驟。
測試的目標:以較少的案例、時間和人力找出軟體中潛在的各種錯誤和缺陷,以確保系統的品質。

從測試的類型來看,測試分為2種:黑盒測試和白盒測試。
黑盒測試又稱為功能測試或資料驅動測試,把系統看成一個黑盒子,不考慮程式的內在邏輯,只根據需求規格說明書的要求來檢查程式的功能是否符合它的功能說明。
白盒測試又稱為結構測試…

Google Earth推出Feed服務

Google Earth以RSS Reader的想法, 開放用戶可自由訂閱與分享各種衛星空照的景點

PMCDF 專案管理績效評估指標

PMCDF(Project Management Competency Development Framework), 是PMI發布的專案管理績效評估指標, 主要以專案經理知識能力(PM Knowledge Competence)、專案經理執行能力(PM Performance Competence)、專案經理個人能力(PM Personal Competence), 客觀的評量專案經理的能力

熟讀PMBOK或拿到PMP證照, 並不代表專案經理的核心職能就已建立, PMCDF的架構協助高階主管評估專案經理的專案管理知識與實務運用的能力,

詳細資訊, 可參考PMCDF在項目經理績效評估指標體系設計中的應用

Business 2.0: Tech's new resolutions

本期的Business 2.0報導幾家科技公司2006年的發展重點

Google's resolution: Reinvent the mobile phone

Apple's resolution: Keep pushing the envelope

Yahoo's resolution: Create a media hub

Microsoft's resolution: Go Live for real

Amazon.com's resolution: Let customers design their own products

Disney's resolution: Make Internet video a profit center

Business 2.0: My Golden Rule

圖片
本期的Business 2.0 My Golden Role介紹49位成功人士,分享他們的成功秘訣