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

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

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友   
reply to topicthreaded modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
singlelog

換回來



發文: 416
於 2007-01-16 10:30 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要怎麼樣落實,就可以讓這個系統沒問題?Big Smile

我其實沒有說過,沒有經驗就沒辦法定義需求。需求是你要解決的問題。你總有一個問題想解決才會去設計一套系統。

沒有經驗時,你的設計可能是爛的,你的系統架構可能是爛的,至於需求,總不能說沒經驗就沒需求。比如說一個少男想要交女朋友,這是一個需求。可是他沒經驗,所以把妹方法上可能比較遜。會有可以改善的空間。

不過我覺得,沒經驗時,你的需求可能會有不對的地方。比如說年輕時都是以上幾壘來當做目標。都進本壘了,打出全壘打之後要做啥,這要是想不太出來,那就會分手了。所以需求其實也要不斷改版。有可能到最後就變成不要因為爬過一棵樹就放棄一座森林。

這也是為什麼,我覺得對一個不是很有概念全新的系統來說,iterative的方式有他優秀的地方。你就是要死第一次,然後修正一次,再死第二次,再修正一次。這樣不斷地修正下去。不管是架構、設計,或是需求。

剛剛問我在神通裡面的朋友。嗯,這就有趣了。

高鐵的案子還是去申請cmmi level 3的案子咧。高鐵的某位高層,擁有豐富的航空業訂票經驗。所以requirement就是個四不像。重複劃位搞不好一開始就是個被寫進去的需求。然後因為高鐵的人也沒經驗,神通的人也沒經驗,所以需求不斷改變。人員也折損的很快。已經換過好幾輪了。

高鐵公司裡面沒有什麼資深的tester,測試是找工讀生來測的。所以我想什麼stress test這種的就不要強求了。兩邊都沒經驗。所以出問題好像是必然的結果。

我猜,剛好又遇到執政黨一定要讓他過。要不然選舉就很難選了。所以大家都是硬逼著QA要他們簽字上線。或者虎頭蛇尾地弄一弄。唉,軟體公司常常為了要拿錢,所以內部測試沒弄好,就會硬要進UAT,甚至硬要上線。其實到最後要付出的代價,都會高的不像話。


singlelog edited on 2007-01-16 10:35
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:高鐵,ETC原來都是同一家做的... [Re:singlelog]
kenchu





發文: 128
於 2007-01-16 11:30 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
對軟體工程而言
只有要求需求要定義清楚,要可以驗證(驗證規格符合需求,而不是驗證需求對不對),要可以追溯。

所以錯誤的需求將導致系統錯誤 這是軟體工程

而軟體工程的專案管理,會有一連串的分析現行作業方式的要求(需求的驗證,這裡就是要作需求的驗證了),
針對設計會造成系統與現行作業的差異分析,(包含操作習慣、組織變更、環境變更)
針對這些變更要提出風險管理,如人員都不懂資訊要如何教育訓練
因應資訊化所以部門組織要變動,環境變更(如多一個機房,配線)
還有操作方式的不同造成與現行作業的不同....
以下不詳敘

根據現行的作業方式,在加上系統的分析,可以得知系統設計後會有哪些與現行不同

針對訂票系統,現行作業是什麼?我不相信高鐵真的沒顧問,讓X通分析高鐵的現行作業方式(顧問就是要知道這些,不然就不要當顧問了)
然後針對這些現行作業 了解系統差異性 ,並透過協調等方式與客戶取得共識
之後將這些協調內容轉換成需求,並提供需求驗證也就是指需求確實來自客戶而非憑空想像。
我敢說如果落實這些就不會發生設計與需求不同
沒落實就是根本沒做這些事,只一昧的聽資深工程師(照你的說法)的話
根本就不出門在家自己定義需求就要求工程師照這做了
產生今天的錯誤

CMMI 對這些非常的嚴謹
這些都是CMMI 2 的重點
更不要說CMMI對系統面的設計要求
比這些更嚴謹...
但錯誤的需求,再嚴謹的系統都沒用因為都是錯的

最後簡單來說,CMMI 包含了專案管理與軟體工程
這些步驟 清清楚楚定義在CMMI 的規範裡
所以CMMI 能不能解決這個問題 ?

CMMI 不能解決的是 作事得態度跟人治的公司

我之所有說 CMMI 本來就是要來處理這些問題,也是基於此
只是在台灣這些複雜的事根本沒人願意做
老闆要的CMMI 是專案入場卷 是卡死小公司的規定

我敢說 那怕今天X通都臭了
還是一樣可以接大案子
然後不會記取教訓
一再錯誤發生
為什麼...因為那些高層根本就不在意這些
只要最後能接到案子 才是重點
作爛就做爛 怕什麼

最後如果我們還是一直習慣人治而非制度
CMMI 已經是多人經驗累積
如果我們還是覺得這些都沒有用
要有超強能力的工程師,才是所有問題解決之道
並選擇性的去遵守CMMI的規定,或者根本只是拿來當神主牌
那台灣軟體業將不會有成長的一天...
說句實話 外國CMMI的顧問根本也不管你有沒有真的落實
只要給錢就好,反正搞爛了也不是他們得公司
太嚴格反而惹人嫌...
而我們就是這些冤大頭...
未來政府案子都要看CMMI了
大公司可以這樣玩
小公司將被迫只能接大公司再轉包的專案
品質可想而知...
說實話 我對台灣的軟體業 是悲觀的

