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:panteratw]
felix_xd





發文: 0
於 2007-05-03 14: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
panteratw wrote:

如果地球是平的,那麼1+1=2,因為1+1=2,所以地球是平的。
這句話之所以成立,是因為在推論中,後件(1+1=2)成立,所以前件(地球是平的)成立。推論中有效與否與事實、經驗、信仰、權威無關。



我沒念過邏輯,不知道那是念什麼的.
不過有念過數位邏輯,布林代數的東西.
我一直以為邏輯是一種數學.

"如果地球是平的,那麼1+1=2,因為1+1=2,所以地球是平的。"

這句話可以分成兩個成分.
A : 地球是平的,true or false
B : 1+1=2,true or false

邏輯運算上,A=B -> B=A,是成立的(好像是交換律).
B(1+1=2)永遠是true,所以A(地球是平的)永遠是true.

但是整句話的前半段:"如果地球是平的,那麼1+1=2"
意思是 A=B 嗎?


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





發文: 14
於 2007-05-03 14:53 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
arima wrote:
知識是有價的Tongue
想知道原因 其實去修課 老師可能第一節課就會教到這觀念

重點:若p則q 只能推論出非q則非p 並不能推論出q則p

重點就這麼一句 至於為什麼 我不想多做解釋
解釋的工作就由專業的老師們來做比較好
要讓人學會邏輯不是一件容易的事
我不認為我多做解說你就會了解
所以也只能建議你去修課
這也是其他人建議你去修課的原因
"教"這件事 還是由專業的老師們來做比較好


嗯,感謝您,如果我舉例失當,自己搞錯了推論規則,我會檢討,謝謝您。

如果我證實了您的推論是對的,我會上來對我的大意向大家道歉,並且重作說明,謝謝。

另外我舉例的用意是在於說明邏輯的推論中有效與否與事實、經驗、信仰、權威無關。這部份如果也有錯,或是推論失當,如果您願意的話,還請指正,謝謝。

這陣子有點坐立不安,也許我找到原因了,如果您說的是,我很感謝您。謝謝


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

換回來



發文: 416
於 2007-05-03 14:55 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要懂技術、才有能力分配資源、管理風險、掌握進度
那是不了解以上這些東西的來源是工作項目、不是所謂的技術
其實我很建議看看我之前貼的 專案計畫
目錄其實就是工作項目
專案就是把那些事做完

1.要做風險管理必需要懂得技術。不懂技術的人是很難做好風險管理。
2.工作項目跟產出物,並不足以做風險管理
3.資源與進度的話,也需要技術能力才有辦法理解。需要什麼樣的資源,為什麼,以及目前的進度到底到哪邊。
4.你會有work item,會有mile stone,可是這些work item到底是指什麼,到底嚴重性有多大,不懂技術的人是不會理解的。
5.我看了很多次你的專案計劃,可是就是沒有提到,沒有技術的人,怎麼樣做好風險管理。

kenchu wrote:
專案管理組的工作內容也不包含技術支援
對專案管理的要求、技術也非必要

我這裡講的技術是指軟體開發的能力
而非軟體管理的能力

那先前講半天說專案管理又不是軟體管理,那你指的技術到底是什麼?含不含所謂軟體管理的能力?我是比較喜歡 軟體工程這個名詞啦。

我是覺得,PM的工作本來就是把Project 管理好。至於你在人力不足時自己跳下場去作戰,通常是橋不到resource時,不得不然的結果。這種事如果變成常態當然非常不好。偶一為之也只能說是無奈的事實,這個世界不怎麼完美。

我們不喜歡這種狀況,可是要說沒有技術(包含軟體工程方面的know how我也算是技術的一種,大概不曉得從第N篇就講過了。)就可以把決策做好,還會做好風險管理,這真的不太可能。

kenchu wrote:
其實就以軟體工程來說
其管理與技術也是分開的
其不同在於
軟體管理目標物是軟體
專案管理目標物是專案

這其實是很弔詭的地方。

因為我看了不少軟體工程的書,裡面當然是沒講什麼軟體管理目標物是軟體,專案管理目標物是專案。

如果你要講的是說自己做一套軟體,跟自己開發一個專案有所不同,這我還勉強可以理解。要不然的話,軟體專案的標的就是軟體,刻意說這與軟體不一樣是很怪異的事。

軟體工程的書通常是不講售後服務,主要是因為前面的部份就已經太厚了。講不完。

kenchu wrote:
專案如果是軟體專案,那就是用專案管理管理整個專案、用軟體管理來管理軟體開發、其工作項目就是軟體開發、但這裡的軟體開發其實會有一個組長,負責各位一直提到要懂技術的工作,但之上是PM、PM管的是整個專案組織

一個軟體專案的組織大概可以分成

專案管理組
系統(軟體)開發組
測試工程組
品質保證組
構型管理組
後勤支援組
....

軟體開發組織如果細分、本身也有測試、品管等軟體工程組織
做的其實就是軟體管理的事
但其Leader 是軟體開發組組長,不是PM
所以很多人把PM定位在這裡、是不好的定位
因為其他組織其實也都歸PM管理
所以PM的工作事擬定以上各組的工作
並訂出產出物讓品質管理組管理
其產出物非只有軟體產生、包含各式文件(包含計畫的執行)、資源運用...等
都是品質管理組在監督、並提供報告給PM
PM上面還是有頭,如部門主管、PM部門的經理、可以一同參加會議
可以透過品質管理部門的報告、監督PM
PM透過品質管理部門的報告、監督各部門(包含品質管理部門)
如此一來、專案依附在公司非依附在個人
也就是公司有能力管控專案的進行
而非只有PM可以掌控、公司只能依賴PM

組織要健全,制度要健全
台灣資訊業才能繁榮
我們是該檢討討論目前一昧的依賴PM技術能力才能做好專案的思考
是否也是台灣資訊業最大的問題所在

如果專案可以歸專案
組織可以健全
制度可以建立
PM為什麼不能就做專案管理的工作
為什麼一定要連開發都要做
既然不需要
那我們對PM的要求
是否應該回歸到專案管理
而不是軟體管理...

覺得台灣不好,我們可不可以看美國大公司的經驗?要講專案管理,歷史最悠久的,就是IBM。我沒聽過IBM的PM有不懂技術的。

那還是要看Google,Microsoft,Oracle?

為什麼,PM要懂技術,因為那是他的最終標的。不管是qualicty control,不管是quality assurance,還是你指的configuration management,最終的目的都是要產出軟體。如果軟體deliver出去了,那就達成一個很重要的milestone。

