JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » 交流、聊天、灌水  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友   
reply to topicthreaded modego to previous topicgo to next topic
己加入精華區
by koji at 2007-04-18 22:54
本主題所含的標籤
無標籤
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:singlelog]
blueman77





發文: 0
於 2007-05-04 09:27 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
我覺得,PM的技術能力不需要最強,可是需要有很敏銳的嗅覺。然後也需要對怎麼掌握人性要很了解。

有時候,你要去解決問題,技術人想到的永遠是最佳解。不過實務上很多都是compromise的結果。所以,你要學會理解,當人家說,沒有超人不行時,這件事情不一定只有超人可以解,你可能找個蝙蝠俠,再配上蜘蛛人,就可以了。

特別是,有時候,你要把技術人員拉回現實面一些,當他認為自己不懂政治也可以出馬選總統時,要記得拉他一把。現實生活不像理論那麼愉快,不懂政治的人也可以說我繳幾百萬出來選個總統也會上。這只是在浪費錢而已。

通常你只要告訴工程師說現在的資源不夠他這樣搞,他自己就會提出次佳解了,但這是直接對工程師,如果是IT LEADER的話,未免就太沒sense了,總之不需PM直接給解,這是強人的作法。我也不認為這樣是對的作法。


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:blueman77]
eriklin





發文: 89
於 2007-05-04 10:36 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
blueman77 wrote:
通常你只要告訴工程師說現在的資源不夠他這樣搞,他自己就會提出次佳解了,但這是直接對工程師,如果是IT LEADER的話,未免就太沒sense了,總之不需PM直接給解,這是強人的作法。我也不認為這樣是對的作法。

有時候就是沒資源,不是不夠,就是沒有,問題還是回到PM
PM不能是強人,所以IT LEADER就應該是?


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:chermanyen]
zhengck





發文: 0
於 2007-05-04 10:55 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
看到現在,已經開始混亂了Smile

工作定位應該是分成 權,責,能 三個部份

權是指管理用人,跟分派工作的權利

責是指專案成敗的責任,基本上就是被定的時候要被罵的啦Big Smile

能是指工作上所需要的能力,懂不懂技術可能是附加的能力選項

PM的權責能在不同的公司可能有不同的定義

就像部長,市長,里長,雖然都是長

但是做的事情就是不一樣,並不適合拿來討論比較


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:kenchu]
panteratw





發文: 14
於 2007-05-04 11:21 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
kenchu wrote:
…恕刪
最後,您是版主
如果您是用這樣的態度再討論
一再的以自身優秀的經履歷來貶低我

那我不想再討論了

dear sir,

您好。貶低!!被貶低有什麼關係呢??如果您能夠提出更充份的說明,並且讓人認同,那麼不就更讓人括目相看,不是嗎??

由其現在有人和您談到CMMI了,但是卻有兩造的結果,希望您們可以繼續討論下去。雖然我不清楚CMMI,只看過一些相關說明,但我不相信對於CMMI會有不同的解釋。所以若不是您們談的是不同的面向,要不就是您們有一方沒有解釋清楚。

我認為僅管知識是有價的,但若要能夠說服人,也成長自己,指教別人的時後,或是想要論述的時後,說明清楚,會是個讓人配服的作法,這比只丟下一句你錯了,然後什麼都不說來得好。

希望您們可以繼續討論,對後輩,對您們個人,應該都會是件好事,謝謝您。


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:kenchu]
cphunterlin





發文: 193
於 2007-05-04 12:20 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
為什麼開發不得兼管理? Dead , 您的偏頗說法. 個人非常不贊同.
很多時候, 一個專案, 就一個人做也行的.
在我們公司, 雖然聽說有800 人. 但有些專案, 都是一個 PM + 一個工程師就go.

軟體工程是什麼? 什麼叫做起來? 您是有看過嗎? 有身歷其境? 可以具體描述?
我待過真的有軟體工程概念的一家日本30年的公司, 他怎麼做軟工?

是制度嗎? 可說是、也可說不是. 軟工..還蠻抽像的, 但如何產生軟體 , 架構和解決方案. 量化基礎、計算管理、作業評估和軟體估價的 SOP...ect . 非一句話可概括....

kenchu wrote:

只是不要開發得兼管理...

現實是要把軟體工程做起來
才有能力把台灣資訊業做起來...

如果真的老是要以個案
以幾萬的專案來說這種專案管理不可行
那就都做幾萬的專案就好
反正也沒大點得專案好做了


reply to postreply to post
我用程式語言去勾勒腦中的想像. 尤如規則的實踐家~
在指尖上散淡淡的煙草香,卻染上法律、資訊、人脈和熱情 ~
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:kenchu]
cphunterlin





發文: 193
於 2007-05-04 13:28 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
CMMI 的目標方法, 在我所在的工作上 , 一直被用來當研發工程時數的一個基石.