singlelog wrote:
有誰可以告訴我,CMMI要怎麼樣落實,就可以讓這個系統沒問題?Big Smile

.....



kenchu edited on 2007-01-16 11:47
reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:singlelog]
johnsoh

disney



發文: 456
於 2007-01-16 12:32 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
singlelog wrote:
高鐵的某位高層,擁有豐富的航空業訂票經驗。


航空業沒有自動售票機, 而且可以超賣, 座位是報到才確定的.

現在很多資深人員, 擁有的是早期系統規劃知識, main frame架構, 文件能力也不錯, 但合用嗎?
現在一般電腦能力已遠超過早期main frame主機, 而資訊的應用, 也遠超越main frame時代, Client端的低層處理訊號, 就不應該由主機直接處理. 應該用C/S架構才對.

其實很多系統, 用main frame, C/S, multi-tier 甚至DOS都可以"寫出來", 設計的人會使用最熟悉的架構, 而不考慮最優的架構.
可是當原先熟悉的架構漸漸不合時代, 也漸漸無法應付大量資料, 多種不同應用的需求時, 任你文件能力多好, 人力多麼充足, 都是無法應付的.


reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
singlelog

換回來



發文: 416
於 2007-01-16 12:46 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
對軟體工程而言
只有要求需求要定義清楚,要可以驗證(驗證規格符合需求,而不是驗證需求對不對),要可以追溯。

所以當我們一開始在創建一套系統時,就需要把怎麼樣確定requirement這件事給確定下來。你要找到stakeholer,你要找到『怎麼樣確定business requirement是對的』的標準作業程序。也就是說,當需求產生疑義的時候,要有人出來說,這樣做就對了。

判斷需求是不是對的,這不是工程人員要做的事情。不管是什麼樣的顧問,做了建議要是不被採納,那又是鼻子摸一摸繼續領錢。

user可能會仗著他們有多年的XX經驗。要求你照著做,你今天有什麼理由不照著做嗎?你可以剖析利弊得失,寫出長篇累牘,可是你做出來的報告,被user一腳踢開,另外訂定一套他要的標準。還會對你為什麼這麼機車不聽話感到很賭爛。三不五時找你們家總經理還是業務副總抱怨。

系統照user要的上線了,現在出包了。user翻臉不認帳,說是你的問題。還有技術論壇上的人,一直說你沒把requirement寫到文件裡面,沒把它當做是個risk,或者說沒有提醒使用者,做事的態度還不對。如果你是這個team的SA還是PM,應該是感到一整個的冏吧。

我不覺得問題出在requirement的原因在於,很多大公司,你要做什麼樣的系統,其實是聽客戶多頭馬車亂講後,再把它兜在一起。客戶講的如果串不起來,你會提建議。可是如果說服不了所有的人,就常常會有人跳出來說,這我決定。

不管你寫了再多文件,說這樣是錯的,他還會告訴你,聽他的準沒錯。系統上線後出包了。這仁兄還在不在是一回事,他認不認賬就是另外一回事了。他可能會告訴你,是你誤解他的意思。或者他只是建議,你應該本於專業來反駁。

這種東西可以靠CMMI來解嗎?你有真的推過CMMI然後就把這種問題解掉嗎?傳說中拔獅子的鬃毛可以治療禿頭。別再相信沒有根據的說法了。

每家公司都有它的問題,每個客戶都有他難搞的地方。CMMI遇到沒概念亂七八糟亂搞的客戶,還是一樣死。要是雙方的人都經驗不足,那上線後多繳點學費,這也就不足為奇了。

當然,不管怎麼說,扣一頂CMMI沒落實的帽子絕對不會有錯。出槌的專案,通常是很多症狀糾結在一起。一個人可能身上長了很多各式各樣的癌症,到最後才會死掉。死掉時你要說他就是沒把怎麼保養身體寫在user requirement裡面,再當做一個risk來好好manage才會死。我是覺得也說得通。不過我會比較好奇的是他到底根本的原因是什麼。


singlelog edited on 2007-01-16 13:03
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
singlelog

換回來



發文: 416
於 2007-01-16 13:22 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
BTW,是誰決定高鐵就不能用航空業的模式來賣票?分成賣票跟訂位兩個動作?這決定權是在user 嘛。這有什麼不合理的地方嗎?如果我可以先把票大量批給旅行社,這樣我是不是就可以快點收現金進來?

如果有這樣的考量,到後來又決定不這樣做,那很有可能,就會有一個高層跑出來:『你們要預留可以做航空業這樣的彈性在裡面。』這個可是個很重要的requirement,請你寫進會議記錄裡面。

這樣的requirement會事先規範在RFQ,或是合約裡面嗎?這就看你的命了。


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

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:高鐵,ETC原來都是同一家做的... [Re:singlelog]
kenchu