不是說其它的東西不重要,而是說,這個是最後客戶要的東西。你提供其它方面的數據與報告,都是來告訴人家他的品質怎麼樣,可是最後人家在用的,或者真正需要的,還是軟體本身。

test team把testing都做完了,到最後要是開發team沒做完,那就是沒做完,沒東西可以上線。所以所有的PM都會focus在開發這一段。因為這是他最主要要管理的東西。

一直到今天還在講『PM為什麼不能就做專案管理的工作,為什麼一定要連開發都要做 』,這件事跟PM懂技術有關嗎?

PM要做的專案管理工作裡面,最會需要focus的,就是軟體的開發。從一開始需求訪談分析設計,到coding,testing,其實這整個主題,就圍繞在,你要開發的軟體,到底做到哪裡了,什麼時候可以上線,目前還有什麼問題。

不同階段會有不同的重點,可是專案管理這檔子事就必需要圍繞著這個開發的過程去跑。你如果採用不同的開發流程,就會有不同的重點。

這是你講的working item 沒錯,不過工作項目上的東西,有些東西就不一定是專案管理者的重點。就像有些defect的severity比較低一樣。那種gui的錯字的defect待解,或是手冊寫的不完善要改,都是工作項目的一環,可是PM可以不用把重點擺在這種事情的控管上面。

要是一個當經理人的人不懂技術,他就對他實際要管理的東西會缺乏概念。這不是不可行,不過,我們通常不會賭這麼大,把一切押在一個不懂的人身上。


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

我的網站:diggirl.net

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





發文: 128
於 2007-05-03 14:58 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
Sorry 借您的文章用一下,希望不會又把您推入火坑

您提到
在火燒到屁股的時侯,
又找不到動作夠快的救火隊的時侯,


很明顯以專案管理得角度來看
這是一個風險
也就是做不完的情況
其風險處置辦法可以為
找人、外包、逼人加班加到死、請客戶上酒家賠罪...等
而懂技術的PM很難袖手旁觀不親自跳下去給火燒 的情況,
其實應列入 "找人" 這個風險處置
也就是把PM當作這個風險處置的資源來處理
PM在這個時候並不是PM,而是這風險處置的資源
所以不管 PM 懂技術或不懂技術
其實對專案管理來說,沒有意義
因為那只是資源的運用

但對風險來說
則是會面臨到PM投入開發的風險中
這風險是否大於做不完的風險,這個其實要看情況改變
也就是說,PM懂技術真正的功用其實只是可以充當工程師用
對專案管理則是根本沒有差別



antijava wrote:

這點我同意,
然而在我個人的經驗裡,
在火燒到屁股的時侯,
又找不到動作夠快的救火隊的時侯,
懂技術的PM很難袖手旁觀不親自跳下去給火燒...
(至於不懂技術的PM怎麼該怎麼處理,
或是專案成敗的責任歸屬,
又是另一篇故事了)



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





發文: 14
於 2007-05-03 15: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
felix_xd wrote:
我沒念過邏輯,不知道那是念什麼的.
不過有念過數位邏輯,布林代數的東西.
我一直以為邏輯是一種數學.

"如果地球是平的,那麼1+1=2,因為1+1=2,所以地球是平的。"

這句話可以分成兩個成分.
A : 地球是平的,true or false
B : 1+1=2,true or false

邏輯運算上,A=B -> B=A,是成立的(好像是交換律).
B(1+1=2)永遠是true,所以A(地球是平的)永遠是true.

但是整句話的前半段:"如果地球是平的,那麼1+1=2"
意思是 A=B 嗎?


不,這個推論語法是所謂的假言推論,前件、後件並沒有if and only if的關係,所以並不是A=B。

我越來越懷疑自己是否舉例失當,自己搞錯推論規則了。我查清楚後,會再上來說明。還好,這問題不用修課,把書拿出翻翻就可以找到答案了。謝謝指教。


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





發文: 128
於 2007-05-03 15:06 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也不可能全部都懂

您提到的都是資訊公司的軟體開發管理
不是專案管理....

請您真的務必搞懂什麼叫做專案管理跟軟體工程

singlelog wrote:
1.要做風險管理必需要懂得技術。不懂技術的人是很難做好風險管理。
2.工作項目跟產出物,並不足以做風險管理
3.資源與進度的話,也需要技術能力才有辦法理解。需要什麼樣的資源,為什麼,以及目前的進度到底到哪邊。
4.你會有work item,會有mile stone,可是這些work item到底是指什麼,到底嚴重性有多大,不懂技術的人是不會理解的。
5.我看了很多次你的專案計劃,可是就是沒有提到,沒有技術的人,怎麼樣做好風險管理。

那先前講半天說專案管理又不是軟體管理,那你指的技術到底是什麼?含不含所謂軟體管理的能力?我是比較喜歡 軟體工程這個名詞啦。

我是覺得,PM的工作本來就是把Project 管理好。至於你在人力不足時自己跳下場去作戰,通常是橋不到resource時,不得不然的結果。這種事如果變成常態當然非常不好。偶一為之也只能說是無奈的事實,這個世界不怎麼完美。

我們不喜歡這種狀況,可是要說沒有技術(包含軟體工程方面的know how我也算是技術的一種,大概不曉得從第N篇就講過了。)就可以把決策做好,還會做好風險管理,這真的不太可能。

這其實是很弔詭的地方。

因為我看了不少軟體工程的書,裡面當然是沒講什麼軟體管理目標物是軟體,專案管理目標物是專案。

如果你要講的是說自己做一套軟體,跟自己開發一個專案有所不同,這我還勉強可以理解。要不然的話,軟體專案的標的就是軟體,刻意說這與軟體不一樣是很怪異的事。

軟體工程的書通常是不講售後服務,主要是因為前面的部份就已經太厚了。講不完。

覺得台灣不好,我們可不可以看美國大公司的經驗?要講專案管理,歷史最悠久的,就是IBM。我沒聽過IBM的PM有不懂技術的。

那還是要看Google,Microsoft,Oracle?

為什麼,PM要懂技術,因為那是他的最終標的。不管是qualicty control,不管是quality assurance,還是你指的configuration management,最終的目的都是要產出軟體。如果軟體deliver出去了,那就達成一個很重要的milestone。

不是說其它的東西不重要,而是說,這個是最後客戶要的東西。你提供其它方面的數據與報告,都是來告訴人家他的品質怎麼樣,可是最後人家在用的,或者真正需要的,還是軟體本身。

