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:chermanyen]
johnsoh

disney



發文: 456
於 2007-05-08 17:22 user profilesend a private message to usersend email to johnsohreply 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, 然後互相交換看, 大部分同事看的是字有沒有寫錯, 一字一字慢慢看, 但查不出來邏輯錯誤, 我看的重點是邏輯, 不管有沒寫錯字, 但可以很快看出問題, 這也沒對錯問題, 程式一樣在RUN.

開始帶兵後, 我也不強調要手下交什麼報告, 程式要如何如何, 但我會去了解使用者需求, 與設計人員溝通整體架構, 由他們自由發揮.

系統一有狀況後, 我會即時介入, 去追蹤程式是如何RUN的, 找出是哪邊邏輯錯誤或Data Error, 逕行修改, 然後開會或發出MEMO, 要求設計人員注意.

因為這樣的方式, 我底下的人員最後都逐漸有了獨擋一面的能力, 我也樂的輕鬆.

經常碰到的狀況是, 底下的人碰到狀況, 許久都無法解決, 交到我手上後, 我反而可以在短時間內找到答案或找出解決方法, 這讓本科系畢業的他們覺得很訝異, 我是如何做到的.

我想, 正因為我並沒有受過這方面正規的教育洗禮, 所以我的思考方式較為自由廣泛.

這樣的模式我與底下的人合作了10年了, 寫過好幾家工廠的管理系統, 中間系統平台, 程式語言 換過了很多次, 也都還運作順暢.

這是我的經驗, 對其他人而言可能並不適用. 但覺得沒必要去爭論這些問題, 個人有自己的模式, 做法, 一直都在運用中, 這樣就ok了, 要歸納是學校的需要.

EMBA的教授做出了很多歸納來解釋成功的商業模式, 可是照著抄就會成功嗎? 那今天的大老闆應該都是那些EMBA的教授.


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





發文: 128
於 2007-05-08 17:32 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
很多人都有這樣的想法

我必須說,您這樣想天經地義

但以公司的角度來看

這些管理是您在管理

以您的管理方式在管理

有您在,這樣的管理會成功

但當您不在呢 ? 您是否思考過如果您得這套管理辦法換成別人來執行還是可以像現在這樣嘛

所以我並不是要說誰專案管理的不對或不好

而是很希望大家可以思考,如何避免以人治的方式管理

盡量形成制度,不要人一旦換了,專案品質就變了...

我才會說做專案跟專案管理的差異

johnsoh wrote:
很奇怪的討論, 居然撐的這麼久.

我想問題在於歸納, 用自己所經歷過的事情去歸納, 試圖建立一個通用模式.

問題是, 一個事情的發生, 每個人會因其經驗不同, 所在角度不同, 做出完全不同的歸納, 據此來做結論, 可能每個人所得到的結果都會不同.

用不同歸納方式導出完全不同的結論, 這在現實生活中比比皆是(政治問題尤其如此), 據此來判斷對錯問題, 其結果都會是雞同鴨講, 再有同樣的事情發生, 用以前歸納的法則去應對就能解決嗎?

進入資訊界一開始我是接受這樣訓練的, 手工Coding, 然後互相交換看, 大部分同事看的是字有沒有寫錯, 一字一字慢慢看, 但查不出來邏輯錯誤, 我看的重點是邏輯, 不管有沒寫錯字, 但可以很快看出問題, 這也沒對錯問題, 程式一樣在RUN.

開始帶兵後, 我也不強調要手下交什麼報告, 程式要如何如何, 但我會去了解使用者需求, 與設計人員溝通整體架構, 由他們自由發揮.

系統一有狀況後, 我會即時介入, 去追蹤程式是如何RUN的, 找出是哪邊邏輯錯誤或Data Error, 逕行修改, 然後開會或發出MEMO, 要求設計人員注意.

因為這樣的方式, 我底下的人員最後都逐漸有了獨擋一面的能力, 我也樂的輕鬆.

經常碰到的狀況是, 底下的人碰到狀況, 許久都無法解決, 交到我手上後, 我反而可以在短時間內找到答案或找出解決方法, 這讓本科系畢業的他們覺得很訝異, 我是如何做到的.

我想, 正因為我並沒有受過這方面正規的教育洗禮, 所以我的思考方式較為自由廣泛.

這樣的模式我與底下的人合作了10年了, 寫過好幾家工廠的管理系統, 中間系統平台, 程式語言 換過了很多次, 也都還運作順暢.

這是我的經驗, 對其他人而言可能並不適用. 但覺得沒必要去爭論這些問題, 個人有自己的模式, 做法, 一直都在運用中, 這樣就ok了, 要歸納是學校的需要.