發文: 128
於 2007-01-16 13: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
說真的
我不想挑戰你
不過我真的建議你多看看CMMI跟其他專案管理的書
你講的都是現實的問題
這些問題正是軟體工程跟CMMI極力要解決的問題
CMMI 教育的不只是廠商也包含客戶
一個好的SA 具備有可以讓客戶了解這樣的設計會導致什麼樣的風險
並將這些在協商中提出
讓客戶確實知道根據這些需求設計後的東西是什麼
透過一連串的步驟可以讓雙方達到對系統的共識與了解風險所在
可清楚釐清設計的依據,跟設計的方向與最後的產出物
這是我對你提的問題的解決之道

但如何可以知道這些設計會導致什麼風險?什麼樣的系統
這樣的需求是否真的是客戶真正的需求,如何引導客戶,如何與客戶達成共識
根據很多人的經驗制定他的標準作業方式
這就是CMMI

而這些都是一大堆軟體公司都會遇到的問題的集合
CMMI就是整合這些問題提出步驟來改善、解決與避免這些問題

軟體工程最大的問題在哪?
就是在"人"
人不像機器投多少料產出多少,多久,做出來是什麼樣子這些都可以知道
很容易算出產能,但人不行
這也是為什麼資訊業的ISO推不起來,改推CMMI的主因
所以CMMI首要就是要避免"人"
把人變成機器
方法是透過文件了解產出物來掌控,唯有文件化才能知道這些資訊
其目的也就是要把人的因素降到最低

你不覺得你的問題都是在"人"
正是如此才會有CMMI
這是我對你提出問題的解決之道
你提了很多問題
那你的解決之道?
一個跟你一樣高強的PM?還是一個超強的工程師? 一組超強的TEAM?一個有水準的客戶?還是?

思考這問題 ,我們將有共識...

singlelog wrote:
對軟體工程而言
只有要求需求要定義清楚,要可以驗證(驗證規格符合需求,而不是驗證需求對不對),要可以追溯。

所以當我們一開始在創建一套系統時,就需要把怎麼樣確定requirement這件事給確定下來。你要找到stakeholer,你要找到『怎麼樣確定business requirement是對的』的標準作業程序。也就是說,當需求產生疑義的時候,要有人出來說,這樣做就對了。

判斷需求是不是對的,這不是工程人員要做的事情。不管是什麼樣的顧問,做了建議要是不被採納,那又是鼻子摸一摸繼續領錢。

user可能會仗著他們有多年的XX經驗。要求你照著做,你今天有什麼理由不照著做嗎?你可以剖析利弊得失,寫出長篇累牘,可是你做出來的報告,被user一腳踢開,另外訂定一套他要的標準。還會對你為什麼這麼機車不聽話感到很賭爛。三不五時找你們家總經理還是業務副總抱怨。

系統照user要的上線了,現在出包了。user翻臉不認帳,說是你的問題。還有技術論壇上的人,一直說你沒把requirement寫到文件裡面,沒把它當做是個risk,或者說沒有提醒使用者,做事的態度還不對。如果你是這個team的SA還是PM,應該是感到一整個的冏吧。

我不覺得問題出在requirement的原因在於,很多大公司,你要做什麼樣的系統,其實是聽客戶多頭馬車亂講後,再把它兜在一起。客戶講的如果串不起來,你會提建議。可是如果說服不了所有的人,就常常會有人跳出來說,這我決定。

不管你寫了再多文件,說這樣是錯的,他還會告訴你,聽他的準沒錯。系統上線後出包了。這仁兄還在不在是一回事,他認不認賬就是另外一回事了。他可能會告訴你,是你誤解他的意思。或者他只是建議,你應該本於專業來反駁。

這種東西可以靠CMMI來解嗎?你有真的推過CMMI然後就把這種問題解掉嗎?傳說中拔獅子的鬃毛可以治療禿頭。別再相信沒有根據的說法了。

每家公司都有它的問題,每個客戶都有他難搞的地方。CMMI遇到沒概念亂七八糟亂搞的客戶,還是一樣死。要是雙方的人都經驗不足,那上線後多繳點學費,這也就不足為奇了。

當然,不管怎麼說,扣一頂CMMI沒落實的帽子絕對不會有錯。出槌的專案,通常是很多症狀糾結在一起。一個人可能身上長了很多各式各樣的癌症,到最後才會死掉。死掉時你要說他就是沒把怎麼保養身體寫在user requirement裡面,再當做一個risk來好好manage才會死。我是覺得也說得通。不過我會比較好奇的是他到底根本的原因是什麼。


kenchu edited on 2007-01-16 13:55
reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
singlelog

換回來



發文: 416
於 2007-01-16 14:26 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
Hi, kenchu,

今天,神通遇到問題,可是這還是一個經過CMMI level 3 認證的公司,用這個專案拿到認證。所以我覺得,你不能夠單單一句話說,他是因為沒有落實,沒有讀通CMMI,其實只要落實CMMI,就可以解決他們所面臨的問題,是他沒做好。所以CMMI還是他們所遇到問題的solution。