test team把testing都做完了,到最後要是開發team沒做完,那就是沒做完,沒東西可以上線。所以所有的PM都會focus在開發這一段。因為這是他最主要要管理的東西。

一直到今天還在講『PM為什麼不能就做專案管理的工作,為什麼一定要連開發都要做 』,這件事跟PM懂技術有關嗎?

PM要做的專案管理工作裡面,最會需要focus的,就是軟體的開發。從一開始需求訪談分析設計,到coding,testing,其實這整個主題,就圍繞在,你要開發的軟體,到底做到哪裡了,什麼時候可以上線,目前還有什麼問題。

不同階段會有不同的重點,可是專案管理這檔子事就必需要圍繞著這個開發的過程去跑。你如果採用不同的開發流程,就會有不同的重點。

這是你講的working item 沒錯,不過工作項目上的東西,有些東西就不一定是專案管理者的重點。就像有些defect的severity比較低一樣。那種gui的錯字的defect解,或是手冊寫的不完善要改,都是工作項目的一環,可是PM可以不用把重點擺在這種事情的控管上面。

要是一個當經理人的不懂技術,他就對他實際要管理的東西會缺乏概念。這不是不可行,不過,我們通常不會賭這麼大,把一切押在一個不懂的人身上。


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

換回來



發文: 416
於 2007-05-03 15:15 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
在火燒到屁股的時侯,
又找不到動作夠快的救火隊的時侯,


其實在這種狀況下,第一個問題是,你要先確定,你遇到的問題的根源在哪裡?

很多時候,我們會往錯的地方去找答案。所以,你會需要RD achitect的意見,test team的意見,也有可能需要客戶的意見。負責開發的人,會有他對問題的詮釋,你要先聽聽大家怎麼說。

要是你搞不懂火是從那裡燒過來,你有可能就跑到錯誤的地方去。

這是為什麼PM要懂技術的關係。

至於解決方案,你可能會有很多可以選的。要選哪一個就悉聽尊便。比如說,找不到人時自己下去寫。

我有遇過PM要自己去寫操作手冊的狀況。像是這種狀況就是公司的愚蠢,是高階經理人該檢討,為什麼公司會發PM的薪水給一個 PM,讓他拿時間去當technical writer用。

以前我常常去救火,救火首要的原則就是要找出起火點。你不找出根源來,後面一大堆問題。所以沒有技術的人到底要怎麼做風險管理,怎麼下決定,其實這種問題打嘴砲容易。說什麼沒技術的人也可以在眾人熱情的擁戴下做好,事實上,大家都忙得要死時,你自己什麼技術都不會,其實很難掌握狀況,要是遇到你的team leader比較強勢的,你就只能低聲下氣地求求team leader撥撥他寶貴的時間解釋給你聽。嗯,這種事以前也看過。


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

我的網站:diggirl.net

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





發文: 128
於 2007-05-03 15: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
我只能說
貴公司沒有技術人員麻
沒有一個技術人員可以協助麻
得PM自己處理..
做個專案管理還得先把技術提升到 Top 才可以管(沒到 Top就能找到起火點,那工程師不就品質堪憂...)

那技術部門主管是在睡覺的麻
正是沒有建立專案制度也沒有建立專案組織
才會有這些根本不是問題的問題...

singlelog wrote:
在火燒到屁股的時侯,
又找不到動作夠快的救火隊的時侯,


其實在這種狀況下,第一個問題是,你要先確定,你遇到的問題的根源在哪裡?

很多時候,我們會往錯的地方去找答案。所以,你會需要RD achitect的意見,test team的意見,也有可能需要客戶的意見。負責開發的人,會有他對問題的詮釋,你要先聽聽大家怎麼說。

要是你搞不懂火是從那裡燒過來,你有可能就跑到錯誤的地方去。

這是為什麼PM要懂技術的關係。

至於解決方案,你可能會有很多可以選的。要選哪一個就悉聽尊便。比如說,找不到人時自己下去寫。

我有遇過PM要自己去寫操作手冊的狀況。像是這種狀況就是公司的愚蠢,是高階經理人該檢討,為什麼公司會發PM的薪水給一個 PM,讓他拿時間去當technical writer用。

以前我常常去救火,救火首要的原則就是要找出起火點。你不找出根源來,後面一大堆問題。所以沒有技術的人到底要怎麼做風險管理,怎麼下決定,其實這種問題打嘴砲容易。說什麼沒技術的人也可以在眾人熱情的擁戴下做好,事實上,大家都忙得要死時,你自己什麼技術都不會,其實很難掌握狀況,要是遇到你的team leader比較強勢的,你就只能低聲下氣地求求team leader撥撥他寶貴的時間解釋給你聽。嗯,這種事以前也看過。


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

換回來



發文: 416
於 2007-05-03 15: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
kenchu,

我先前已經講過了,這裡是Java論壇,我們在討論的是軟體專案管理,你要討論建築業的,還是全世界走到哪裡都會通的專案管理,你去建築師論壇還是什麼專案管理認證論壇去討論。不要一直要我們搞懂專案管理可以用在幫老人通便,可以用在讓特技演員跳火圈上面。

軟體專案的特點,就是他是開發軟體,而軟體這類型的開發工作有他特殊的地方。高鐵有十個車站要蓋,中間有三個進度落後了,三個進度超前,你可能可以調進度超前的team的人去落後的地方支援。你有三個軟體專案進度落後了,三個進度超前了,調進度超前的team的人去落後的地方支援,你可能會得到六個落後的專案,而這三個落後的有可能會落後的更嚴重。

這些就是軟體專案比較特別的地方。

台灣軟體界最大的問題,就是一些不懂軟體專案管理的人,一直在那邊裝懂。請務必搞懂這件事。

我講的當然都是軟體方面的專案,要不然講半天你還以為在講什麼?我們又不是要去考營建工程專案管理,也不是要去考在走在世界各地都會通的專案管理。所以當然討論的是軟體專案。如果你要討論的是專案,是那種包含投資銀行管理,還是反攻大陸之類的專案,還是那種陸軍總司令可以不懂怎麼作戰的專案,這個恕小弟不會。我只懂軟體專案。


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

我的網站:diggirl.net

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





發文: 128
於 2007-05-03 15: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
軟體專案多數都會包含硬體
軟硬體稱為系統
一個大型系統專案就像我說的
包含很多東西在裡面
PM是不可能每種技術都懂
所以也不會要求PM懂這些...

另外
做軟體管理的人叫做軟體開發的Leader
不叫做PM