我所在的公司、也許有CMMI 、也許沒有;但我心中有一個底.
我會去了解公司的人員素質、過去經歷、開發態度、甚至興趣.
這是為什麼?

CMMI 的量化方法和一整套的軟體架構概念, 因為帶專案的時間久了, 在我的經驗和配合上我所整理出來的 dataform , 一直是用來評估研發的一個標準.

我為了去 try 我的方法論,從軟體公司走出來,去政府單位、機械、醫療、貿易、電信、金融、直銷,甚至現在的網路科技產業,我去 try 我自己的 model , 但CMMI 方法論用來直接估算人力工時這套, 我覺得它用來做持續改進的工作 這個效益大過於一切....

CMMI 5 中,我覺得通過評估測試的license 後 , 如果把進度、工作量、成本和軟體質量等經驗的紀錄下來,進行多方向、多維度和人力素質產出上的分析,及PM 去參與這個專案時, 工程師的能力成長、專長應用、處理方法、解決問題的態度...etc ..等有一個record。

我工作時餘,在軟體工程上的成長,經回想來自許多的地方。除了對技術的偏執和自己的定位清楚外,吸收了日本人文件管理和持續改進的企業精神和方法論;我最愛和日本的老企業家餐敘請益,軟體工程他們也許沒聽過、知識管理的提出之前,他們的企業就是一個高度知識的公司,我提出幾個我有在往來的公司高層決策主管,Toray(醫療和材料)、Fanuc、Sumitomo、Fuji 、GE-Fanuc....etc...公司的相關主管,他們的產出成本,重點就在 software 的研發, 他們怎麼做的? 日本公司各有一套方法論, 但絕對不是 一件事,多少人力....這樣的簡單定義.
p.s 如果這樣,幹嘛有資深工程師、幹嘛有 junior 和 senior 之分,還有一個有經驗的工程師的產出 > n 個無經驗或初階的工程師, 甚至在程式碼的維護,可再用、可修改性上都會比 juior 來的好很多....我指的是真正的 senior ,不是在年資上混年資的人. 也不會寫出一堆不能切割和維護的 source code
p.s 剛好手上在改一個之前工程師留下的 code ,看到現在一肚子氣,連一個註解也沒有的程式碼,而且程式碼亂七八糟.... 我也在考慮要不要把他的事拿出來評一評....唉Disapproved

軟體工程真的沒那麼簡單,現在我們在討論的東西,好像是在討論管理學導論,您說的是管理科學中的量化理論,小弟我提的是管理科學它已經不單單是用數字和量化來分析一些具體問題,而是用自然科學與社會科學兩大領域的綜合性交叉科學來分析,人力資源管理,風險管理與不確定性決策,複雜系統的演化、湧現、自適應、自組織、自相似的機理等。已經不是一個運籌學所能涵蓋的。Big Smile

so , 20世紀有個叫 Follett 的人, 把這叫做:讓人們做事的藝術,在 PM 的管理範圍中, 有能力的PM 會去運用資源(這很重要) , 然後會去把專案適宜的、如期的,在內部進度和外部需求雙方面,掌握資源的分配和產出的品質及需求方向的控制...etc.... 您意下如何呢?Shy

kenchu wrote:
我不是說CMMI 不適合研發
我是說 CMMI Level 5 的目標方法,
不適合套用研發上
因為其量化方式,重複性越高,正確性越高
如果套用在研發上,其量化較難達到
雖用很多可行的方式,但如果真要做到像生產化設備
投料多少,運轉多久就產出多少成品
那還是重複性高得專案,達成率高
我這樣說難道不是事實嘛..


reply to postreply to post
我用程式語言去勾勒腦中的想像. 尤如規則的實踐家~
在指尖上散淡淡的煙草香,卻染上法律、資訊、人脈和熱情 ~
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:eriklin]
blueman77





發文: 0
於 2007-05-04 13:34 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
eriklin wrote:
有時候就是沒資源,不是不夠,就是沒有,問題還是回到PM
PM不能是強人,所以IT LEADER就應該是?

你這是過度引申我的意思了
資源不足和技術能力有什麼關係呢?
技術夠強,就可能不需要這些資源了?
你這個是PM技術比較強,還是IT LEADER技術比較強的問題
IT LEADER實際從事他的工作,和以角色而言他對該領域勢必要比PM熟悉
為什麼總要假設IT LEADER不能解的技術問題,PM可以解?
為什麼這個PM總愛插手技術的事務
我真搞不懂


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:blueman77]
eriklin





發文: 89
於 2007-05-04 14:03 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
blueman77 wrote:
你這是過度引申我的意思了
資源不足和技術能力有什麼關係呢?
技術夠強,就可能不需要這些資源了?
你這個是PM技術比較強,還是IT LEADER技術比較強的問題
IT LEADER實際從事他的工作,和以角色而言他對該領域勢必要比PM熟悉
為什麼總要假設IT LEADER不能解的技術問題,PM可以解?
為什麼這個PM總愛插手技術的事務
我真搞不懂