CMMI既然是一種認證,那就表示他應該是以一套客觀的標準去驗證的。要拿到這樣的認證,其實花錢又花心力,而且並沒有那麼簡單。形式上吻合了,我就認為他們就達到一定的水準。要不然,拿到CMMI level 5的公司,要是專案做垮了,也被一句沒有落實就打死了,那這個認證就不要玩了。

做專案一定會遇到問題。有些你想過,有些你沒想過。遇到surprise,我的解決方法也是人。Big Smile

找到對的人加上時間。可以解決絕大多數的問題。所以我的態度一直是覺得,現在大家都用放大鏡在看這個系統的問題。事實上,新系統上線多半就是要陣痛一陣子,才會找到解決之道。用了對的人,他們再過一段時間,可以figure out要怎麼做才對。

我不覺得軟體開發是那種可以plug and play的事情。也不覺得有什麼可以把人的因素降到最低這回事。即使所有的東西都document下來,人還是最重要的因素。我大概是屬於比較接近tom demarco派的人,所以我不覺得這件事有這麼簡單。

你寫的這一段我很同意。

一個好的SA 具備有可以讓客戶了解這樣的設計會導致什麼樣的風險,並將這些在協商中提出,讓客戶確實知道根據這些需求設計後的東西是什麼,透過一連串的步驟可以讓雙方達到對系統的共識與了解風險所在,可清楚釐清設計的依據,跟設計的方向與最後的產出物 。

可是我遇過一些不懂裝懂的客戶,也遇過很多水準沒你這麼高可是又很堅持己見的客戶。有時候客戶會拒絕接受你的建議。可能是我們說服的能力不夠,所以客戶跑來跟我們的業務抱怨時,我們只能乖乖讓他牽著鼻子走。他還嫌你不夠聽話。

高鐵公司是一家新公司,以前在建鐵路,現在要開始營運。沒有人有營運一家高速鐵路新公司的經驗,所以沒有什麼往例可循。需求可能莫衷一是,那雜七雜八的需求混在一起,專業能力也不足的團隊,再加上一個迫切的deadline,造成他們今天的問題。這個我是認為是必要的學費。


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

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
singlelog

換回來



發文: 416
於 2007-01-16 14: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
想起一篇舊文。 我覺得時間是一個很重要的因素。我自己的經驗值,SA/SD : Coding : testing = 2 : 1 : 3。如果看起來測試時間縮短了,那就是在UAT或是上線之後還要付出代價才會stable。

所以可能有個milestone被硬逼著好像達成了,代價可是會在後面階段慢慢掏腰包付出來的。


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

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:高鐵,ETC原來都是同一家做的... [Re:kenchu]
antijava





發文: 65
於 2007-01-16 15: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 wrote:
說真的
我不想挑戰你
不過我真的建議你多看看CMMI跟其他專案管理的書

...恕刪..


看到這段話,
忍不住又跳出來講點話,
耳邊不禁響起singlelog大大的OS
「蝦米?專案管理?我寫過的文章說不定比你看過的還多」
開玩笑的, 別介意Big Smile

CMMI=文件=沒用,
這是一般常有的觀念,
我和很多人一樣,
聽CMMI之後心中第一個OS就是「又來了」
還有英文版OS「Oh, no, not again」

其實我才不管什麼CMMI,
如我之前所強調的,
我在乎的是「流程標準化」和「經驗傳承」,
而這兩件事似乎都脫離不了要寫點文件.

只要寫的內容正確(do what you write, write what you do),
寫的時間點正確(什麼文件後補? 後補等於應付),
文件不會是浪費生命的事情,
就像singlelog大大寫的專案管理的文章,
也可說是另一種型式的專案管理經驗傳承, 不是嗎?

我百分百同意「人」是CSF,
因此我一直期盼像站上各位優秀的大大,
能夠不藏私地公開分享自己的經驗,
不喜歡CMMI這個名詞,
我換個名詞,叫「Best Practice」好了.

以Singlelog大大所提的 SA/Coding/Test 2:1:3 這個為例,
kenchu或是其他大大一定也有自己的一套經驗值,
即使大家意見或經驗分岐,
武當劍, 少林拳...還是會有蹲馬步之類的基本功(異中求同),
將大多數人在專案各階段的經驗整理起來,
不就是台灣版的CMMI嗎?

不知道是不是我們都有傳統「留一手」的觀念,
以致於這麼多年來只能抄洋人的玩意兒,
ISO, CMMI, ITIL, BS7799...

如果台灣軟體界能訂出自己本土化的 Best practice 流程,
(多年前好像有一套SEED, 被打入泠宮)
那才是我期待的一天,
連標準的名字我都想好了, 先講先贏,
就叫「I-Taiwan」

取這個名字, 應該不會有人敢批評吧...Cool

大家加油吧...


reply to postreply to post

作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
piggy

piggy



發文: 333
於 2007-01-16 17: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
iTaiwan說不定已經先被Apple註冊走了 哈~~~
我是來亂的 Tongue


reply to postreply to post
An Apple a day, keeps M$ away
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
singlelog

換回來



發文: 416
於 2007-01-16 17:40 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,要是architect很差,PM很弱,SA沒經驗,其實寫再多文件還是一樣會死。