如果結論是資訊公司做軟體開發的人就叫做PM
而本討論串講的是軟體管理而非專案管理

那我很抱歉
是我搞錯了

singlelog wrote:
kenchu,

我先前已經講過了,這裡是Java論壇,我們在討論的是軟體專案管理,你要討論建築業的,還是全世界走到哪裡都會通的專案管理,你去建築師論壇還是什麼專案管理認證論壇去討論。不要一直要我們搞懂專案管理可以用在幫老人通便,可以用在讓特技演員跳火圈上面。

軟體專案的特點,就是他是開發軟體,而軟體這類型的開發工作有他特殊的地方。高鐵有十個車站要蓋,中間有三個進度落後了,三個進度超前,你可能可以調進度超前的team的人去落後的地方支援。你有三個專案進度落後了,三個進度超前了,調進度超前的team的人去落後的地方支援,你可能會得到六個落後的專案,而這三個落後的有可能會落後的更嚴重。

這些就是軟體專案比較特別的地方。

台灣軟體界最大的問題,就是一些不懂軟體專案管理的人,一直在那邊裝懂。請務必搞懂這件事。

我講的當然都是軟體方面的專案,要不然講半天你還以為在講什麼?我們又不是要去考營建工程專案管理,也不是要去考在走在世界各地都會通的專案管理。所以當然討論的是軟體專案。如果你要討論的是專案,是那種包含投資銀行管理,還是反攻大陸之類的專案,還是那種陸軍總司令可以不懂怎麼作戰的專案,這個恕小弟不會。我只懂軟體專案。


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

換回來



發文: 416
於 2007-05-03 15:35 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自己處理..
那技術部門主管是在睡覺的麻
正是沒有建立專案制度也沒有建立專案組織
才會有這些根本不是問題的問題...

敝公司有技術人員,敝公司也有技術主管,可是要是我不懂技術,他講給我聽我是聽得懂嗎?我要是不了解嚴重性,我知道那件事值得我要把所有的事情停下來優先處理嗎?

出問題的時候,每個人都認為他的問題最重要。小從高中生要嘿咻找不到保險套,大從在體育館嘿咻貼照片被全世界都看到。你要是沒有技術能力,人家聽不懂你在講什麼,你不能下正確的判斷,那要你這個PM是要做什麼?真的只是在畫甘特圖而已嗎?

就是有很多很多東西都跟技術有關,你不可能什麼不懂就都去問人家。會出什麼問題,也不是大家可以事先料到的,所以很多時候你要在蠻短的時間內做出判斷與取捨。人家給你建議,有空跟你寫說這是我的建議方案,而你要拿什麼東西去換嗎?

很多solution都有tradeoff,比如說拿時間換空間,拿空間換時間,拿金錢換人力,你要做每個決定,都會有要給的東西。有經驗跟沒經驗的人就差在這邊,你會知道你要拿什麼去換,做了一件事之後會有什麼後果。技術主管又不是你的萬靈丹,他能夠講的東西有限,剩下很多事要你自己去做判斷。

比如說,出了一個defect很嚴重,技術主管建議你,我們把它當做沒看到,直接趕deadline進 UAT,你是做還不做?他也是專業人士呀。那他叫你挖個坑把自己埋起來,你幹是不幹?並不是說人家會害你,而是說每個人都有自己的考量。比如說,tester說有bug,report給test team leader,programmer說沒有,report給developmenet team leader,兩個人槓上了,這時候那你要聽誰的?是看誰跟你交情比較好嗎?


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

我的網站:diggirl.net

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

換回來



發文: 416
於 2007-05-03 15:43 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是不可能每種技術都懂
所以也不會要求PM懂這些...


你知道找那種賣硬體的人來管軟體專案有多恐怖嗎?

我沒有要他什麼都懂,可是系統整合專案,不懂軟體開發其實是蠻恐怖的一件事。

PM不可能什麼技術都懂,這我們大家都講過了。可是不可能什麼技術都懂,跟PM 不懂技術(這聽起來是什麼都不懂),這差別很大好嗎?

kenchu wrote:
另外
做軟體管理的人叫做軟體開發的Leader
不叫做PM

如果結論是資訊公司做軟體開發的人就叫做PM
而本討論串講的是軟體管理而非專案管理

那我很抱歉
是我搞錯了

本討論串講的,是有沒有不會寫程式卻在做系統分析的?Big SmileBig SmileBig Smile

我覺得啦,一個懂軟體開發的PM,遇到那種軟硬體整合的案子,可能會遇到不少問題,不過多少都還是處在可以解決的範圍,遇到一個不懂軟體開發的PM接手這種軟硬體整合的案子 ,那會死得有多慘,就很難預料了。

我在講的,其實都是只有軟體專案裡面,一個專職的軟體專案PM,帶領著technical team 與test team...等等團隊去把軟體做完。我想我從頭到尾就是在講軟體專案。應該可以在前一百篇裡面看到吧。那種肚子痛要投黃色炸彈進馬桶的專案,就不是我的專長了。

當然啦,你口口聲聲胾講的是台灣軟體界的問題,接下來又要把系統整合給納進來。那還會再把建築跟投資銀行也納進來嗎?這我就真的不會了。


singlelog edited on 2007-05-03 15:45
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

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





發文: 2
於 2007-05-03 15: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
felix_xd wrote:
我沒念過邏輯,不知道那是念什麼的.
不過有念過數位邏輯,布林代數的東西.
我一直以為邏輯是一種數學.

"如果地球是平的,那麼1+1=2,因為1+1=2,所以地球是平的。"

這句話可以分成兩個成分.
A : 地球是平的,true or false
B : 1+1=2,true or false

邏輯運算上,A=B -> B=A,是成立的(好像是交換律).
B(1+1=2)永遠是true,所以A(地球是平的)永遠是true.

但是整句話的前半段:"如果地球是平的,那麼1+1=2"
意思是 A=B 嗎?

imply ( -> ) 跟 對等/等於 (=) 並不同...
比方 "因為她懷孕了, 所以她是女生". 不等於 "因為她是女生, 所以她懷孕了". 這個是 imply. 你證明了前一段, 不等於後面那一段也成立.

另外, 她是瑪莉, 瑪莉是她. 這裡用的是等於. 所以當 A=B 成立 B=A 也成立. 不過呢, 常常會有誤用的地方. 這應該是邏輯比較複雜的地方: 我們會誤用或混淆. 同例子, 如果這裡有兩個都叫瑪莉, 那 A=B 成立, 是否 B=A 也成立呢? 如果瑪莉是指特定某個叫做瑪莉的人, 那成立. 但如果你只是說明 她的名子叫瑪莉, 那後面那句話不成立.