您才是過度引申吧

我只說問題回到PM身上,這就表示PM自己下去解?

當LEADER就是會遇到一些鳥事
PM找人來給工程師,結果他沒機器可以用,找誰?
就算IT LEADER家裡在光華商場開店,沒有就是沒有,還不是找PM
IT LEADER光管技術不管人?
這問題太鳥?好!

現在的技術問題整個Team沒有人有這個Skill Set
慢慢自己培養人弄要一個月,外面找人來比較快,IT LEADER剛好有這個人選
他就直接找人來?
也許PM覺得一個月的時間還可以,他要節制一下成本

要花一個月自己培養人弄還是去外面找人,這不是IT LEADER的call


eriklin edited on 2007-05-04 14:06
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:eriklin]
blueman77





發文: 0
於 2007-05-04 14:16 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
eriklin wrote:
您才是過度引申吧

我只說問題回到PM身上,這就表示PM自己下去解?

當LEADER就是會遇到一些鳥事
PM找人來給工程師,結果他沒機器可以用,找誰?
就算IT LEADER家裡在光華商場開店,沒有就是沒有,還不是找PM
IT LEADER光管技術不管人?
這問題太鳥?好!

現在的技術問題整個Team沒有人有這個Skill Set
慢慢自己培養人弄要一個月,外面找人來比較快,IT LEADER剛好有這個人選
他就直接找人來?
也許PM覺得一個月的時間還可以,他要節制一下成本

要花一個月自己培養人弄還是去外面找人,這不是IT LEADER的call

不好意思
你舉了一堆例子
但我看不出這個PM需技術能力有啥關係。。。


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:eriklin]
blueman77





發文: 0
於 2007-05-04 14:23 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
eriklin wrote:
您才是過度引申吧

我只說問題回到PM身上,這就表示PM自己下去解?

當LEADER就是會遇到一些鳥事
PM找人來給工程師,結果他沒機器可以用,找誰?
就算IT LEADER家裡在光華商場開店,沒有就是沒有,還不是找PM
IT LEADER光管技術不管人?
這問題太鳥?好!

現在的技術問題整個Team沒有人有這個Skill Set
慢慢自己培養人弄要一個月,外面找人來比較快,IT LEADER剛好有這個人選
他就直接找人來?
也許PM覺得一個月的時間還可以,他要節制一下成本

要花一個月自己培養人弄還是去外面找人,這不是IT LEADER的call

我懂了
你是來灌水的,是吧?

Big Smile


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:cphunterlin]
kenchu





發文: 128
於 2007-05-04 14:24 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
因為當一個專案本身就是要可以監督
所以管理的人不適合兼任開發
就像要求
球員不要兼裁判一樣的道理
這是專案組織的要求
做不做都可以,但應避免
因為客戶會在意這種工作分配

這根本就是專案管理的常識
這樣說還叫偏頗說法

如果說話要用這種語氣
那我覺得就不要再討論了

cphunterlin wrote:
為什麼開發不得兼管理? Dead , 您的偏頗說法. 個人非常不贊同.
很多時候, 一個專案, 就一個人做也行的.
在我們公司, 雖然聽說有800 人. 但有些專案, 都是一個 PM + 一個工程師就go.

軟體工程是什麼? 什麼叫做起來? 您是有看過嗎? 有身歷其境? 可以具體描述?
我待過真的有軟體工程概念的一家日本30年的公司, 他怎麼做軟工?

是制度嗎? 可說是、也可說不是. 軟工..還蠻抽像的, 但如何產生軟體 , 架構和解決方案. 量化基礎、計算管理、作業評估和軟體估價的 SOP...ect . 非一句話可概括....


kenchu edited on 2007-05-04 14:30
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:panteratw]
kenchu





發文: 128
於 2007-05-04 14:28 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我之所以說貶低
是因為根本無法討論下去

如果我跟各位說
我專案XX年,我從沒聽過這樣管理
你這樣會被打槍

那還有什麼好討論的 ?
所以我不喜歡使用這種方式討論
請問真的還要討論麻...

坦白說,本討論一直在討論PM需不需要技術才能管理好專案
我個人一直認為不需要技術也可以管好
這樣也會被說成我認為不會技術的PM,才可以管好專案
然後就說我都亂說...
真的有完整看過我的論述麻

panteratw wrote:
dear sir,

您好。貶低!!被貶低有什麼關係呢??如果您能夠提出更充份的說明,並且讓人認同,那麼不就更讓人括目相看,不是嗎??

由其現在有人和您談到CMMI了,但是卻有兩造的結果,希望您們可以繼續討論下去。雖然我不清楚CMMI,只看過一些相關說明,但我不相信對於CMMI會有不同的解釋。所以若不是您們談的是不同的面向,要不就是您們有一方沒有解釋清楚。