為什麼會這樣講,是剛剛我的朋友又告訴我,神通用了很多就業青年,就是找不到工作,到青輔會說要找工作,青輔會幫你出一點薪水,公司給他試用機會的就業青年。所以他雖然手下眾多,能打仗的實在不多。

再者,目前神通內部似乎是認為,系統本身並沒有錯,只是使用者不懂得欣賞這種航空業的訂票方式。Big SmileBig SmileBig Smile

我是不知道講再多CMMI可以做什麼,在這樣的氛圍之下,到底可以真正發揮些什麼。特別是現在很多軟體公司的主管,並沒有那麼了解軟體工程。平時錯誤的決策就一堆了,就算鍍上CMMI的金,那又有什麼用?可是如果老闆們持續照著舊思惟辦事,那光講要落實CMMI,結果卻只是變成了寫文件寫到爆,必要時老闆還是會來發揮政策指導,你到最後還是會被搞死,這樣的CMMI又有什麼意義呢?


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

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:高鐵,ETC原來都是同一家做的... [Re:singlelog]
kenchu





發文: 128
於 2007-01-16 23: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
機器可以買到一樣的規格
人卻很難找到一樣的能力的人
如果一個PM 跟我說 他的解決之道是用透過高手處理問題
那我會問他,那如果沒有高手了呢 ?
就注定案子會失敗麻??
如果CMMI 做的是要你找一個高手處理這些問題
沒有高手的話就會造成很多問題
那CMMI 早就被丟到垃圾桶了
CMMI沒有錯
錯在"人"
老闆不懂不願意做 主管不懂 不願意做
都是"人"
這也就是沒有落實
沒有落實的結果
就是搞成現在這樣,一蹋糊塗


kenchu edited on 2007-01-16 23:28
reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:singlelog]
kenchu





發文: 128
於 2007-01-16 23: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
你還是誤解了
如果你去認真去寫這些文件
每一個段落 都會跟你說你應該做些什麼
要怎作...
不管你有沒有經驗
如果你真的很認真去做
就可以避免這些問題
因為那些都是別人經驗的累積要做的事
最後變成一個標準讓你跟隨...
所謂得高手 不也只是知道該怎作 該做些什麼
既然CMMI都跟你說要做些什麼了
不就是照做了麻

其實導CMMI 初期最重要的角色是QA 不是PM

只要QA了解文件應撰寫的內容
並驗證內容是否正確與確實
那就又回到我剛剛說的
這些東西只要都照著做(照著眾多高手共同規畫出來的步驟標準作)
就可以避免很多問題發生
就算是沒經驗的人
也可以透過文件互相檢視達到控管
因為只有文件才能清楚表達你打算怎作要怎作會有怎樣的風險
只要寫的完整,就可以"檢視"(不要把東西放在腦裡,要寫出來才能讓別人知道,才能交流,才能知道哪裡有問題,才能經驗傳承...)

這絕對比強的PM 爛的TEAM 或濫的PM 強的TEAM 或強的PM 強的TEAM 但完全沒有依據的各自獨立的做專案,沒有把相關資訊文件化,無從得知彼此的想法與做法
來的更安全 更可以信任 也更可以累積經驗  提早發現解決問題

期待一個超強的PM,TEAM
都是風險
都得列入風險評估
因為萬一超強的PM 、TEAM 走了 掛了 病了
那是否整個專案將產生絕大風險
所以該如何避免這些的風險呢?

我提出的問題 , 大家不妨思考看看

singlelog wrote:
我倒不會覺得CMMI = 文件 = 無用。不過,CMMI如同其名,只是一個成熟度模型。你有了CMMI,要是architect很差,PM很弱,SA沒經驗,其實寫再多文件還是一樣會死。



kenchu edited on 2007-01-16 23:55
reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
blueman77





發文: 0
於 2007-01-17 00:33 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了,不世出的天才只要有三個人就可以改變世界了,而且還可以休閒時間中想出AMMI和BMMI來讓大家導入。
那導入CMMI就天下無敵了嗎?這又不盡然了,人畢竟不是機器,你要他寫文件,他會乖乖寫嗎?寫了難道不會應付了事嗎?我寫了,眉角都讓你知道了。
那我還混啥?寫出來的文件是不是真的有價值,這又要怎麼衡量呢?總不能叫網友給點數來評分吧?
明明流程說好要那樣跑,我偏不跑,和菜鳥做一樣的事,怎麼顯的我資深呢?
CMMI的假設是好的,但是人們又不是純潔的白紙,規距如電腦,君不見...光是導入知識管理就已困難重重了。
我想CMMI還是一個新名詞,我期待CMMI 2.0 的出現。


reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
kenchu





發文: 128
於 2007-01-17 00: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整天抱怨長官不懂,工程師太差,資源太少,客戶太爛
整天認為所有的問題都是在人身上
而不是設法去降低這些風險
那我只能說,台灣就是這種環境
而解決之道就是落實文件的製作,讓風險降到最低
而不是雙手一攤說,阿就沒高手壓 我能怎樣..


kenchu edited on 2007-01-17 00:54
reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
singlelog

換回來



發文: 416
於 2007-01-17 01:07 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,

