走路與專案管理(轉)
儘管在專案初期和專案收尾時浪費的10分鐘看起來是一樣的,但它們帶來的影響是完全不同的,而沒有認識到這個差別有時會產生非常嚴重的後果。每天上下班都要走不少的路,卻是最近幾天才體會出走路與專案管理之間的聯絡。
因為基本能確定上班花在路上的時間,所以每天幾乎都是掐著點兒從家裡出發。可是在剛出門走去地鐵站的時候,因為覺得還早,所以挺悠哉的像散步一樣走過去。可是下了地鐵往往都8點10好幾,有時是11、2分,有時就是17、8分了,從地鐵站到公司也要10來分鐘,就只好緊趕慢趕,甚至跑步前進了。就算這樣也未必就能及時趕到公司,上次的遲到就是一個明證了。
專案管理也會出現同樣的情形。通常在專案啟動時,大家都知道我們有“大量的”時間,雖然可能這段時間相對於真實進度而言可能還是很緊張甚至是不夠的,可是大家看著數量“巨大”的時間資源擺在面前,很容易產生一種“還早呢”的懈怠感。於是在專案初期產生拖拉、分析設計不深入等問題也不足為奇。同樣,在專案中期雖然會感覺到一定的壓力,但仍會感覺有一定的“緩衝時間”在,有時也會產生“唉,這個問題我知道,等我有空了就馬上解決”或是“我知道這裡應該重新設計,可是我們還有時間,等過一會兒我有空了一定會好好設計的”這種想法/做法。然而當進行到專案收尾階段,大家才會發現時間不夠用,前面沒解決的問題全都拖到這個階段,各種各樣的毛病、問題和使用者反饋像火山一樣爆發,大家拼命加班加點,把所有精力都投入到Debug工作中,把那些“修飾性”的設計工作拋到了下一版,所有的團隊成員都為了準時提交可用的軟體這個唯一目標而努力奮鬥。最終也許可以準時提交(如果足夠幸運的話),但再拖延個三四周甚至幾個月也並不是什麼罕見的事。
為什麼會這樣呢?這是因為,在專案的啟動階段(開始走路時),我們擁有全部可調動的資源,同時我們的時間還沒有開始浪費在不相關的地方,所以在這個時候我們最容易也最有可能減少我們的浪費。就像走路時你完全可以在前半段稍稍提高你的速度,不必奔跑,就可以省下大概10多分鐘的時間,而這些時間足夠讓你悠閒的從地鐵站走到公司而不會遲到。同樣在專案開始時你可以透過對需求進行詳細而深入的分析,對系統進行全面的考慮而給出儘量合理的設計,在發現時間和資源浪費的同時糾正這些錯誤而提高開發速度,同時減輕資源(包括時間)的浪費。在前期的這些投入將使你在專案後期得到10倍甚至100倍的收益,因為你無法收回已浪費的時間和資源,但可以透過努力工作而減少尚未產生的浪費。
而在專案後期,絕大部分的時間和資源都已經被使用,儘管你知道很多被浪費了,你也沒有辦法再去收回;而同時你可以調動用來進行“補償”的資源也大大減少,之前由於懶惰、懈怠、草率造成的問題也都開始顯現,所以你在這時焦頭爛額,疲於奔命,但往往還是不得不面對你無法兌現你當初的承諾的悲慘結局。因為無論如何努力,人的能力是有限的,就像如果地鐵站與公司的距離是一個人拼命狂奔也需要15分鐘的話,你在只剩10分鐘的情況下無論如何努力也是要遲到的,因為你不能期望著你能比世界短跑冠軍跑得還快。
所以儘管在專案初期和專案收尾時浪費的10分鐘看起來是一樣的,但它們帶來的影響是完全不同的,而沒有認識到這個差別有時會產生非常嚴重的後果。
順便說一句,同走路一樣,通常不能期望專案相對於估算日期提前很多完成。因為當進入到專案後期,每個人都能夠肯定專案不會拖延,肯定能夠按時交付的時候,不能夠指望他們還會拼命的去提前釋出日期;相反,他們的通常做法是保持原來的進度甚至稍稍懈怠一些,因為“反正不可能遲到,為何不看著報紙走去公司?”。
所以如果專案比估算日期提前很多完成,那只有一種情況:估算本身偏離了實際情況太多,就如同早上上班出來的太早,儘管你走得很慢,可還是很早到了公司一樣。但要注意的是,儘管比預算提前了很多,但浪費也會更多?因為預算過於寬鬆,緊迫感會隨之降低。(e-WORKS)
[@more@]
因為基本能確定上班花在路上的時間,所以每天幾乎都是掐著點兒從家裡出發。可是在剛出門走去地鐵站的時候,因為覺得還早,所以挺悠哉的像散步一樣走過去。可是下了地鐵往往都8點10好幾,有時是11、2分,有時就是17、8分了,從地鐵站到公司也要10來分鐘,就只好緊趕慢趕,甚至跑步前進了。就算這樣也未必就能及時趕到公司,上次的遲到就是一個明證了。
專案管理也會出現同樣的情形。通常在專案啟動時,大家都知道我們有“大量的”時間,雖然可能這段時間相對於真實進度而言可能還是很緊張甚至是不夠的,可是大家看著數量“巨大”的時間資源擺在面前,很容易產生一種“還早呢”的懈怠感。於是在專案初期產生拖拉、分析設計不深入等問題也不足為奇。同樣,在專案中期雖然會感覺到一定的壓力,但仍會感覺有一定的“緩衝時間”在,有時也會產生“唉,這個問題我知道,等我有空了就馬上解決”或是“我知道這裡應該重新設計,可是我們還有時間,等過一會兒我有空了一定會好好設計的”這種想法/做法。然而當進行到專案收尾階段,大家才會發現時間不夠用,前面沒解決的問題全都拖到這個階段,各種各樣的毛病、問題和使用者反饋像火山一樣爆發,大家拼命加班加點,把所有精力都投入到Debug工作中,把那些“修飾性”的設計工作拋到了下一版,所有的團隊成員都為了準時提交可用的軟體這個唯一目標而努力奮鬥。最終也許可以準時提交(如果足夠幸運的話),但再拖延個三四周甚至幾個月也並不是什麼罕見的事。
為什麼會這樣呢?這是因為,在專案的啟動階段(開始走路時),我們擁有全部可調動的資源,同時我們的時間還沒有開始浪費在不相關的地方,所以在這個時候我們最容易也最有可能減少我們的浪費。就像走路時你完全可以在前半段稍稍提高你的速度,不必奔跑,就可以省下大概10多分鐘的時間,而這些時間足夠讓你悠閒的從地鐵站走到公司而不會遲到。同樣在專案開始時你可以透過對需求進行詳細而深入的分析,對系統進行全面的考慮而給出儘量合理的設計,在發現時間和資源浪費的同時糾正這些錯誤而提高開發速度,同時減輕資源(包括時間)的浪費。在前期的這些投入將使你在專案後期得到10倍甚至100倍的收益,因為你無法收回已浪費的時間和資源,但可以透過努力工作而減少尚未產生的浪費。
而在專案後期,絕大部分的時間和資源都已經被使用,儘管你知道很多被浪費了,你也沒有辦法再去收回;而同時你可以調動用來進行“補償”的資源也大大減少,之前由於懶惰、懈怠、草率造成的問題也都開始顯現,所以你在這時焦頭爛額,疲於奔命,但往往還是不得不面對你無法兌現你當初的承諾的悲慘結局。因為無論如何努力,人的能力是有限的,就像如果地鐵站與公司的距離是一個人拼命狂奔也需要15分鐘的話,你在只剩10分鐘的情況下無論如何努力也是要遲到的,因為你不能期望著你能比世界短跑冠軍跑得還快。
所以儘管在專案初期和專案收尾時浪費的10分鐘看起來是一樣的,但它們帶來的影響是完全不同的,而沒有認識到這個差別有時會產生非常嚴重的後果。
順便說一句,同走路一樣,通常不能期望專案相對於估算日期提前很多完成。因為當進入到專案後期,每個人都能夠肯定專案不會拖延,肯定能夠按時交付的時候,不能夠指望他們還會拼命的去提前釋出日期;相反,他們的通常做法是保持原來的進度甚至稍稍懈怠一些,因為“反正不可能遲到,為何不看著報紙走去公司?”。
所以如果專案比估算日期提前很多完成,那只有一種情況:估算本身偏離了實際情況太多,就如同早上上班出來的太早,儘管你走得很慢,可還是很早到了公司一樣。但要注意的是,儘管比預算提前了很多,但浪費也會更多?因為預算過於寬鬆,緊迫感會隨之降低。(e-WORKS)
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-955730/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 專案管理與專案經理(轉)專案管理
- 施工專案管理與專案成本控制(轉)專案管理
- IT監理與專案管理(轉)專案管理
- 專案管理的是與非(轉)專案管理
- 專案管理與軟體工程(轉)專案管理軟體工程
- 6西格瑪與專案管理(轉)專案管理
- 論專案管理與成本控制(轉)專案管理
- IT產品管理與專案管理的關係(轉)專案管理
- 專案現場與環境管理(轉)
- IT業專案管理與人才環境(轉)專案管理
- 專案管理與組織結構(轉)專案管理
- 專案管理與企業智商1(轉)專案管理
- 專案管理與企業智商2(轉)專案管理
- 專案管理與企業智商3(轉)專案管理
- 專案管理與企業智商4(轉)專案管理
- 與時俱進的專案管理(轉)專案管理
- 專案計劃與質量管理(轉)
- 專案經理與溝通管理(轉)
- IT專案管理的“羊肉”與“狗頭”(轉)專案管理
- IT專案管理(轉)專案管理
- 專案管理與足球比賽――淺談專案的人力資源管理(轉)專案管理
- 淺論專案經理的素質與專案管理(轉)專案管理
- 專案施工中的合同管理與技術管理(轉)
- 專案風險管理與蒙特卡羅方法(轉)
- 對安全專案的規劃與管理(轉)
- ERP專案的風險控制與管理(轉)
- 專案管理_轉載專案管理
- 專案成本管理 (轉)
- 按專案管理(轉)專案管理
- 專案風險管理(轉)
- 專案成本管理(轉)
- ERP專案實施應用與專案管理辯證方案(轉)專案管理
- 專案管理軟體與IT業界專案經理人的關係(2)(轉)專案管理
- 專案管理軟體與IT業界專案經理人的關係(3)(轉)專案管理
- 論專案管理中人的管理(轉)專案管理
- 專案管理過程之專案團隊(轉)專案管理
- 專案管理過程之專案團隊 (轉)專案管理
- [轉]Web專案管理思考Web專案管理