這是人類語言複雜跟混淆的地方. "她是瑪莉" 可以被解讀成 "她就是那個特定叫做瑪莉的人", 也可以解讀成 "她的名子叫做瑪莉". 所以當我們在談 "她是瑪莉, 瑪莉是她", 我們必須先確定: 1. 有幾個瑪莉, or 2. 字句中的瑪莉是單指名子, 還是特定的人.

這就像是這個 thread 一樣. 我們談 "技術" 這兩個字時, 每個人心中的定義不同. 就會發生 A=B, 卻無法同意 B=A.


ianhong edited on 2007-05-03 15:47
reply to postreply to post
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:arima]
panteratw





發文: 14
於 2007-05-03 16: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
arima wrote:
知識是有價的Tongue
想知道原因 其實去修課 老師可能第一節課就會教到這觀念

重點:若p則q 只能推論出非q則非p 並不能推論出q則p

重點就這麼一句 至於為什麼 我不想多做解釋
解釋的工作就由專業的老師們來做比較好
要讓人學會邏輯不是一件容易的事
我不認為我多做解說你就會了解
所以也只能建議你去修課
這也是其他人建議你去修課的原因
"教"這件事 還是由專業的老師們來做比較好


dear sir,

您好,感謝您播空指正我的缺失,我把推論的規則搞混了,混洧了大家的視聽,感到非常報歉。
例子應該是這樣舉的:
如果1+1=2,那麼地球就是平的。
因為1+1=2。
所以地球是平的。

這是有效的,這是所有邏輯的推論中,所謂的假言推論,推論的規則是,如果我肯定了前件(第一句話中前面的條件語句),那麼可以肯定後件(第一句話中後面的條件語句),另一方面,如果我否定後件,那麼就可以否定前件。拿另一個例子來作比較:(希望不會再搞錯了:p)

如果天下雨,那麼地就會濕。
天下雨了。
所以地濕了。

我們可以說因為天下雨了(肯定前件),所以地濕了(可以肯定後件),
我們也可以說地沒有濕(否定後件),所以天沒有下雨(可以否定前件),
但是我們不可以說地濕了(肯定後件),所以天下雨了(肯定前件),
明顯地,我們也不可以說因為天沒下雨(否定前件),所以地不會濕(否定後件),
因為就事實面來說,地會濕的原因有很多,不一定要天下雨地才會濕;而就邏輯面來說,若p則q,若非q則非p(這是邏輯的語法規則,證明上吳定遠先生有翻譯了一本書叫「數理邏輯原理」,上面有寫,很抱歉書在家裡,我的能力也不夠證不出來)。所以arima 先生的指正是對的,感謝您。常看到這句話「魔鬼就在細節裡」,我該好好檢討,感謝您播空指教,浪費您的時間,不好意思。

另方面舉例是為了要說明,邏輯講的是語法規則,所以與事實、經驗、信仰、權威無關。我相信我主要的論點沒有錯。如果認為陳述經驗的整段話就不是邏輯的是沒有道理的。就我曾經提出的「今天天氣很好」,跟「我覺得今天天氣很好」在語意上是大不相同的。當我說「今天天氣很好」這句話只是單純地指出今天的天氣狀況,那麼這要用觀察來證明真或是假的,沒有推論,所以與邏輯無關。但是如果我說「我覺得今天天氣很好」那麼我為什麼會有這樣的感覺??,因為…所以…而我只是省略罷了。舉個例子:

所有唸資訊的學生,都會在學校的電算中心打電腦,今天有一群人在電算中心打電腦,這群人都是唸資訊的學生。這段話是不是邏輯的陳述??是。只是這段話的邏輯不正確,我們就事實面就可以看得出這句話不對,因為我們都知道有些唸別的學科的學生也會來使用電算中心的電腦;而就邏輯來說,因為所有唸資訊的學生,並沒有窮盡所有的學生,也就是說不是所有的學生都是唸資訊的,所以由前提推不到結論來,所以這段話的推論不正確。但是我們可以說那段話只是陳述,是沒有邏輯的嗎??相信不是。

謝謝arima 先生,也對blueman77 先生感到報歉,我拿錯誤的邏輯規則來論述,對不起。而我的邏輯錯誤是我自己造成的,不是書上寫的,因為書上寫的並沒有錯。…這麼說來好像對作者也該表達歉意。anyway,希望多多不吝指教,能夠這樣子討論真有趣。希望這個討論串的主題越來越熱,可以吸引越來越多的高手出來和singlelog 先生討論。謝謝。


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

雲端決策系統

版主

發文: 1861
於 2007-05-03 16: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
破表了~ 也來湊一腳

PM可以不懂技術 如圖

如果專案管理是一個 interface的話,那麼的確是不用考慮實做的(不用懂技術)。
需要懂技術的是實做專案管理的特定領域專案。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public interface ProjectManagement {
  public Object 資源管理();
  public Object 管理風險();
  public Object 掌握進度();
  ...
}
public SoftwareProjectManagement implements ProjectManagement{
  public Object 資源管理(){
     程式人員能力評估
     ...
  }
  public Object 管理風險(){
     系統當機處理流程
     ...
  }
  public Object 掌握進度(){
     bug數目監控
     ...
  }
  ...
}

SoftwareProjectManagement 顯然會有很多軟體相關的知識在裡面,所以應該要懂技術。
但 SoftwareProjectManagement不是 ProjectManagement,如同白馬非馬,因此堅持PM可以不懂技術也沒錯啦,只是蠻無聊的。

(縮略圖,點擊圖片鏈接看原圖)


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





發文: 128
於 2007-05-03 17:00 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 當作軟體管理得 Leader 在看待,所以才一直堅持認為 PM需要有技術背景才有能力做好專案管理
我則是想打破這種觀念,讓PM歸PM,技術歸技術
讓技術工程師有個可以純技術升遷的管道
也期待台灣的軟體公司建立專案制度與組織

而不是
一直以軟體管理的角度來管理專案
以軟體管理的 Leader 的工作來要求 PM

這才是我想表達的

kebin_liu wrote:
破表了~ 也來湊一腳

PM可以不懂技術 如圖