我怎麼覺得你好像有點誤會我的說法。我並沒有說有了高手,這些高手就會跟散兵游勇一樣地胡亂夾雜在一起亂做。也不是說你找來一堆強人,這些人就什麼文件都不寫,人一不爽就放著讓公司倒。

找好的人上門,跟你要不要寫文件,這是兩碼子事。

我只是覺得,找了傻瓜來,不會的東西就是不會。你要他寫,他會寫一個看起來形式正確的東西給你。可是這東西的價值可能趨近於零。後人要接這個系統,其實就被一堆文件壓到死。

我自己帶專案,我會盡量避免為了寫文件而寫文件。最重要是這份文件確實有用,從頭串到尾是必要的。而且對於大家進習溝通,了解彼此的想法有正面的幫助。

至於透過高手處理問題,我覺得這就看你開發系統的本質了。最近這幾年我幾乎都用蠻接近extreme programming的方式在做專案。寫程式的人少,可是彼此很有默契,透過msn進行大量的溝通,透過CVS進行version control。文件極少,很多想法就躲在程式碼裡面。

系統出了問題,大概同個team的人看一看就知道別人的東西哪邊出錯,要怎麼改,要在哪邊改。

沒有寫文件,這會是一個很大的問題嗎?對我們就還好。

當然,開發大型系統,story全然不同。因為系統大到沒辦法讓每個人都可以輕鬆理解,所以一定要尋求方法來做divide and conquer。這時候文件絕對有必要。可是要怎麼樣從頭一路串到尾。從user requirement到design/test case design/code/test data ...一路串下去,然後盡量只做最低程度的文件,這就是看開發團隊的人要怎麼視狀況做決定。

任何一種文件,如果可以不要寫還可以讓專案進行的很順利,那就盡量不要去寫它。要不然,寫完每次改版,這東西會不會呈指數成長,這我就不知道了。比如說需求一動,就會牽涉到一拖拉庫文件全死。光是每個文件的改版就會讓人流出眼淚來。

很多時候,我們只有能力記錄version 0.8 的文件,從0.8到1.5中間的文件,就看良心了。我知道CMMI一定會嚴格要求你什麼文件都要寫。可是這衍生出來的這個工作量,就不見得是每個軟體公司的老闆願意買單的。如果你把產生文件這件事當做是完全不需要任何成本的話,到時候很可能就會連自己是怎麼死的都不知道。


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

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
singlelog

換回來



發文: 416
於 2007-01-17 01:33 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
BTW, 不管在哪邊,有個強人PM/architect/designer/programmer走了,都應該會是一種很大的損失。開發系統時,常常會遇到某些問題,是沒有強人就解不掉的。這跟製造業不一樣。

如果你做的東西,是人人都可以抽換的,那表示你用個code generator就可以協助你做好大部份的事情。你讓寫文件的人變成去configure這個code generator的rule,你其實就省下一大塊人力與時間,以及可能到處蔓生的bug。

拿你的例子來問你好了,你因為對公司不爽所以走人了。你留下了文件給後面的人,他們就可以繼承你的想法,做新的專案就高枕無憂嗎?然後看著你的文件,就可以沒有問題地快速開發嗎?對你們公司來說,是你比較有價值,還是你的文件?還是說你老闆一拿到你的文件,就可以把你一腳踢開?

如果事情像你描述的這樣的話,我要是貴公司的主管,我絕對是把你當大爺伺候的好好的。文件有沒有寫是一回事,少掉一個腦袋清楚又有能力的人,這個就虧大了。

當然啦,如果我們公司,數十年來都在開發同樣的產品,有著專攻的domain,那前人的智慧絕對有可取之處。不過要是不是這樣的話,我覺得最重要的還是在人。當然啦,你要是覺得你在你們公司裡面,是那麼容易被取代的,公司有需要,可以去印度還是中國找個人來plug and play,這我也沒什麼意見。只是說我並不相信這種事可以在現實世界中發生。

把michael jordan插到巫師隊,巫師也沒就此拿到nba總冠軍。把Karl Malone,Gary Payton,Shaq,Kobe通通放在湖人隊,那年也沒拿到nba總冠軍。我是覺得開發軟體比較像是在組這種運動團隊,或者像是tom demarco說的在組合唱團。你有的是一個個不一樣的人,不是把強人兜在一起就會發生最好的結果。

可是你要是相信說,只要michael jordan 寫了一本秘笈,講講怎麼樣從罰球線起跳灌籃的絕技,然後隨便去大陸的國家隊挑個籃球員,還是去印度的國家隊挑個球員,隨便組一組的雜牌軍,要他們照著練,後就可以打敗眾高手,拿到NBA總冠軍,這種事是打死我也不會相信的啦。


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

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:高鐵,ETC原來都是同一家做的... [Re:singlelog]
kenchu