EMBA的教授做出了很多歸納來解釋成功的商業模式, 可是照著抄就會成功嗎? 那今天的大老闆應該都是那些EMBA的教授.


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





發文: 209
於 2007-05-08 17:47 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是不是在一家規模極大的公司歷練阿
不像版上不少人都是在那種中小企業下工作(常常都是小貓兩三隻去做專案)
才會覺得PM根本不需要去管理(或是說是面對溝通)工程師
只要跟各團隊的領導溝通無礙就好了

也許kenchu和獨孤木等人都讀過同樣的技術書籍
可是經歷不同,解讀方式就有落差

寫這裡又想要問,上次問說台灣沒這種公司
那外國總有這種理想模式的公司吧?像IBM?
請哪位有歷練過外國大公司的朋友說說看吧

ps:可是不要把某些語病擴大解釋來打啦,獨孤木不也是同意要建立可長久的制度


reply to postreply to post
One day,a girl appeared before the boy suddenly.
She said that it was an "angel" about herself.
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:chermanyen]
luandjack





發文: 45
於 2007-05-08 17:50 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:
我一直說,不一定需要技術才能當PM管好專案
不一定不代表一定不要懂技術


小弟在想,不知道以上這一段kenchu大大的文字,算不算是大家的共識之一呢??


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

換回來



發文: 416
於 2007-05-08 17:50 user profilesend a private message to usersend email to singlelogreply 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:
既然大家要列出書目

那我懇請 獨孤木 (應該沒打錯吧)

列出您看的專案管理的書 (不是軟體管理喔)

其章節與頁碼 ,來反駁我的專案管理理論

也請您列出

哪本專案管理的書

提到PM必須要有技術才有能力分配資源

提到不需要計畫,也可以"管理"專案

然後看看哪本說不是提到專案的工作項目為專案的基本

其管理都不是再針對工作項目

請列出書目 章節與頁碼

請其他冷嘲熱諷的人 也一併提出吧

小弟懇請賜教

請務必要回我

讓我知道我書讀得少,好多看點書

拜託...


我有說不用計畫就可以管理嗎?我每次講一句話,都會被人拿去亂扯。

你指的這些事都是trivial。就像是為了要嘿咻,你會去買保險套,會去買花束,會吃燭光晚餐。你心裡面想的就是要score,可是前面這些該做的還是要做。可是重點就是在嘿咻。

你要我舉,tom demarco 最後期限,中文版46頁,自己看。

我每次講專案管理不是就寫plan這件事而已,然後你都要解釋成不需要計畫,也可以"管理"專案,這不是扣帽子,抹黑,要怎麼解釋?我不願意對你的動機做揣測,那就只能猜你看不懂別人在問什麼。


singlelog edited on 2007-05-08 18:20
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:chermanyen]
johnsoh

disney



發文: 456
於 2007-05-08 17:53 user profilesend a private message to usersend email to johnsohreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
資訊科技變化快速, 如何避免人治, 似乎是不可能的.

以前Cobol擁有全事件85%的市場, 現在一些老系統要做一些些微的修改, 都很困難, 因為老設計師退休了, 小伙子沒看過, 讓他們看當初的規劃資料就可以做出來嗎? 省省吧.

現在偶而會看到一些DOS系統, 一當掉小伙子就沒輒了, 要他從config.sys開始學起, 算了吧.

不管有沒有文件, 重點是平穩過度, 公司要未雨綢繆, 準備下一代資訊系統要如何發展, 要培育新人, 這樣才有人接手.

我不是說我的手下都有了獨擋一面的能力, 我現在回台灣了, 他們還是在運作, 沒有垮掉.

我以前的一個公司, 把工廠遷移到大陸後, 所有文件 圖檔都搬過去, 然後就把台灣RD解散了, 結果您可以用腳去想看看.
我離開該公司時, 程式大部分都完成了, 系統運作都是ok的, 後來該廠老總自己開工廠, 把一大票管理人員挖走, 系統還在, 只不過新任老總只有看損益表, 平常所有程式全部停擺.
後來在舊老總的要請下, 我到新工廠, 用新的平台, 新的程式語言, 重新建立整個管理系統, 現在已完成95%.

重點是人才培育, 不做人才培育, 有沒文件都是一樣完蛋.


johnsoh edited on 2007-05-08 18:02
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:luandjack]
singlelog

換回來



發文: 416
於 2007-05-08 18:27 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
luandjack wrote:

kenchu wrote:
我一直說,不一定需要技術才能當PM管好專案
不一定不代表一定不要懂技術


小弟在想,不知道以上這一段kenchu大大的文字,算不算是大家的共識之一呢??