我認為僅管知識是有價的,但若要能夠說服人,也成長自己,指教別人的時後,或是想要論述的時後,說明清楚,會是個讓人配服的作法,這比只丟下一句你錯了,然後什麼都不說來得好。

希望您們可以繼續討論,對後輩,對您們個人,應該都會是件好事,謝謝您。


kenchu edited on 2007-05-04 15:42
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:cphunterlin]
kenchu





發文: 128
於 2007-05-04 14:48 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
CMMI 的人力資源量化用了很多的辦法
但多數都在於系統分析到很細
工程師就像工人一樣
按圖施工,所以才有可能很精準的計算到工時
但要做到這種程度,分析要做到很細
產出物也要訂到很細
所以通常都是需要經過經驗的累積
才能在一開始的階段就可以精確算出工時
也才能達到 CMMI Level 5 的境界 : 最佳化
因為已經有了可以精確算出工時所以才可以找出最佳的路線,得以最佳化
CMMI 本身就是要像 ISO ,只是偏向軟體業的 ISO
但人的問題一直是軟體開發的問題
所以很難向生產機器一樣,可以算出產能
只要知道要備多少料,運轉多久,良率,品管...等
知道這些資料,就可以算出這間公司生產的品質,產量等...
但軟體很難,所以CMMI才會以成熟度的方式來做
因為其方法就是要透過各種目標方法的執行
來看出產能與品質,
所以CMMI導的是整間公司的專案組織、專案制度,工作項目(目標方法)
並透過一堆目標方法執行去掌控。

但其因為研發性質原因
專案性質可能常常會改變,而且幅度可能很大
如果專案性質改變,很難以之前的經驗套用在現在的經驗上
不是不能,而是沒辦法很精準
而Level 4 已經要求到要將資源(包含人力)量化,並持續改進,如果要到 level 5 則要找出最佳路徑,
最佳路徑的找尋,本身就是要經驗的累積
所以重複性越高的專案,其經驗越能達到 Level 5 的要求:最佳化
所以我才會說 Level 5 不適合研發類得專案
因為其效果沒有重複性高的專案來的好
導了 level 5 卻可能只有 level 4 的效果
所以我個人才會說不適合
level 5 做了很多最佳化的目標執行方法
可是其效果卻跟 level 4 一樣
而且其經驗又不能累積
那level 5 的導入就顯得沒有意義
還不如用 Level 4 來做

您自己也提到持續改進的工作
但這些目標工作的執行
是否本來就是累積經驗的做法
如果研發是差異極大的內容
那累積的效果本來就沒有重複性高的專案來的大

我解釋的夠清楚嘛,如果我這樣叫偏頗
這樣是亂說一通,那我就閉嘴

cphunterlin wrote:
CMMI 的目標方法, 在我所在的工作上 , 一直被用來當研發工程時數的一個基石.

我所在的公司、也許有CMMI 、也許沒有;但我心中有一個底.
我會去了解公司的人員素質、過去經歷、開發態度、甚至興趣.
這是為什麼?

CMMI 的量化方法和一整套的軟體架構概念, 因為帶專案的時間久了, 在我的經驗和配合上我所整理出來的 dataform , 一直是用來評估研發的一個標準.

我為了去 try 我的方法論,從軟體公司走出來,去政府單位、機械、醫療、貿易、電信、金融、直銷,甚至現在的網路科技產業,我去 try 我自己的 model , 但CMMI 方法論用來直接估算人力工時這套, 我覺得它用來做持續改進的工作 這個效益大過於一切....

CMMI 5 中,我覺得通過評估測試的license 後 , 如果把進度、工作量、成本和軟體質量等經驗的紀錄下來,進行多方向、多維度和人力素質產出上的分析,及PM 去參與這個專案時, 工程師的能力成長、專長應用、處理方法、解決問題的態度...etc ..等有一個record。

我工作時餘,在軟體工程上的成長,經回想來自許多的地方。除了對技術的偏執和自己的定位清楚外,吸收了日本人文件管理和持續改進的企業精神和方法論;我最愛和日本的老企業家餐敘請益,軟體工程他們也許沒聽過、知識管理的提出之前,他們的企業就是一個高度知識的公司,我提出幾個我有在往來的公司高層決策主管,Toray(醫療和材料)、Fanuc、Sumitomo、Fuji 、GE-Fanuc....etc...公司的相關主管,他們的產出成本,重點就在 software 的研發, 他們怎麼做的? 日本公司各有一套方法論, 但絕對不是 一件事,多少人力....這樣的簡單定義.
p.s 如果這樣,幹嘛有資深工程師、幹嘛有 junior 和 senior 之分,還有一個有經驗的工程師的產出 > n 個無經驗或初階的工程師, 甚至在程式碼的維護,可再用、可修改性上都會比 juior 來的好很多....我指的是真正的 senior ,不是在年資上混年資的人. 也不會寫出一堆不能切割和維護的 source code
p.s 剛好手上在改一個之前工程師留下的 code ,看到現在一肚子氣,連一個註解也沒有的程式碼,而且程式碼亂七八糟.... 我也在考慮要不要把他的事拿出來評一評....唉Disapproved