如果專案管理是一個 interface的話,那麼的確是不用考慮實做的(不用懂技術)。
需要懂技術的是實做專案管理的特定領域專案。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public interface ProjectManagement {
  public Object 資源管理();
  public Object 管理風險();
  public Object 掌握進度();
  ...
}
public SoftwareProjectManagement implements ProjectManagement{
  public Object 資源管理(){
     程式人員能力評估
     ...
  }
  public Object 管理風險(){
     系統當機處理流程
     ...
  }
  public Object 掌握進度(){
     bug數目監控
     ...
  }
  ...
}

SoftwareProjectManagement 顯然會有很多軟體相關的知識在裡面,所以應該要懂技術。
但 SoftwareProjectManagement不是 ProjectManagement,如同白馬非馬,因此堅持PM可以不懂技術也沒錯啦,只是蠻無聊的。


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

OMG!



發文: 87
於 2007-05-03 17: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
kenchu wrote:
您誤會了
我想我文中提到
我堅持的是PM懂不懂技術都可以做好專案管理
另一方是堅持 PM 得懂技術才能做好專案管理


我之所以一直強調
也是因為太多的資訊公司
都把PM 當作軟體管理得 Leader 在看待,所以才一直堅持認為 PM需要有技術背景才有能力做好專案管理
我則是想打破這種觀念,讓PM歸PM,技術歸技術
讓技術工程師有個可以純技術升遷的管道
也期待台灣的軟體公司建立專案制度與組織

而不是
一直以軟體管理的角度來管理專案
以軟體管理的 Leader 的工作來要求 PM

這才是我想表達的


這位大師您誤會了
您的論述是說PM可以完全不管細節,但其他人是覺得PM不見得全懂,但懂最好
而且您一直假設所有的人都「都把PM 當作軟體管理得 Leader 在看待」
才會這樣有理說不清

對了,既然加入了這個話題
「媽!我上電視了」 Big Smile


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





發文: 2
於 2007-05-03 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
kebin_liu wrote:
破表了~ 也來湊一腳

PM可以不懂技術 如圖



我在想, PM 到底是什麼? Project Manager? Program Manager? Project Management?

中文: 專案管理師? 專案經理? 專案管理經理? 專案管理? 還是項目經理?

哀... 你們到底在講什麼??!!


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





發文: 128
於 2007-05-03 17: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
如果不是當 當作軟體管理得 Leader 在看待
那何須堅持PM一定要懂技術才能管好專案 ?
畢竟軟體的專案管理其實是不需要技術背景的

我想我一直在驗證 PM是不需要技術也可以管好專案
懂也好,不懂也沒差,才是我的論述吧
但有些人卻認為沒有技術背景當依靠是不可能管好一個專案
會被虎,會搞砸
所以我一直在驗證專案管理是不需要技術背景
我想文章都沒改,應該可以查證我說的話
我提的誤會是這個,因為您誤解我的論述

以上技術都是指軟體開發技術能力..

電視有轉播麻....

YA ... 媽你有再看嘛,是我呀是我...

javaer wrote:
這位大師您誤會了
您的論述是說PM可以完全不管細節,但其他人是覺得PM不見得全懂,但懂最好
而且您一直假設所有的人都「都把PM 當作軟體管理得 Leader 在看待」
才會這樣有理說不清

對了,既然加入了這個話題
「媽!我上電視了」 Big Smile


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





發文: 128
於 2007-05-03 17: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
原來貴公司的技術人員的話是沒技術的人聽不懂的
那貴公司的客戶應該都很強,不然肯定聽不懂你們在做什麼

專案有專案的風險,軟體開發有軟體開發的風險
如果你指的是軟體開發的風 險,那主要處理者還是軟體開發組組長
不是 PM
一個軟體開發組組長如果不能把問題說出來給不懂技術的人聽,
那我請問PM何以有能力把問題 說出來給客戶聽
難道技術問題的軟體開發組組長沒能力處理
得PM處理這些技術問題
事實上要PM處理的都多數都是資源問題
那裏會是技術問題......
我實在不懂貴公司的組織,技術主管沒能力處理技術問題,得PM來處理
如果是資源的問題,那PM懂技術的目的何在
投入自己變成開發的資源麻

一直以來我很希望您可以分別出這兩者身分的差異

您提的都不是問題,這些都是處理的方式,是分工的責任,我強調不要用支微末節的方式來討論
這些本來就是一個專案組織在分配工作上都可以解決的
不用制度去看去處理,老用推給PM就對了的方式
當然就會認為PM懂技術是必須的..
我不諱言,如果技術的東西都得勞煩PM處理,那這專案組織本身就有問題...

singlelog wrote:
敝公司有技術人員,敝公司也有技術主管,可是要是我不懂技術,他講給我聽我是聽得懂嗎?我要是不了解嚴重性,我知道那件事值得我要把所有的事情停下來優先處理嗎?

出問題的時候,每個人都認為他的問題最重要。小從高中生要嘿咻找不到保險套,大從在體育館嘿咻貼照片被全世界都看到。你要是沒有技術能力,人家聽不懂你在講什麼,你不能下正確的判斷,那要你這個PM是要做什麼?真的只是在畫甘特圖而已嗎?

就是有很多很多東西都跟技術有關,你不可能什麼不懂就都去問人家。會出什麼問題,也不是大家可以事先料到的,所以很多時候你要在蠻短的時間內做出判斷與取捨。人家給你建議,有空跟你寫說這是我的建議方案,而你要拿什麼東西去換嗎?

很多solution都有tradeoff,比如說拿時間換空間,拿空間換時間,拿金錢換人力,你要做每個決定,都會有要給的東西。有經驗跟沒經驗的人就差在這邊,你會知道你要拿什麼去換,做了一件事之後會有什麼後果。技術主管又不是你的萬靈丹,他能夠講的東西有限,剩下很多事要你自己去做判斷。

比如說,出了一個defect很嚴重,技術主管建議你,我們把它當做沒看到,直接趕deadline進 UAT,你是做還不做?他也是專業人士呀。那他叫你挖個坑把自己埋起來,你幹是不幹?並不是說人家會害你,而是說每個人都有自己的考量。比如說,tester說有bug,report給test team leader,programmer說沒有,report給developmenet team leader,兩個人槓上了,這時候那你要聽誰的?是看誰跟你交情比較好嗎?


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

換回來



發文: 416
於 2007-05-03 17:57 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懂不懂技術都可以做好專案管理
另一方是堅持 PM 得懂技術才能做好專案管理