一開始是:
我會認為一個PM根本不需要了解技術,只要會專案管理就好

有技術當然也好,但做專案管理時反而應拋棄自己對技術看法

後來是:
我堅持的是PM懂不懂技術都可以做好專案管理

現在是:
我一直說,不一定需要技術才能當PM管好專案
不一定不代表一定不要懂技術


我的說法一直都是,懂技術會對做PM的工作有很大的好處,所以PM 應該要懂技術,這會比較好。

那現在到底是怎麼樣?到底是不是懂技術比較好?老實說,如果還要再扯什麼軟體管理的那一大塊,我就沒興趣討論了。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:singlelog]
kenchu





發文: 128
於 2007-05-08 18:39 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 當然不是專案管理
就像ISO 一樣
那只是個認證
就像SCJP一樣

通過 ISO XXX 就代表達到那個規範
CMMI 就像軟體業的 ISO
因為軟體品質參差不齊,所以導致很多軟體專案失敗
有鑑於軟體開發得特性所以另外推了CMMI
主要就是透過很多目標方法來驗證成熟度
所以每一個階段有很多得目標要達到
CMMI 會列出目標,要怎做隨你,只要能達到目標就好
其方法可以根據公司的情況與性質改變
所以書中的方法可以當作參考,不會有一本書可以完全適合

因為CMMI 其實是驗證公司成熟度的方法
其目的就是要讓開發的產品(不一定是軟體),品質可以掌握
所以其中很多目標方法都是在做專案管理,管理專案品質

所以CMMI當然不是專案管理的書
但卻是驗證專案管理品質的方法之一
所以其目標做法會要求很完整得專案管理

以下您的指教
====
"如果一直有人就把它當做這就是專案管理,其實還是有點那種白馬非馬的感覺。 "
===

我只能說,真得多看書,會有不同見解

singlelog wrote:
CMMI不是專案管理的全部。從名字就可以看出來,它不是叫做專案管理聖經。而是叫做capability maturity model integration。

如果一直有人就把它當做這就是專案管理,其實還是有點那種白馬非馬的感覺。

tom demarco 在最後期限的13章裡面有提到一個例子,有興趣的人可以去看看。


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

換回來



發文: 416
於 2007-05-08 18:44 user profilesend a private message to usersend email to singlelogreply 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懂技術,前面已經解釋過很多次,不是技術能力要最強,eriklin 和我也舉例來問,當角色不同時,每個人提出來的建議可能會有不足的地方,PM應該要自己判斷怎麼做比較好。

這種說明有說一定要top嗎?事實上我們只要對系統的運作也好,開發流程也好,有一定的理解,搭配經驗,就比較容易做決策。

我們不是要領導開發,而是做決策。特別是那種資源有限的情況下,你要怎麼要做出正確的決策。

專案管理確實是在有限的資源下,把事情做好。求的是在resource/ time/ quality /scope之間可以達成你要的結果。(這我也寫過呀)

可是軟體專案管理,為什麼會跟一般的專案管理不一樣,就是因為很多東西彼此之間的關係並不是線性的。(這我也寫過呀)

託kenchu的福,我最近把溫伯格的書從頭到尾看一遍,像是剛才那段關於線性關係的描述,沒看過書還真寫不出來。

所以,我不認為,單單看專案管理的書,可以解決軟體專案的管理問題,因為會有很多地方,會有很大的不一樣。

光是講說只要把它切成工作項目,就可以管理,就可以怎麼樣怎麼樣,這就純嘴砲了啦。反正人人都可以講這種話。要的話,舉歐美大公司的實例出來。

magicfish,

歐美大公司會用技術能力不好的PM嗎?還是說會用技術能力不錯,專案管理能力也很好的PM?你有聽過Google用個不懂技術的人去當PM嗎?Micosoft?Oracle?IBM?這用卡頭夫就可以想的出來。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:singlelog]
kenchu





發文: 128
於 2007-05-08 18:45 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就沒能力決策

專案不能做決策,這樣只是比較好的差異 ?

這是能不能完成專案的問題吧

您的文章都在

請自己看

singlelog wrote:
一開始是:
我會認為一個PM根本不需要了解技術,只要會專案管理就好

有技術當然也好,但做專案管理時反而應拋棄自己對技術看法

後來是:
我堅持的是PM懂不懂技術都可以做好專案管理

現在是:
我一直說,不一定需要技術才能當PM管好專案
不一定不代表一定不要懂技術


我的說法一直都是,懂技術會對做PM的工作有很大的好處,所以PM 應該要懂技術,這會比較好。