軟體工程真的沒那麼簡單,現在我們在討論的東西,好像是在討論管理學導論,您說的是管理科學中的量化理論,小弟我提的是管理科學它已經不單單是用數字和量化來分析一些具體問題,而是用自然科學與社會科學兩大領域的綜合性交叉科學來分析,人力資源管理,風險管理與不確定性決策,複雜系統的演化、湧現、自適應、自組織、自相似的機理等。已經不是一個運籌學所能涵蓋的。Big Smile

so , 20世紀有個叫 Follett 的人, 把這叫做:讓人們做事的藝術,在 PM 的管理範圍中, 有能力的PM 會去運用資源(這很重要) , 然後會去把專案適宜的、如期的,在內部進度和外部需求雙方面,掌握資源的分配和產出的品質及需求方向的控制...etc.... 您意下如何呢?Shy


kenchu edited on 2007-05-04 15:52
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:chermanyen]
kenchu





發文: 128
於 2007-05-04 15:09 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我其實覺得很累
我的話一再被誤解
我本不想回
不過孤獨木大大希望我回答問題
所以我在這裡回答對我的質疑

但我個要求
請先釐清現在我們要討論的是專案管理還是軟體管理
要討論PM 指的是專案經理還是開發組織經理
如果要討論專案管理,請以專案管理的角度討論
雖然軟體開發專案多數的工作項目與軟體管理一致
但一個是管專案,一個是管軟體

專案是只用有限的資源做一件事
所以管理的重點是資源(所以一個PM本來就是把人力當資源,哪來的壓榨...)

軟體管理是以工程學的角度把軟體開發當做一件工程來管理
所以其管理的重點是軟體品質

兩者不同
但一個軟體開發專案本來就是一個專案然後有一個很大的工作項目叫做軟體開發
但兩者管理得角度不同

專案管理強調資源的運作。
軟體管理強調軟體開發的品質。

一個像是要用這些錢建立一間房子
另一個則是要怎建立好一棟房子

兩者本身就不同
所以PM跟軟體開發組組長在意的角度本身也不同

我真的希望大家可以分清楚後,再給予我指教

我有空我會很認真的回大家
但懇請不要用傲人的經履率來當作正確與否的標準

小弟雖不才,但我曾在因緣巧合下一個人模擬整個專案組織的成員
產出所有工作項目,而其產出物是客戶聘請資深顧問來監督
產出的工作項目,也是客戶付款的依據
其金額上億到上千萬都有
也是因為這個因緣
所以我了解整個專案組織的運作與工作責任
才有這些論述

有人認為我是打高空,我都願意接受
不過請不要惡意攻訐
謝謝

另外我必須說對不起
其實我說話很直,有時非故意但多少會讓人不悅
我很希望大家可以原諒我
我是真的沒什麼惡意


kenchu edited on 2007-05-04 15:26
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:kenchu]
antijava





發文: 65
於 2007-05-04 15:46 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
kenchu wrote:
我其實覺得很累
我的話一再被誤解
我本不想回
不過孤獨木大大希望我回答問題
所以我在這裡回答對我的質疑
...(恕刪)


沒禮貌, 名字又寫錯了,
還是你是故意氣他的Big SmileBig Smile

kenchu wrote:
...(恕刪)
但我個要求
請先釐清現在我們要討論的是專案管理還是軟體管理
要討論PM 指的是專案經理還是開發組織經理
如果要討論專案管理,請以專案管理的角度討論
雖然軟體開發專案多數的工作項目與軟體管理一致
但一個是管專案,一個是管軟體
...(恕刪)


這點好像有點難,
大家好像在討論「同一件事」,
又好像討論的不是「同一件事」DeadDead

其實這麼多篇看下來,
大致上各位的看法都表達的差不多了,
除了看法之外,
陸陸續續也加入了不少錯誤解讀, 挖苦, 諷刺和履歷表ShockShock

想起信義房屋的一句廣告台詞,
提出來大家互相勉勵勉勵,
「杯子滿了, 就沒法再倒水進去了」

各位都是身經百戰的沙場老將,
在這裡分享傳承多年的征戰經驗給後輩知道,
本是美事一件,
不要弄得刀光劍影, 血流成河嗎....

相信各位的杯子早就滿了,
有時真的要靜下心來,
聽聽別人的看法,
告訴自己不要 hearing without listening,
告訴自己不要 see only what I want to see,
杯子滿了, 就換個大一點的杯子,
或是像我一樣,
將杯子打碎, 砍掉重練....TongueTongue

砍掉重練的初心者 敬上


reply to postreply to post

作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:antijava]
kenchu





發文: 128
於 2007-05-04 15:48 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list

真的麻
對不起喔
我一像不會記男生名
我真不是故意的
孤獨木大大