發文: 128
於 2007-01-17 09:43 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所接手的案子總金額約三億(軟體六 硬體四)
包含軍方,政府,企業 
這些專案我都做過
除了幾個案子有高手幫我外
其他都是剛畢業,而且還是剛工作的新鮮人組成的TEAM
但都如期做完,而這些案子還每一個都不一樣,差異很大
要說這是雜牌軍,我個人覺得是
但除了別人的爛攤子外,只要是我主導的案子,都成功,無一失敗
這說明我很強麻,不是!而是我很守規舉照著別人的經驗去做
認真寫我的文件,寫著幫助我自己了解專案內容,了解問題可能點,讓我的工程師了解我設計理念
客戶-我-工程師 我們三方都達到共識,彼此都了解專案設計的依據
跟系統完成後的樣貌,所以核心需求很少改,改的都是一些介面需求
所以專案才得以如期完成

我的工程師只要照著我的文件作,而我只要照著別人的經驗做
這樣我們雜牌軍(沒一個是高手),一樣做完這些專案
NBA 是 NBA ,專案是專案
兩個扯在一起,我不覺得這是好的例子
畢竟專案重的經驗累積,解決問題的經驗與資源的分配
而不是小隊能力...

而且一個PM能不能做好專案的原因是取決在小組中有沒有強而有力的工程師...
那就真的風險太大...
我不覺得這是一個好的PM
不過台灣對PM的要求就是只要可以搞定客戶就好,作的爛也沒差...
大不了再花一筆錢帶客戶去上上酒家...
反正搞定客戶就肯驗收就好,懂不懂管理,甚至基本觀念都沒有也沒差
反正PM就只是掛名的業務罷了...
我猜X通也是這樣搞...
只可惜這東西是消費者在用,不是像有些是買來丟在哪不用,消費預算的東西,多爛也沒人知道,PM還可以揚揚得意的升官發財...

singlelog wrote:

可是你要是相信說,只要michael jordan 寫了一本秘笈,講講怎麼樣從罰球線起跳灌籃的絕技,然後隨便去大陸的國家隊挑個籃球員,還是去印度的國家隊挑個球員,隨便組一組的雜牌軍,要他們照著練,後就可以打敗眾高手,拿到NBA總冠軍,這種事是打死我也不會相信的啦。


kenchu edited on 2007-01-17 10:07
reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
tonyyg





發文: 0
於 2007-01-17 10: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
1. CMMI本身是很好的,只是因文化環境不同,會被誤用。所以要檢討的不是制度,而是人…
2. 高鐵的系統不是很了解,不過和是不是用RS-232無關吧? 一切還是回歸到人,老手新手有差,還有做事的態度決定一切
3. 台灣資訊的人材太多了,多到爛竽充數,良材癈材混在一起,老闆那管那麼多,時間內做的出來就好。所以資訊業也是良心事業ㄚ
4. 這種大案子,往往是說的人多,做的人少。顧問一大堆,意見也一堆,七嘴八舌的,吵了老半天,就是沒人肯簽名負責。下面的看著辦
5. 現在很多軟體已經外包阿六仔做了,一行十元,便宜沒好貨啊。不過台灣人也別洋洋得意,沒得寫也混不下去。好一點的還能混個SA/SD來當飯碗。不過人家早晚寫,累積經驗。總有一天會取代掉台幹(為什麼? 便宜又好用)

唉~
台灣的軟體業越來越不像話了
早點轉行賣雞排吧


reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:singlelog]
aladdin

老婆不准我用兒子照片



發文: 175
於 2007-01-17 10:14 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:
都進本壘了,打出全壘打之後要做啥,這要是想不太出來,那就會分手了。所以需求其實也要不斷改版。有可能到最後就變成不要因為過一棵樹就放棄一座森林。


獨孤大,你又害我噴可樂了......

看完這整串東西(花了我兩個多小時),我對獨孤大所說的心有戚戚焉。神通到底有沒有照著CMMI走,我們不知道;但是CMMI不能解決高鐵售票系統的問題,大概是應該的。當你從頭看整個發展足跡的時候,你會發現:政治的影響(長官的、承辦人員的、開發team之間的),這些沒有辦法透過CMMI解決的問題,才是影響專案結果最重要的因素。

關於doucment,我一直秉持一個原則:如果今天你寫一份文件,你的team不需要花半個小時看完,然後仔細想想會不會造成他的困擾,這份文件根本就不必寫,而應該想辦法在程式碼中表達出來。符合這個標準的,通常只有:requirement、architecht framework 和 sequence diagram。至於use case,通常是這三樣兜不起來了,才會去翻出來檢查的東西(多半是再去問客戶一次)。

至於CMMI:如果每個程式師可以配個助理,或是他只領半天的薪水,另外半天免費寫document我再來考慮...什麼,我們不是印度?對壓,這本來就是美國人發工作給印度人用的東西阿...


aladdin edited on 2007-01-17 10:20
reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:tonyyg]
kenchu





發文: 128
於 2007-01-17 10: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
你寫的我真的心有戚戚焉
前陣子我想換工作
在高雄應徵了幾家
可惜人家要的PM都是那種會交際應酬的資深業務
而不是專案管理強的人才...
不管客戶給我的評價多高...專案管理做多好...
都比不上我的人脈超廣超大...

說的洋洋灑灑專案管理...
老闆根本不在意,人家要的都是業務PM
哪裡要懂專案管理的PM
希望是因為我在高雄得關係...

我看我來專案管理賣香雞排
可能會變成我得第二春...