那現在到底是怎麼樣?到底是不是懂技術比較好?老實說,如果還要再扯什麼軟體管理的那一大塊,我就沒興趣討論了。


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





發文: 45
於 2007-05-08 18: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
小弟認為,PM對於判斷的主客觀是個人的想法特質,這是可以籍由專業訓練或是經驗累蹟來改變的,其實與PM懂不懂技術應該是無關。

其實排除了PM的主客觀判斷的問題,其實PM還是懂點技術是比較有利於專案的


luandjack edited on 2007-05-08 23:25
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:chermanyen]
singlelog

換回來



發文: 416
於 2007-05-08 18:51 user profilesend a private message to usersend email to singlelogreply 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有寫說找個不懂技術的人來當PM比較好,就翻出來講說是那個地方有這樣寫。看看是在哪一個process area,哪個specific and generic goals有提到。

我其實也很懶得再講了。只能說,下士聞道大笑之。潛水去。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:chermanyen]
kenchu





發文: 128
於 2007-05-08 22: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
要批評我前,請務必先看過以下,我針對我所說的做以下的說明

我將專案經理(PM)的工作定為在專案管理,
其工作內容為工作項目的擬定、資源的分配,因為有了要做的事與有限的資源
所以PM才要針對這些工作項目進行管理。

因為要管理,所以必須讓專案變成可以管理,因此專案將分成各個專案組織,其職掌不一樣,工作內容也不一樣,其目的在於分工合作與互相監督。

以下我以軟體開發專案作為專案內容

軟體開發專案,為了要可以管理,所以至少應該要有管理單位、開發單位、監督與驗證單位。

管理單位負責軟體專案工作項目的管理(工作項目的擬定、資源的分配、風險處理…等),開發單位負責軟體開發(也就是工作項目中的軟體開發的工作項目),再透過監督與驗證單位做為工作項目是否落實的監督單位,為此很多軟體專案會區分成

專案管理組
專案開發組
品質保證組
構型管理組
測試工程組
後勤支援組

其每個組織都有其工作項目要做,運作方式與產出物等定義在專案計畫中
其中各位最質疑的是專案管理組與專案開發組,
專案管理組做的是擬定專案開發組的工作項目,如要求開發組做需求分析,需求分析要產出什麼,有哪些資源可用,需求要做追溯,需求要可以驗證,說明工作項目後就交由專案開發組執行,所以PM對技術不需要插手,但要知道軟體開發要做哪些工作項目(這個才是PM要懂得重點,因為軟體開發專案中開發組所做的工作項目,跟系統開發專案就會不同,系統開發專案會有系統鑑定測試,軟體開發專案則沒有,大專案可能要做到很完整的測試,小專案可能不需要做太多的測試,因此專案大小差異都只有在工作項目的多寡而以<-所以這種專案管理不是只適合大專案,訂出可以完成專案的工作項目與方法才是PM的最重要工作,也就是專案計畫)。
因為專案管理組是擬定專案工作的人,而工作項目中的生產(軟體開發專案就是指軟體開發)都是有開發組去做得,所以必須要可以掌握進度,但其進度的正確性則是交由品質保證組來驗證,軟體開發組的東西會交由測試工程的人去做測試(就是產出物的測試),其測試結果才是功能是否完成的依據,而其測試的正確性與是否落實則是交由品質保證組做監督,因此專案管理的人員不應該兼職作專案開發、或品質保證目的就是要確保這些監督的機制得以運行。就監督的角度來看,軟體開發的驗證在測試,測試的真實與落實會由品質保證組監督,專案計畫的執行正確性也會是品質保證監督範圍,所以品質保證組通常會將報告公開給其他高階長官看,以避免專案進度做假的風險。

所以其專案組織的運行,是將工作分離,PM不需插手管理技術,而是因了解整個軟體開發專案所需要做的工作項目,並掌握軟體開發組執行工作項目的進行。
因此專案經理對技術的依賴度不高,反而是其專業領域要懂,如系統建置案有哪些工作項目,軟體開發案有哪些工作項目,大的系統建置要有哪些工作項目、小的系統建置案有哪些工作項目,要正確的擬定,並且在擬定的工作項目時要取的其他組織成員的共識,以方便專案進行。

以上這樣做專案的目的在於