antijava wrote:
沒禮貌, 名字又寫錯了,
還是你是故意氣他的Big SmileBig Smile

這點好像有點難,
大家好像在討論「同一件事」,
又好像討論的不是「同一件事」DeadDead

其實這麼多篇看下來,
大致上各位的看法都表達的差不多了,
除了看法之外,
陸陸續續也加入了不少錯誤解讀, 挖苦, 諷刺和履歷表ShockShock

想起信義房屋的一句廣告台詞,
提出來大家互相勉勵勉勵,
「杯子滿了, 就沒法再倒水進去了」

各位都是身經百戰的沙場老將,
在這裡分享傳承多年的征戰經驗給後輩知道,
本是美事一件,
不要弄得刀光劍影, 血流成河嗎....

相信各位的杯子早就滿了,
有時真的要靜下心來,
聽聽別人的看法,
告訴自己不要 hearing without listening,
告訴自己不要 see only what I want to see,
杯子滿了, 就換個大一點的杯子,
或是像我一樣,
將杯子打碎, 砍掉重練....TongueTongue

砍掉重練的初心者 敬上


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:blueman77]
eriklin





發文: 89
於 2007-05-04 15:49 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
blueman77 wrote:
不好意思
你舉了一堆例子
但我看不出這個PM需技術能力有啥關係。。。


當然有關,你總是要了解問題吧
為什麼你需要有這個Skill Set的人?
要用這個Skill Set生出來的東西,算是在Critical Path上,沒有會死人嗎?
別人報上來的東西PM就是要消化一下,要委派等專案結束升官當CEO再來說委派吧

舉例當然是不完整,省略掉很多的背景因素
實際專案就是狀況很多


eriklin edited on 2007-05-04 15:51
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:kenchu]
cphunterlin





發文: 193
於 2007-05-04 15:52 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Kenchu , 事情沒有決對的啦... Big Smile
會說偏頗是因為您..把話說死了...
每種 situation 都有的, 其實制度是制度、實作是實作 ....

其實有人說 , 為何我很欣賞一些日本的公司. 也欣賞鴻海的工程能力...
專案的管理、不一定是管理的人適不適合去兼任開發之類的...
誰有能力主導,他又願意去做,何不可為呢?

我們公司有很多一人 team ,就是 PM 兼工程師(like :股市頻道)
您說的對:球員不兼裁判 , 但軟體開發工作是場競賽嗎?

我個人覺得不是耶,是一場建築的工程....

您說客戶在意工作分配的部分? 我又更不了解了.
在我當PM 的時候, 我就白天談專案需求和做程式開發工作、Seminar等工作.
晚上去做 beta testing 和工作上 review 和再審核及文件的 check.

客戶對我兼PM、業務面和工程面沒啥不滿的呀 , 也這樣過了一大段的時間...
我不知道這違反了專案管理的常識耶..... *_*

可以向您請教嗎?
kenchu wrote:
因為當一個專案本身就是要可以監督
所以管理的人不適合兼任開發
就像要求
球員不要兼裁判一樣的道理
這是專案組織的要求
做不做都可以,但應避免
因為客戶會在意這種工作分配

這根本就是專案管理的常識
這樣說還叫偏頗說法

如果說話要用這種語氣
那我覺得就不要再討論了


reply to postreply to post
我用程式語言去勾勒腦中的想像. 尤如規則的實踐家~
在指尖上散淡淡的煙草香,卻染上法律、資訊、人脈和熱情 ~
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:antijava]
cphunterlin





發文: 193
於 2007-05-04 15:55 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
有點像阿扁欠四大天王之中的其中一段...

最近看來,版上這文...還真砍到見骨了....Big Smile

antijava wrote:
其實這麼多篇看下來,
大致上各位的看法都表達的差不多了,
除了看法之外,
陸陸續續也加入了不少錯誤解讀, 挖苦, 諷刺和履歷表ShockShock
各位都是身經百戰的沙場老將,
在這裡分享傳承多年的征戰經驗給後輩知道,
本是美事一件,
不要弄得刀光劍影, 血流成河嗎....

相信各位的杯子早就滿了,
有時真的要靜下心來,
聽聽別人的看法,
告訴自己不要 hearing without listening,
告訴自己不要 see only what I want to see,
杯子滿了, 就換個大一點的杯子,
或是像我一樣,
將杯子打碎, 砍掉重練....TongueTongue


reply to postreply to post
我用程式語言去勾勒腦中的想像. 尤如規則的實踐家~
在指尖上散淡淡的煙草香,卻染上法律、資訊、人脈和熱情 ~
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:cphunterlin]
kenchu





發文: 128
於 2007-05-04 16:04 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
不敢

但試問

除了您之外,誰有能力監督本專案
對一間公司而言
專案成敗繫乎您一人身上
對一間公司而言,這是好的麻?
專案管理之所以要這樣要求
重點在於整個組織的運行得以順利
就像三權分立一樣