我之所以一直強調
也是因為太多的資訊公司
都把PM 當作軟體管理得 Leader 在看待,所以才一直堅持認為 PM需要有技術背景才有能力做好專案管理
我則是想打破這種觀念,讓PM歸PM,技術歸技術
讓技術工程師有個可以純技術升遷的管道
也期待台灣的軟體公司建立專案制度與組織

而不是
一直以軟體管理的角度來管理專案
以軟體管理的 Leader 的工作來要求 PM

這才是我想表達的

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

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

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

誰可以告訴我,是我國學能力太差嗎?『一個PM根本不需要了解技術』跟『PM懂不懂技術都可以做好專案管理』這一樣嗎?

然後,我們討論的點,一直都不是下面這些東西:
讓PM歸PM,技術歸技術

讓技術工程師有個可以純技術升遷的管道

台灣的軟體公司建立專案制度與組織

這幾個論點我就說過了,請建立起這跟PM懂不懂技術之間的因果關係。

如果PM懂了技術,就沒有讓PM歸PM,技術歸技術嗎?技術工程師就沒有可以純技術升遷的管道嗎?台灣的軟體公司就不會建立專案制度與組織嗎?


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

我的網站:diggirl.net

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





發文: 89
於 2007-05-03 18: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:
如果不是當 當作軟體管理得 Leader 在看待
那何須堅持PM一定要懂技術才能管好專案 ?
畢竟軟體的專案管理其實是不需要技術背景的

我想我一直在驗證 PM是不需要技術也可以管好專案
懂也好,不懂也沒差,才是我的論述吧
但有些人卻認為沒有技術背景當依靠是不可能管好一個專案
會被虎,會搞砸
所以我一直在驗證專案管理是不需要技術背景
我想文章都沒改,應該可以查證我說的話
我提的誤會是這個,因為您誤解我的論述

以上技術都是指軟體開發技術能力..

電視有轉播麻....

YA ... 媽你有再看嘛,是我呀是我...


我是不知道您怎麼看這四百多篇的Post
一開始是有人提過"會被虎,會搞砸",是,我有提過
您堅持這是沒有制度的關係

那好,我也想像出一個兩難的局面
=>系統寫下去效能會無法達成需求,幕僚建議砍掉重練或是加買硬體解決
沒人虎,沒人砸,大家都是希望專案可以上線收到錢
PM沒有相關技術背景要怎麼評估兩種方案對專案的影響

一開始堅持沒有相關技術背景也可以管理專案的也是您
既然這麼神,那也請您提一下併購銀行有哪些工作項目
您的回應是PM找顧問來就好了,這種大型專案本來就有顧問
所以您也可以管理併購專案
好呀,雖然現實中不是每個專案都找的到顧問可以問
<eg.日本蓋新幹線去哪找顧問,送人上月球去哪找顧問?>
不過我們還是送一個或是一群顧問過去
顧問送出來的報告裡面沒有包含任何技術面的報告?
一個PM沒有相關的技術背景看的懂這些報告?

真的那麼神,如果您願意那還是請您大概說一下,
併購銀行的專案的專案計畫書大概會有哪些工作項目
畢竟
之前也是您自己說的,
"但其實我不懂採購銀行可我知道怎麼管理一個採購銀行專案"
您之前也提過,PM只要看計畫書就可以管理專案了
要是連計畫書都提不出來,還說什麼專案管理呢?
PM不能只是等人家準備好專案計畫書吧


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

換回來



發文: 416
於 2007-05-03 18: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
kenchu wrote:
原來貴公司的技術人員的話是沒技術的人聽不懂的
那貴公司的客戶應該都很強,不然肯定聽不懂你們在做什麼

敝公司的技術人員都很會解釋。

問題是,我們會預期客戶很笨,可是客戶會付錢給我們,所以我們解釋給他聽是應該的。我們不會預期PM很笨,因為PM薪水通常都拿蠻多的,你付他錢,他什麼都不會,又不是sales,你就會覺得很X!

比較客氣一點的說法是,我們花錢養一個廢人做什麼?
kenchu wrote:
專案有專案的風險,軟體開發有軟體開發的風險
如果你指的是軟體開發的風 險,那主要處理者還是軟體開發組組長
不是 PM
一個軟體開發組組長如果不能把問題說出來給不懂技術的人聽,
那我請問PM何以有能力把問題 說出來給客戶聽
難道技術問題的軟體開發組組長沒能力處理
得PM處理這些技術問題
事實上要PM處理的都多數都是資源問題
那裏會是技術問題......

事實上,PM要處理的,通常是技術人員的資源問題。也就是說,我們人不夠了,我們沒有能力解決這個問題,我們需要某某人火力支援。這一定要XXX才可以解決這個問題。

這裡面會先有一個技術問題,我們在XX地方卡住了,需要討論演算法,然後需要browser跟koji兩個人下來幫忙。你就是要去判斷,這個東西卡住了,你要的這兩個人可以解決問題嗎?我可以要得到這兩個嗎?還是說要找jini跟anthoychen來幫忙。他們可以解決問題嗎?(id是隨手想到隨便打,不代表任何技術能力的假設)

技術人員講的是人話呀,可是你要怎麼下決定?還是說你要去哪邊找個大師來弘法?

在這裡有聽不懂人話這個問題嗎?是人家講了人話,你還是要決定怎麼辦吧。

技術部門的leader,跟你說了,我要這幾個人,沒有這案子就go不下去,你變不出這幾個人,你就要說專案失敗嗎?你如果想一想,想要調動施工的順序,沒有技術能力可以辦得到嗎?

我說過了,PM要做的事叫做判斷,叫做決策。不是要自己下去解問題。可是要是自己一點技術能力都沒有,怎麼做判斷?聽都聽不懂問題的癥結點在哪邊。怎麼做決策?搖骰子嗎?玩一次吹牛,輸的人就要下來解決問題嗎?

你從專案的狀況裡面,會收集到很多訊息,你要去判斷,哪些是對的,哪些是錯的,專案現在的狀況到底是什麼?有沒有辦法繼續做下去?有什麼樣的棋可以下?

這些不是經驗,就是專業。沒有什麼叫技術組長來幫你解決的空間。要不然,你就是不要掛PM,或者當個掛名不辦事的PM,這也可以。這就不要講說你在做管理啦。我們也遇過那種專門跟客戶交際的PM。我是覺得那是sales啦。

kenchu wrote:
我實在不懂貴公司的組織,技術主管沒能力處理技術問題,得PM來處理
如果是資源的問題,那PM懂技術的目的何在
投入自己變成開發的資源麻