專案真正可以管理,也可以監督
不會必須依賴專案經理一人
也可以累積專案經驗,將其變成公司資源
專案可以監督才能掌握品質,才可以做到同一家公司做的專案品質都差不多
不會變成超強能力的PM品質一級棒,不怎樣的PM品質普普通通甚至很差…
對公司而言依賴PM能力而決定專案品質是件危險的事
所以才會讓管理的做管理,技術的做技術、監督單位做監督
很多的規範會要求以這樣的方式進行專案管理
不是我個人要求的,而是規範要求的(CMMI , MIL-STD-498 )
因為這樣專案品質才有能力監督,才不會品質參差不齊
反過來看,如果各位是客戶
會希望一個專案的成敗都繫乎PM的能力(包含管人的能力)上嗎?
還是希望該公司的專案品質是透過制度來管理的
以客戶的立場來看,自然就會知道這些規範為什麼要這樣訂
就是要以專案組織與制度來做專案管理,讓專案品質可以監督,而不是以PM個人能力決定品質與專案成敗。

要怎做到以上? 答案大家可以自己思考看看
如果不能把專案管理與專案開發兩個拆開,一直要讓兩個混在一起,那專案進度要怎真正與正確得監督?

如果有拆開了,PM做專案管理、開發組做專案開發,測試單位做測試、監督單位做監督,有了專案組織,專案制度才得以運轉,才得真正落實專案管理。

以上的情況下,PM懂不懂技術其實已經不是必要了,我想我一直都是這樣去做論述的

文章很長,雖然我想寫得更詳細,不過實在太長了,所以我有縮減。

我希望大家可以真的看完我寫的,再來批評我

我很虛心的受教


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





發文: 128
於 2007-05-08 22:10 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來說專案管理,是 馬都是白馬
我只能說就好像我用軟體工程的規範去說明需求分析怎做的時候
您質疑我軟體工程不是需求分析一樣的讓我不知道怎回答

真要討論CMMI
歡迎再開一個主題
看看CMMI 中對專案管理要求的目標方法,是不是非常完整
夠不夠做為專案管理的依據...

最好是連軟體開發都開一個主題
不要說專案管理、CMMI ,就算是軟體開發,我都可以跟您討論

既然您說我在打嘴砲
那我希望您不要讓我覺得,真的在打嘴砲的人不是我
反而是傻傻分不清楚什麼是軟體管理什麼叫做專案管理的人

歡迎您開以上任一個主題來討論
小弟虛心受教

singlelog wrote:
有些人就是以為他在苦讀cmmi時,別人都沒看過cmmi教科書在寫什麼。

要是cmmi有寫說找個不懂技術的人來當PM比較好,就翻出來講說是那個地方有這樣寫。看看是在哪一個process area,哪個specific and generic goals有提到。

我其實也很懶得再講了。只能說,下士聞道大笑之。潛水去。


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





發文: 161
於 2007-05-08 22: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
我看這樣再討論下去就會變成辯論會,大家火氣也都冒上來了
建議版主鎖文,避免擴大衝突


reply to postreply to post
電腦是害人的工具,但是上帝卻可以藉著它行奇妙的大能
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:kenchu]
yesteven





發文: 2
於 2007-05-08 22:38 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
嗯嗯....看完了

還是一樣的老問題:
這些論點,你是研讀哪些專案管理書籍分析後得來的?

不要老是踢皮球,先說要多看點書的是你,所以我認為
你有義務先說明。

-the end-

kenchu wrote:
要批評我前,請務必先看過以下,我針對我所說的做以下的說明

我將專案經理(PM)的工作定為在專案管理,
其工作內容為工作項目的擬定、資源的分配,因為有了要做的事與有限的資源
所以PM才要針對這些工作項目進行管理。

因為要管理,所以必須讓專案變成可以管理,因此專案將分成各個專案組織,其職掌不一樣,工作內容也不一樣,其目的在於分工合作與互相監督。

以下我以軟體開發專案作為專案內容

軟體開發專案,為了要可以管理,所以至少應該要有管理單位、開發單位、監督與驗證單位。

管理單位負責軟體專案工作項目的管理(工作項目的擬定、資源的分配、風險處理…等),開發單位負責軟體開發(也就是工作項目中的軟體開發的工作項目),再透過監督與驗證單位做為工作項目是否落實的監督單位,為此很多軟體專案會區分成

專案管理組
專案開發組
品質保證組
構型管理組
測試工程組
後勤支援組

....(下略)


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





發文: 128
於 2007-05-08 22:39 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不需要技術也能做好專案,只要建立好專案制度與組織

如果是,那請說我打嘴砲的人可以跟我道歉
不然真的覺得欠我個公道

老陳 wrote:
我看這樣再討論下去就會變成辯論會,大家火氣也都冒上來了
建議版主鎖文,避免擴大衝突


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

換回來



發文: 416
於 2007-05-08 22:47 user profilesend a private message to usersend email to singlelogreply 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的說法不感興趣,因為一天到晚要我務必看的東西都一樣,卻又回答不出什麼道理來。人家問了問題,不回答,一直拿同樣的東西去copy paste。我最少舉了N個不同的比喻與問題。