tonyyg wrote:
1. CMMI本身是很好的,只是因文化環境不同,會被誤用。所以要檢討的不是制度,而是人…
2. 高鐵的系統不是很了解,不過和是不是用RS-232無關吧? 一切還是回歸到人,老手新手有差,還有做事的態度決定一切
3. 台灣資訊的人材太多了,多到爛竽充數,良材癈材混在一起,老闆那管那麼多,時間內做的出來就好。所以資訊業也是良心事業ㄚ
4. 這種大案子,往往是說的人多,做的人少。顧問一大堆,意見也一堆,七嘴八舌的,吵了老半天,就是沒人肯簽名負責。下面的看著辦
5. 現在很多軟體已經外包阿六仔做了,一行十元,便宜沒好貨啊。不過台灣人也別洋洋得意,沒得寫也混不下去。好一點的還能混個SA/SD來當飯碗。不過人家早晚寫,累積經驗。總有一天會取代掉台幹(為什麼? 便宜又好用)

唉~
台灣的軟體業越來越不像話了
早點轉行賣雞排吧


kenchu edited on 2007-01-17 10:20
reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:aladdin]
kenchu





發文: 128
於 2007-01-17 10: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
很標準的台式資訊工程師想法

幾個思考點...
第一 需求怎來? 需求是否正確?
第二 沒有規格哪來設計?
第三 沒有測試計畫如何驗證程式正確?
第四 沒有風險評估哪來專案管理?
第五 軟體設計不等於專案管理

台灣專案失敗最多的原因
就是PM,只會一張嘴客戶說什麼都好,對系統根本不懂只會交際應酬
工程師只會關在家裡想系統該怎設計而不願意跟客戶溝通
所以需求全錯
到最後修修補補,程式碼也亂七八糟
以後人走了也沒辦法維護,只能亂改,看起來對就好

就我所看過的資訊大公司  無一例外...

aladdin wrote:
獨孤大,你又害我噴可樂了......

看完這整串東西(花了我兩個多小時),我對獨孤大所說的心有戚戚焉。神通到底有沒有照著CMMI走,我們不知道;但是CMMI不能解決高鐵售票系統的問題,大概是應該的。當你從頭看整個發展足跡的時候,你會發現:政治的影響(長官的、承辦人員的、開發team之間的),這些沒有辦法透過CMMI解決的問題,才是影響專案結果最重要的因素。

關於doucment,我一直秉持一個原則:如果今天你寫一份文件,你的team不需要花半個小時看完,然後仔細想想會不會造成他的困擾,這份文件根本就不必寫,而應該想辦法在程式碼中表達出來。符合這個標準的,通常只有:requirement、architecht framework 和 sequence diagram。至於use case,通常是這三樣兜不起來了,才會去翻出來檢查的東西(多半是再去問客戶一次)。

至於CMMI:如果每個程式師可以配個助理,我再來考慮...這不是說CMMI不重要,只是我寧可去花時間找更能和我們一起工作的人...


kenchu edited on 2007-01-17 10:24
reply to postreply to post
作者 Re:高鐵,ETC原來都是同一家做的... [Re:adoo]
singlelog

換回來



發文: 416
於 2007-01-17 10:24 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來說,他的工作基本上就是讓整個team 照他的規劃一起和諧地在一起工作,並且與客戶達到共識,把工作都順順利利的完成。可以做到的人,其實就是一個很優秀的PM了。

在我的定義裡面,這樣的PM就已經是一個強人。他不需要是萬能PM呀。Big Smile 太過萬能的PM,常常會選擇去當一個能人,而非當一個管理者。

話說回來,你完全照一定的流程在開發系統,然後run的很好。這並不能拿來證明,當其他的人,完全符合CMMI的定義,同樣的去run project,就會有一樣的成果。That's my point.


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

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:高鐵,ETC原來都是同一家做的... [Re:kenchu]
antijava





發文: 65
於 2007-01-17 10:31 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 大大,
我說真的,
以你的經歷,
建議你到台北找工作,
或者到新竹園區找工作,
對你自己
或是對軟體界,
都是利多呀.

六年三億Shock,
我在dot com時代過了之後,
就不知道超過千萬的案子長得什麼樣子了...DeadDead


reply to postreply to post

作者 Re:高鐵,ETC原來都是同一家做的... [Re:singlelog]
kenchu





發文: 128
於 2007-01-17 10:31 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來說,他的工作基本上就是讓整個team 照他的規劃一起和諧地在一起工作,並且與客戶達到共識,把工作都順順利利的完成。可以做到的人,其實就是一個很優秀的PM了。

在我的定義裡面,這樣的PM就已經是一個強人。他不需要是萬能PM呀。Big Smile 太過萬能的PM,常常會選擇去當一個能人,而非當一個管理者。

話說回來,你完全照一定的流程在開發系統,然後run的很好。這並不能拿來證明,當其他的人,完全符合CMMI的定義,同樣的去run project,就會有一樣的成果。That's my point.


kenchu edited on 2007-01-17 10:34
reply to postreply to post
go to first page go to previous page  1   2   3   4   5   6   7   8   9   10   11  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