不是,是做決策的時候,不需要透過技術主管語言翻譯機。當然啦,我講的一直都是以軟體工程方面的知識當做主體。這從這個thread的第一頁我就講過了。

kenchu wrote:
您提的都不是問題,這些都是處理的方式,是分工的責任,我強調不要用支微末節的方式來討論
這些本來就是一個專案組織在分配工作上都可以解決的

沒有一件事不是在分配工作上可以解決的。我也說過很多次,哪一家的公司只要寫plan,不用真的做管理,出事推給下面的人就好,我馬上去interview。

人家花錢請一個米蟲,這當然可以,只要公司是他爸爸開的,沒多少人會講話。可是我們要討論的,是一個企業的常態,還是那種爸爸是董事長的PM?我也請教過你,你一直認為台灣的公司有一堆問題,那歐美那一家大公司,採用了你的說法?要不然,為什麼我們不照人家外國大公司,做出很多軟體的公司的方法去走,要下這種猛藥?

對你來說,我提的都不是問題。所以我只能問一些像是你的專案計劃書的內容這類的問題。

在實務上窒礙難行的東西,比較適合進學術殿堂去討論啦。我們舉了例子,問你要怎麼處理,這就叫枝微末節。How convenient.

kenchu wrote:
不用制度去看去處理,老用推給PM就對了的方式
當然就會認為PM懂技術是必須的..
我不諱言,如果技術的東西都得勞煩PM處理,那這專案組織本身就有問題...

技術的問題不用通通推給PM,可是,很多PM要做的決策需要具有技術背景才容易做出正確的判斷。

歐美的大公司不是傻瓜,他們為什麼不用純粹只懂project management的人來當PM?因為了解軟體開發這件事並不如一般人想像的那麼簡單。

哈哈哈,已經排到第一名了!接下來應該是看會不會破500。Big SmileBig SmileBig Smile


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

我的網站:diggirl.net

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





發文: 89
於 2007-05-03 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
kebin_liu wrote:
但 SoftwareProjectManagement不是 ProjectManagement,如同白馬非馬,因此堅持PM可以不懂技術也沒錯啦,只是蠻無聊的。


ProjectManagement 這個是Interface,你無法Create這個物件
-->無法有這種不限領域的實體PMBig Smile


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





發文: 0
於 2007-05-03 21: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
singlelog wrote:
敝公司的技術人員都很會解釋。

問題是,我們會預期客戶很笨,可是客戶會付錢給我們,所以我們解釋給他聽是應該的。我們不會預期PM很笨,因為PM薪水通常都拿蠻多的,你付他錢,他什麼都不會,又不是sales,你就會覺得很X!

比較客氣一點的說法是,我們花錢養一個廢人做什麼?

事實上,PM要處理的,通常是技術人員的資源問題。也就是說,我們人不夠了,我們沒有能力解決這個問題,我們需要某某人火力支援。這一定要XXX才可以解決這個問題。

這裡面會先有一個技術問題,我們在XX地方卡住了,需要討論演算法,然後需要browser跟koji兩個人下來幫忙。你就是要去判斷,這個東西卡住了,你要的這兩個人可以解決問題嗎?我可以要得到這兩個嗎?還是說要找jini跟anthoychen來幫忙。他們可以解決問題嗎?(id是隨手想到隨便打,不代表任何技術能力的假設)

技術人員講的是人話呀,可是你要怎麼下決定?還是說你要去哪邊找個大師來弘法?

在這裡有聽不懂人話這個問題嗎?是人家講了人話,你還是要決定怎麼辦吧。

技術部門的leader,跟你說了,我要這幾個人,沒有這案子就go不下去,你變不出這幾個人,你就要說專案失敗嗎?你如果想一想,想要調動施工的順序,沒有技術能力可以辦得到嗎?

我說過了,PM要做的事叫做判斷,叫做決策。不是要自己下去解問題。可是要是自己一點技術能力都沒有,怎麼做判斷?聽都聽不懂問題的癥結點在哪邊。怎麼做決策?搖骰子嗎?玩一次吹牛,輸的人就要下來解決問題嗎?

你從專案的狀況裡面,會收集到很多訊息,你要去判斷,哪些是對的,哪些是錯的,專案現在的狀況到底是什麼?有沒有辦法繼續做下去?有什麼樣的棋可以下?

這些不是經驗,就是專業。沒有什麼叫技術組長來幫你解決的空間。要不然,你就是不要掛PM,或者當個掛名不辦事的PM,這也可以。這就不要講說你在做管理啦。我們也遇過那種專門跟客戶交際的PM。我是覺得那是sales啦。

不是,是做決策的時候,不需要透過技術主管語言翻譯機。當然啦,我講的一直都是以軟體工程方面的知識當做主體。這從這個thread的第一頁我就講過了。

沒有一件事不是在分配工作上可以解決的。我也說過很多次,哪一家的公司只要寫plan,不用真的做管理,出事推給下面的人就好,我馬上去interview。

人家花錢請一個米蟲,這當然可以,只要公司是他爸爸開的,沒多少人會講話。可是我們要討論的,是一個企業的常態,還是那種爸爸是董事長的PM?我也請教過你,你一直認為台灣的公司有一堆問題,那歐美那一家大公司,採用了你的說法?要不然,為什麼我們不照人家外國大公司,做出很多軟體的公司的方法去走,要下這種猛藥?

對你來說,我提的都不是問題。所以我只能問一些像是你的專案計劃書的內容這類的問題。

在實務上窒礙難行的東西,比較適合進學術殿堂去討論啦。我們舉了例子,問你要怎麼處理,這就叫枝微末節。How convenient.

技術的問題不用通通推給PM,可是,很多PM要做的決策需要具有技術背景才容易做出正確的判斷。

歐美的大公司不是傻瓜,他們為什麼不用純粹只懂project management的人來當PM?因為了解軟體開發這件事並不如一般人想像的那麼簡單。

哈哈哈,已經排到第一名了!接下來應該是看會不會破500。Big SmileBig SmileBig Smile

奇怪呢,我看到這些感覺和PM的技術能力沒有關係,感覺和PM的人際能力和溝通能力比較有關係呢。
而需要誰來支援,感覺是等IT Leader報給你的吧,你覺得他說的不對,那就是你覺得自己的技術能力比IT Leader強,這太不信任專業了吧,難怪專案問題多,平安回家最好
看起來這個PM越權了


blueman77 edited on 2007-05-03 22:08
reply to postreply to post
(Total 33 pages)  
go to first page go to previous page  13   14   15   16   17   18   19   20   21   22   23  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