不管人家怎麼諷刺他,他都可以依然故我,不管人家怎麼質疑他,他都可以忽略所有的問題,然後只講他自己的那一套。我必需這樣說,這種毅力與韌性我很少看見,連我這個自認為很耐幹的人都只能甘拜下風了。

我在這個 thread裡面,不曉得是第幾次看到他用一模一樣的話來回答所有的人的問題了。本來剛剛已經做了整理,沒想到又再用robot打一次給我們看。

我個人才疏學淺,沒辦法理解專案計劃的微言大義,也搞不懂,為什麼看到同樣的胡扯100次我就會懶得再回應了。我決定就此罷手,在這個thread裡面,不再針對kenchu任何發言再次進行回應。

感謝各位的耐心與忍讓,我要潛水了。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:chermanyen]
poshoung





發文: 51
於 2007-05-08 22: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
唉啊,後面火藥味越來越重了

站在中間半潛水,感覺的應可以一句話來解釋雙方的歧異

請問kenchu 前輩,如果讓您挑PM,假設專案管理的能力都相同的前提下

PM懂一點點技術多多少少在無形中是可以幫助到他一些忙的,至少在追殺

各組的milestone之餘可以與工程師聊聊天促進專案小組革命情感之類的。

if true

那我真的覺得雙方只是文字上的誤解跟火氣上來而已,也許雙方

都該退一步喝杯涼茶。

而獨孤木前輩用字遣詞慣於語帶詼諧,也許看在某些太認真看文的人眼裡

可能會覺得話中帶刺。

所以我真的覺得只是語言的誤會吧。也許觀念不盡相同,老實說建立起

kenchu 說的管理制度比較好?還是獨孤木前輩說的比較好?

管理這門學問真的能有定論嗎?我想是否定的

如美式管理跟日式管理風格上有些根本是相悖持的,但是各自都有成功的一片天地

我只信老闆應該只信奉的唯一真理:show me the money Smile take it easy


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





發文: 128
於 2007-05-08 22:51 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
ok

以下是 MIL-STD-498 對專案計畫的要求
目錄其實都是工作項目
這些就是人家美國國防部要求外包專案的公司
要做的工作項目
要列出的計畫

這些就是人家對計畫書得規範
這些都是題目
自己去找書來看,
哪些書

所有專案管理的書跟軟體工程得書
可以幫助您來落實這些得書
都是您參考的書目
也是我所參考的書目

以下目錄
都是軟體開發得工作項目
裡面其實是用專案管理的方式來管理軟體開發,以軟體工程來開發軟體...

4,5 章的工作項目都是軟體工程
6,7 則是專案組織跟時程規畫

整篇計畫要可以執行
每一個工作項目要可以監督
客戶會派人檢查每一個工作項目是否按照計畫
是否真的有執行,資料是否正確
所以客戶有能力在專案進行中監督專案品質是否如預期
而不是在專案開發完成後看到成品後才知道問題所在
那時已經來不及了

但因為 498 的規範會變成客戶要有能力看懂這些東西
所以反而會產生很多問題,才會又衍生出CMMI
以CMMI組織來驗證其專案承包公司的CMMI LEVEL
以解決 498 需要客戶有能力監督的問題
因此 CMMI 為什麼叫做成熟度...
原因在這裡....
其實就是專案開發的品質成熟度
因此CMMI對專案管理的要求很嚴謹
提升一個Level,要求的會更嚴僅
其實就是工作項目訂的更多更嚴僅
雖然可靠度增加所以成本也會增加
才會有 如果A專案要求 Level 5 是 1000萬 Level 3 是500萬的現象
因為工作項目的要求多寡....

不管是導CMMI 或 498 都是這樣要求專案管理....
如果專案管理組織去做專案開發或者品質保證的工作
第一個就不會過,就被打槍了
就會面臨人家質疑這樣兼任,專案無法監督的情況與風險

專案組織會提到
專案組織的工作,
專案組織如何互相監督(專案監督)
會提到專案開發跟管理兼任時的風險
這些都是整個目標能不能達成的重點
我已經幫各位整理了...坦白說,這些都是精華了...

算了,沒真得被要求用這些規範做專案
不懂也沒什麼好奇怪的

如果真還要質疑我是看哪本書...
我真得很無奈

這些其實都是很基本得專案管理得理論..