不需要用專案管理的方式本來就可以做好一個專案
就像 CMMI 只要有能力接案子然後可以做完
都可以通過 CMMI Level 1

但如果要導 Level 2 就會要求專案組織的建立
其中就會提到,組織成員中兼任的問題
管理不可兼開發,
沒為什麼,因為專案組織的建立其目的就是要分工合作
互相監督,有監督有制度才能管理
一個管理的人也跑去作要被監督的工作,就會讓互相監督的機制崩潰,

您當然可以認為一個就可以做好一個專案
事實也是可以,但問題不是在做好一個專案
而是一個專案要怎可以監督
其監督不是繫乎一人
而是每一個人都可以透過這些監督的方式,了解專案進度

您的做法,我並沒有說不對
但在專案管理上您的專案是無法管理的

但那不代表對錯,畢竟一個人也可以做到好
只是就管理的角度來看,這樣子是無法監督的
而我們討論得是專案"管理",那當然不適合兼任...

再次強調,對能不能做好一個專案來說,要不要兼都沒差
反正能做好就好
但對管理來說,這專案是無法監督的
所以也沒什麼好管理的,如此而以

希望我解釋得清楚
不要再誤解我的話了

cphunterlin wrote:
Kenchu , 事情沒有決對的啦... Big Smile
會說偏頗是因為您..把話說死了...
每種 situation 都有的, 其實制度是制度、實作是實作 ....

其實有人說 , 為何我很欣賞一些日本的公司. 也欣賞鴻海的工程能力...
專案的管理、不一定是管理的人適不適合去兼任開發之類的...
誰有能力主導,他又願意去做,何不可為呢?

我們公司有很多一人 team ,就是 PM 兼工程師(like :股市頻道)
您說的對:球員不兼裁判 , 但軟體開發工作是場競賽嗎?

我個人覺得不是耶,是一場建築的工程....

您說客戶在意工作分配的部分? 我又更不了解了.
在我當PM 的時候, 我就白天談專案需求和做程式開發工作、Seminar等工作.
晚上去做 beta testing 和工作上 review 和再審核及文件的 check.

客戶對我兼PM、業務面和工程面沒啥不滿的呀 , 也這樣過了一大段的時間...
我不知道這違反了專案管理的常識耶..... *_*

可以向您請教嗎?


kenchu edited on 2007-05-04 16:18
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:kenchu]
ianhong





發文: 2
於 2007-05-04 16:19 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
讓我好奇的是, 如何讓小案子的經驗提昇到中型或大型的案子中使用? 還有小案子監督應該是什麼? 沒人管? 還是 資深的 監管? 誰又是資深?

kenchu wrote:
不敢

但試問

除了您之外,誰有能力監督本專案
對一間公司而言
專案成敗繫乎您一人身上
對一間公司而言,這是好的麻?
專案管理之所以要這樣要求
重點在於整個組織的運行得以順利
就算三權分立一樣

不需要用專案管理的方式本來就可以做好一個專案
就像 CMMI 只要有能力接案子然後可以做完
都可以通過 CMMI Level 1

但如果要導 Level 2 就會要求專案組織的建立
其中就會提到,組織成員中兼任的問題
管理不可兼開發,
沒為什麼,因為專案組織的建立其目的就是要分工合作
互相監督,有監督有制度才能管理
一個管理的人也跑去作要被監督的工作,就會讓互相監督的機制崩潰,

您當然可以認為一個就可以做好一個專案
事實也是可以,但問題不是在做好一個專案
而是一個專案要怎可以監督
其監督不是繫乎一人
而是每一個人都可以透過這些監督的方式,了解專案進度

您的做法,我並沒有說不對
但在專案管理上您的專案是無法管理的

但那不代表對錯,畢竟一個人也可以做到好
只是就管理的角度來看,這樣子是無法監督的
而我們討論得是專案"管理",那當然不適合兼任...

再次強調,對能不能做好一個專案來說,要不要兼都沒差
反正能做好就好
但對管理來說,這專案是無法監督的
所以也沒什麼好管理的,如此而以

希望我解釋得清楚
不要再誤解我的話了


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:kenchu]
yesteven





發文: 2
於 2007-05-04 16:26 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
To:Kenchu
所以你的表達方式真是令人費解.....
搞了半天你做過的專案也是一個人幹到底!?
一個人可以模擬成各個專案成員???
你不是說PM歸PM, Team Leader歸Team Leader嗎?

你自己舉的實例不正是之前singlelog, cphunter...一堆人的結論嗎?

所以你口頭上說的理論(也不知是哪本書上的理論,你也從不交待)
跟你實際做專案的方式,根本就是南轅北轍 & 剛好相反嘛!!

這是在搞笑嗎?

-the end-