1. 範圍 5
1.1. 識別 5
1.2. 系統綜觀 5
1.3. 文件綜觀 7
1.4. 與其他計畫書的關係 8
2. 參考文件 9
3. 需求工作綜觀 10
4. 執行一般系統開發工作項目的計劃 11
4.1. 系統開發過程 11
4.2. 系統開發的一般計劃 11
4.2.1. 系統開發方法 11
4.2.2. 系統產品的標準 11
4.2.3. 可再用軟體產品 12
4.2.3.1. 納入可再用軟體產品 12
4.2.3.2. 開發可再用軟體產品 12
4.2.4. 關鍵性需求的處理 12
4.2.4.1. 安全性保證 12
4.2.4.2. 保密性保證 12
4.2.4.3. 私密性保證 13
4.2.4.4. 其他關鍵性需求之保證 13
4.2.5. 電腦硬體資源利用 13
4.2.6. 記錄原則 14
4.2.7. 籌獲者審查之途徑 15
5. 執行細部系統開發工作項目的計劃 16
5.1. 專案規劃與監督 16
5.1.1. 系統開發規劃 16
5.1.2. CSCI測試規劃 17
5.1.3. 系統測試規劃 17
5.1.4. 系統安裝規劃 17
5.1.5. 系統移轉規劃 17
5.1.6. 後續更新的計畫書 17
5.2. 建立系統開發環境 18
5.2.1. 系統工程環境 18
5.2.2. 系統測試環境 19
5.2.3. 軟體開發程式館 20
5.2.4. 軟體開發檔案 20
5.2.5. 非交付軟體 20
5.3. 需求分析 21
5.3.1. 使用者輸入分析 21
5.3.2. 作業構想 21
5.3.3. 系統需求 22
5.4. 系統設計 23
5.4.1. 系統層面設計決策 23
5.4.2. 系統架構設計 23
5.4.3. 系統細部設計 24
5.5. 軟體製作與單元測試 24
5.5.1. 軟體製作 24
5.5.2. 單元測試之準備 24
5.5.3. 執行單元測試 24
5.5.4. 修訂與再測試 25
5.5.5. 分析並記錄單元測試結果 25
5.6. 整合與測試 26
5.6.1. 整合與測試之準備 26
5.6.2. 執行整合與測試 26
5.6.3. 修訂與再測試 26
5.6.4. 分析並記錄整合與測試結果 26
5.7. 系統鑑定測試 27
5.7.1. 系統鑑定測試之獨立性 27
5.7.2. 標的電腦系統上之測試 27
5.7.3. 系統鑑定測試之準備 27
5.7.4. 系統鑑定測試之預演 27
5.7.5. 執行系統鑑定測試 27
5.7.6. 修訂與再測試 27
5.7.7. 分析並記錄系統鑑定測試結果 28
5.8. 接收測試 28
5.8.1. 抽樣或展示 28
5.8.2. 提供測試報告 28
5.8.3. 燒機測試 28
5.9. 系統使用之準備 28
5.9.1. 準備可執行軟體 28
5.9.2. 準備使用地點之版本說明 28
5.9.3. 準備使用手冊 29
5.9.3.1. 軟體使用者手冊 29
5.9.3.3. 軟體中心操作人員手冊 29
5.9.3.4. 電腦操作手冊 29
5.9.4. 安裝於使用地點 29
5.10. 系統移轉之準備 30
5.10.1. 準備可執行系統 30
5.10.2. 準備原始程式檔 30
5.10.3. 準備支援地點之版本說明書 30
5.10.4. 準備「既建」(as-built)之系統設計與相關資訊 30
5.10.5. 更新系統設計說明書 30
5.10.6. 準備支援手冊 31
5.10.6.1. 電腦編碼手冊 31
5.10.6.2. 韌體支援手冊 31
5.10.7. 移轉至指定之支援地點 31
5.11. 構型管理 32
5.11.1. 構型識別 32
5.11.2構型管制 32
5.11.3. 構型狀況記錄 32
5.11.4. 構型稽核 32
5.11.5. 包裝、儲存、處理及交付 33
5.12. 系統產品評估 34
5.12.1. 製程中與最終產品評估 34
5.12.2. 系統產品評估記錄 34
5.12.3. 產品評估之獨立性 34
5.13. 品質保證 35
5.13.1. 品質保證評估 35
5.13.2. 品質保證記錄 35
5.13.3. 品質保證之獨立性 35
5.14. 矯正行動 36
5.14.1. 問題/變更報告 36
5.14.2. 矯正機制 36
5.15. 聯合技術與管理審查 37
5.15.1. 聯合技術審查 37
5.15.2. 聯合管理審查 37
5.16. 其他工作項目 38
5.16.1. 風險管理 38
5.16.2. 管理指標 39
5.16.3. 保密與私密 39
5.16.4. 分包商管理 39
5.16.5. 獨立確認與驗證機構之介面 39
5.16.6. 與協同開發者之協調 39
5.16.7. 專案過程之改良 40
5.16.8. 在本計畫書中未被涵蓋的其他工作項目 40
5.16.8.1. 操作手冊 40
5.16.8.2. 系統維護及操作使用手冊 40
5.16.8.3. 教育訓練計畫書 40
6. 時程表與活動網絡 41
7. 專案組織及資源 42
7.1. 專案組織 42
7.2. 專案資源 42

yesteven wrote:
嗯嗯....看完了

還是一樣的老問題:
這些論點,你是研讀哪些專案管理書籍分析後得來的?

不要老是踢皮球,先說要多看點書的是你,所以我認為
你有義務先說明。

-the end-


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





發文: 2
於 2007-05-08 23:05 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
hey, singlelog, 這樣就要潛水了哦....有點可惜.

這一串看了下來,在我腦海中最印象深刻,一直浮現的畫面
就是 "紙上談兵" 這個成語中的長平之戰。

所以我就上維基查了一下 "趙括" ,他老人家逞強出兵,最後
硬著頭皮嘗試突圍,結果被秦軍弓箭手一射斃命,連帶害得
40萬趙卒被坑。

所以不是我愛吐嘈,而是"Manager"真的很重要,不要太天真
誤人誤己,希望kenchu能體會。

-the end-

singlelog wrote:
唉,算了,我自爆。

我對軟體管理與專案管理的分別沒興趣。講了再多,我們問了再多問題,到最後還在扯這個。
...(中略)

感謝各位的耐心與忍讓,我要潛水了。


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





發文: 128
於 2007-05-08 23:12 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的重點

說什麼工程師也有情緒

要管好工程師

才能做好專案

40萬的大軍

PM要怎每一個都管到

管理就是要透過制度去做

要有能力掌握、監督、執行

要訂一套制度使40萬大軍可以有所依循

不是在那邊因人而異的管理

因PM 而異的管理

在那邊PM要懂技術才能管好工程師...

管好工程師才能做好專案 ....

這樣叫做管理?

哀 ....

誤人誤己 ?

請務必先搞懂管理

再來說這句話

整天要求PM要有技術能力

讓PM去做軟體開發的工作

卻不去了解什麼叫做專案管理

傻傻分不清楚

導致專案完全無法掌握

才真的叫誤人誤己

yesteven wrote:
hey, singlelog, 這樣就要潛水了哦....有點可惜.

這一串看了下來,在我腦海中最印象深刻,一直浮現的畫面
就是 "紙上談兵" 這個成語中的長平之戰。

所以我就上維基查了一下 "趙括" ,他老人家逞強出兵,最後
硬著頭皮嘗試突圍,結果被秦軍弓箭手一射斃命,連帶害得
40萬趙卒被坑。

所以不是我愛吐嘈,而是"Manager"真的很重要,不要太天真
誤人誤己,希望kenchu能體會。

-the end-


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





發文: 2
於 2007-05-08 23:18 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
浮上來換個氣....

我終於瞭解「最後期限」第二章那位愛德加.卡布福斯在現實生活長什麼樣子了,我的感覺和第 24 頁裡所描述的完全一模一樣。

不想再說了,免得被解讀成冷嘲熱諷...繼續潛...


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





發文: 2
於 2007-05-08 23:18 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,你提的這些不是專案管理書籍,好不好?
這個叫作workbook, 工作手冊,是人家案主要求的
output產出物。

我也想潛水了.....

-the end-

kenchu wrote:
ok

以下是 MIL-STD-498 對專案計畫的要求
目錄其實都是工作項目
這些就是人家美國國防部要求外包專案的公司
要做的工作項目
要列出的計畫

這些就是人家對計畫書得規範
這些都是題目
自己去找書來看,
哪些書

所有專案管理的書跟軟體工程得書
可以幫助您來落實這些得書
都是您參考的書目
也是我所參考的書目

以下目錄
............(下略)


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





發文: 128
於 2007-05-08 23:22 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
那個是人家要求我們
承接這專案就要有這些專案管理的能力
透過計畫看我們公司得專案管理方式
這些是驗證我們公司有沒有能力做專案管理的依據
寫了計畫是要驗證的
人家依據計畫付錢的

請務必了解

thx

yesteven wrote:
kenchu,你提的這些不是專案管理書籍,好不好?
這個叫作workbook, 工作手冊,是人家案主要求的
output產出物。

我也想潛水了.....

-the end-


reply to postreply to post
(Total 33 pages)  
go to first page go to previous page  20   21   22   23   24   25   26   27   28   29   30  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