kenchu wrote:
小弟雖不才,但我曾在因緣巧合下一個人模擬整個專案組織的成員
產出所有工作項目,而其產出物是客戶聘請資深顧問來監督
產出的工作項目,也是客戶付款的依據
其金額上億到上千萬都有
也是因為這個因緣
所以我了解整個專案組織的運作與工作責任
才有這些論述


reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:ianhong]
kenchu





發文: 128
於 2007-05-04 16:35 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
您提得是好幾個問題

第一
如何讓小案子的經驗提昇到中型或大型的案子中使用

專案管理其實依據專案大小可以伸縮的
人力也可以兼任的

例如有的顧問導入CMMI
有時會要求A工程師寫完的程式要給B工程師看
目標可能是為了互相 backup (萬一A掛了 還有B 可以幫忙)
也可以是互相監督 互相學習 ....等
反正就是要訂出要做某個目標,為了這個目標要做哪些,步驟有哪些,產出有哪些,方式是...CMMI 很囉嗦

但有時專案很小,根本就不需要做到這些
所以一個 level 5 的公司
可能會跟你說, 如果要用 5 要 1000萬 4 500萬 3 200萬 1 100萬
聽起來很詭異

但其實只是做多做少的問題
成熟度其實也就是跟你說 用 5 可以說是萬無一失拉(當然是理想)
用 1 可能就有點風險....諸如此類

所以大中小型的專案是可以調整工作項目的

第二
還有小案子監督應該是什麼? 沒人管? 還是 資深的 監管? 誰又是資深?

監督其實就是驗證而已
沒有驗證什麼
只有到底有哪些工作項目要做
那這些工作項目要怎驗證
如A工程師寫了一個XX功能
如何證明A工程師完成一個XX功能
那就要透過測試計畫中針對此功能的測試方式
測試結果如果跟預期一樣
那自然就可以說驗證通過
這裡的監督指的是正確的資料
有了正確得資料才能真正掌握進度、管理風險、分配資源
所以監督是非常重要的,其實也就是避免PM唬爛...進度亂寫、風險亂訂...
然後又沒人可以真正知道專案進度
直到交卷的一刻,才知道原來都是白的 ...
看看本討論串的問題
有多少都是因為監督制度沒有建立
但還是不建立,還是想依賴PM的技術能力
殊不知這反而是最大的風險所在 ..

如上

A工程師寫了一個XX功能
但是否代表完成了XX功能 ?

如果 A工程師 兼任 PM 或兼任 測試工程師
那基於人性本惡的邏輯下(<- 應該又要成為戰點了,不過這只是減低風險的處理方式而已)
旁人無法從測試結果中得知
XX功能是否真的完成
既然無法得知
自然也無法監督...

所以專案管理的監督重點就是工作項目
大中小專案也只能工作項目得多寡
做的少自然要監督的也少

以上...

ianhong wrote:
讓我好奇的是, 如何讓小案子的經驗提昇到中型或大型的案子中使用? 還有小案子監督應該是什麼? 沒人管? 還是 資深的 監管? 誰又是資深?


kenchu edited on 2007-05-04 17:12
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:yesteven]
kenchu





發文: 128
於 2007-05-04 16:44 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
沒什麼好搞笑的
正因為都我一個人做
我才知道為什麼要做這些
才了解前因與後果
才了解全盤

也才知道為什麼人家會要求這些東西的目的
與做這些管理的目的
就好像一個工程師 從需求 - 系統分析 - coding -測試 - 整合 - 封裝
都做到完,之後才真的了解整個軟體工程的來龍去脈一樣
這樣很搞笑嘛 ?

哪本書的交代喔....
我都亂看耶

反正 CMMI 要做的一堆
每一樣都像申論題
自己翻書找答案
反正有資深顧問再幫我閱卷

所以我也沒辦法給您交代...
對不起

yesteven wrote:
To:Kenchu
所以你的表達方式真是令人費解.....
搞了半天你做過的專案也是一個人幹到底!?
一個人可以模擬成各個專案成員???
你不是說PM歸PM, Team Leader歸Team Leader嗎?

你自己舉的實例不正是之前singlelog, cphunter...一堆人的結論嗎?

所以你口頭上說的理論(也不知是哪本書上的理論,你也從不交待)
跟你實際做專案的方式,根本就是南轅北轍 & 剛好相反嘛!!

這是在搞笑嗎?

-the end-


kenchu edited on 2007-05-04 17:00
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:chermanyen]
kenchu





發文: 128
於 2007-05-04 17:42 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我想我回答很多人的問題

那我想問請教一個問題

一個專案中,PM是否該被監督
如果是的話
那請教要怎監督PM
要怎知道PM所說的進度是真的
要怎知道PM的決策是對的
誰能監督PM,誰該監督PM
PM萬一中途掛了,要怎讓別人接替

我希望有人可以給我指教..


reply to postreply to post
(Total 33 pages)  
go to first page go to previous page  16   17   18   19   20   21   22   23   24   25   26  go to next page go to last page
» JWorld@TW »  交流、聊天、灌水

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8