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:eriklin]
habbit

有怪獸~快跑



發文: 84
於 2007-04-20 11:41 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是不是利害關係人之一
還是他又只是Proxy而已,把專案管理計畫書轉給別人去簽名
自己不用簽名?

PM簽名就表示他認可這個執行計畫,而他也要依照這個計畫去執行
如果他底下的專案團隊送出一個超出範圍(預算,技術.........)的計畫上來
他也不可能就直接簽了吧,還不是要請他們再調整到他願意簽名的地步
我比較難想像,你要送給客戶老闆看,PM不用簽名或是表示他同意這個計畫書

所以還是有PM決定收不收啦(簽名或是其他表示他同意的表達方式)

pm當然是最重要的利害關係人,因為專案的成敗在他的手上.
pm當然要簽名,因為這是他未來執行專案管理的重要依據!

但沒有收不收的問題,因為撰寫管理計畫書是由pm所主導!
對內來說是總合內部專案成員提供的意見及技術來達到專案目標,對外來說就是要讓客戶知道pm是如何管理專案是被正確的執行!

當然,一個管理計畫書並不可能一次搞定,會經過與利害關係人討論的過程,也就是你所說的調整的過程,也就是我之前提到的要與利害關係人共同訂定的過程!這就牽扯到pm必備的專案知識!
這裡指的專案知識包括一些範圍,時程,成本,品質,風險,溝通...等等管理知識.
而這些知識是我認定一個pm所必須具備的,當然就不同領域的專案,pm有相關的技術背景是最好的,因為能幫助pm做正確決策與判斷,如果沒有,就要思考如何利用相關資源來幫助判斷.

簡單來說,我所要強調的是,沒有pm沒有收不收的問題,因為這個計畫書是由他主導提出的,說明未來他要如何管理專案!

另外之前可能打太快,表達錯我的想法:一些詳細的範圍,時程,風險,成本...等等相關的規劃並不是在計畫書完成之後,是要包含在計畫書之中


reply to postreply to post
陷入無止盡的迴圈...
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:singlelog]
habbit

有怪獸~快跑



發文: 84
於 2007-04-20 12: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
singlelog wrote:
habbit ,

專案計劃的話,PM的角色會比較像是記者與被採訪的對象之間的關係。被採訪的人會說出他想要記者刊登的部份。而記者要基於自己的判斷去決定取材。

就像我們去包案子,客戶在你還沒簽約時都會說,這個很簡單,那個很簡單,就怎麼樣弄一弄就好了。

這是stakeholder的說法。sales也會說,不是拿我們的XX案子的東西改一改就好了?architect可能會說,這技術上有XX系統與XX系統整合的問題,我們要先survey一下,做做實驗才能告訴你。

每個人都告訴你他認知到的部份。技術人員也幫你做出估計來了,可是你就直接把他寫進去嗎?

很多人會做調整。比如說,嗯,這個habbit每次都估的太樂觀,他的數字要double,嗯,這邊的人力可能會出問題,所以要加兩個人進來,恩,這個survey要做三個月,太唬爛,改成兩個月。

我們常常在詬病的地方也在這邊。你做這些調整,到底有沒有所本呀?

比較有制度的公司會用比較量化的數據,而且會加入review的機制來處理這個問題。不過基本上,最後交考卷時,還是PM在交考卷。


以上同意,這也是我們公司現在的做法!在量化的數據上,會參考之前專案作的lesson learnd and template,以及召集專案團隊大家一起來review!


當然,這世上計畫永遠趕不上變化。所以不管你計畫想得多麼天衣無縫,變化可能都還是很多。

有些人是會把什麼configuration management plan,完整的test plan + test case design,measurement plan...通通都算是project plan的一環。所以你的project plan有可能是不斷在專案進行過程中一堆一堆加進來的,也有很多只是加進來讓你擺著好看的。我自己是很懶的寫太多我做不到的plan。年紀大了就變懶了。


在初步風險管理時,會以之前的專案經驗假設風險問題,且在計畫時盡量去避免負向的問題發生,去引導產生正向的問題.
不過這不簡單,如果有之前的專案參考還好,沒有的話這部分的執行必須會請求有相關經驗的人員做協助!

目前我們以滾動式規劃來進行,在監控專案時,pm必須要評量現在的專案進行是否偏移baseline;是團隊個人績效問題?客戶需求變更問題?外在不可預料問題?所造成的影響!隨時修改調整管理計畫,盡量在成本,時程,範圍與品質中做平衡!


reply to postreply to post
陷入無止盡的迴圈...
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:habbit]
eriklin





發文: 89
於 2007-04-20 13:17 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
habbit wrote:

簡單來說,我所要強調的是,沒有pm沒有收不收的問題,因為這個計畫書是由他主導提出的,說明未來他要如何管理專案!



隨便啦,我還沒看過哪個PM會主導出一個他自己不認可的計畫書

也許對你來說PM算是內部的人,只有認可不認可,對我來說
他是哪裡人根本不重要,他既然不是整本都自己去寫
就會有收不收別人寫的部份,
收部分的計畫書(某某Team寫出來他那個部份的計畫書)
你要說這是認不認可部分計畫書,不叫做收不收,那我也沒意見啦


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

換回來



發文: 416
於 2007-04-20 13: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
我怎麼覺得eriklin與habbit講的明明就是同一件事?Big Smile

Project plan 有需要別人input的地方,所以這會有一個怎麼樣產生內容的過程。至於要不要就這樣照單全收,有些公司或是有些比較小的案子,是PM自己決定,有些公司,或是比較大的案子,就會是call個meeting來討論簽字。

即使是開會出來的結論,是不是就直接照單全收,這通常也看PM或是公司的規定而定。PM如果覺得討論出來的東西有疑慮,自然會再call一個meeting,或是跟主要成員討論後再做出最後的定稿。當然,也有可能PM就自己把它幹掉啦。

我是覺得這種情況下,PM就比較像是記者,他會跑過來跟你訪問,問問你的意見,可是不見得會照你講的全部都刊上去,有些人可能會加上個聳動的標題,有些人會用不同的面向去切入。而要用什麼樣的材料產出最後的版本,那就看這個記者是怎麼寫了。

所以要不要收進來,有些公司可能會有比較嚴謹的process去規範,有些則是交由PM自己決定。可是本質上都是差不多的flow。


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

我的網站:diggirl.net

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

換回來



發文: 416
於 2007-04-20 14:06 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
waily wrote:
如果不會寫程式,那麼系統分析的時候,怎麼得知分析出來的結果,在程式開發上是可行的?

答案是,用問的。

我自己剛好是跨過client/server到web application的年代,所以在web剛興起時,很多案子的SA當然都沒有相關經驗。

對client/server架構來講,很多AP的假設都是client與server在同一個LAN上,所以傳輸極快,可是遇到web,就有一拖拉庫假設是全然不同的。

比如說企業內部在用的系統,很多人會希望我按個A,就把A相關的單號帶進來,有一個下拉式的選單出來,裡面的內容會隨你的input不斷去做filter。

這對client/server 在同一個LAN的程式來說,是piece of cake,可是在web application一開始時,這可是很難搞的東西。(現在AJAX盛行後GUI的interaction就比較好了倒是真的。)

那對SA來說,我可能玩了一輩子的MIS系統,可是我不會寫web application呀。那技術上到底辦不辦得到?事實上很多問題只要願意問就有答案。而PM就是要知道這種事情會發生,所以在SA進行SA時,要搭配一個懂技術的人跟他討論。

不過在剛好技術交替的年代裡面,很多專案就改用了懂得怎麼寫code,卻不太知道怎麼樣做SA的人去做SA。接下來就會跟用了不對的人去搞個NCC一樣地慘兮兮了。

術業本來就有專攻,而一日之所需,本來就是百工斯為備。身為一個管理者,其實是要知道,該怎麼樣把不同背景的人組成一個team,而不是讓每個人單打獨鬥。SA不懂的技術領域,就要找人去協助他解決這方面的問題。而不是說,要不你這個做了一輩子SA的人,快點去學寫Java程式吧。我們可能沒有這種美國時間去等一個夠格的SA去學到會。事實上也沒必要。


singlelog edited on 2007-04-20 14:10
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

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





發文: 89
於 2007-04-20 14:11 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:
我怎麼覺得eriklin與habbit講的明明就是同一件事?Big Smile

我也這樣覺得啊Big Smile


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

什么都不懂的小白

版主

發文: 540
於 2007-04-21 13:20 user profilesend a private message to usersend email to ray_linnreply 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 不等於 Team Leader
PM 最重要的是資源管理與計畫
管理職 也不等於行政
所謂的管理就是做好一件事的方法


PM管需求变更时候去靠妖,靠的市场部,你这个需求一变,我这里得拖延十天半月;

PM管到底要几个人月写代码, 人不够,就是变也要变出来.

PM管老板你要同意这个项目要拨款要预算;

PM管XXX按进度和经验,你应该在昨天就拿出东西, then tell me why?

PM还管产品出来之后如何跟市场沟通,如何培训跟进,如何算这个项目给公司带来多少赢收.

PM也许不懂系统问题出在哪里,却能找来大牛级的人来处理这个问题;更好的PM,可能系统还没上马,就可以预测出问题的所在,并要求提前防范.

PM还得管项目结束后,带这些人去吃吃喝喝看美女秀...

PM还得管,所有的人对项目没信心的时候,他还的装得信心满满, 满世界去想办法....


ray_linn edited on 2007-04-21 13:26
reply to postreply to post
飞翔的候鸟
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:what_is]
kenchu





發文: 128
於 2007-04-23 10: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
其實我的帳號
很明白的指出我是誰了
還需要某某麻
我同事都看過我寫的文章了
要吐我,我早被吐番了.,,
還用你來某某麻,這帳號這麼明顯了...
你說的人叫 ken 麻 後面是我的姓
這樣的帳號,連猜都不用猜了,一看就知道我是誰
我有時也不知道該怎說...

what_is wrote:
如果,kenchu 是某某(名字暫不透露)公司裡的那位仁兄(語氣、行為超像),則,那篇文章,麻煩請你當作參考用吧!!


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

秒速5センチメートル

站長

發文: 8415
於 2007-04-23 10:37 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
莫非是...朱孝天~
http://www.kenchu.com/

好吧我來冷的...orz..

以上題外話,
基本上請討論時針對問題討論
不要扯到題目之外的個人身上.
不然討論失焦,也會沒完沒了.

koji


koji edited on 2007-04-23 10:43
reply to postreply to post
JCConf Taiwan 2015 開始售票了!!
Facebook上的TWJUG社團,歡迎加入
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:chermanyen]
kenchu





發文: 128
於 2007-04-23 10: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
前幾天,因為趕程式,所以沒來看這討論串
我同事跟我說這個討論串還滿熱烈的
叫我看看

說真的,以我的背景,要求PM 要有技術對我來說,何難之有

有些人可能誤會我的話,我不是說PM阿貓阿狗都可以當
而是PM能力是屬於管理面而不是技術開發面
所以其能力應偏重在管理,而非技術
因培養其專案管理能力而不是技術開發能力
有技術當然也好,但做專案管理時反而應拋棄自己對技術看法
與軟體開發組進行溝通,讓技術部門管理技術,而不是,反而是pm領導軟體開發的危險狀態。
其原因是因為這樣會變成無法管理,因為開發者就是PM,PM又怎能監督自己開發得東西

把軟體管理當成專案管理則是把岳飛當張飛
兩者有差異,有興趣可以看看高鐵那偏
那篇就偏軟體管理。

正因為我懂技術,也作過專案管理
我才深知,如果我們一昧的依賴PM監督專案,監督開發技術
那最後會是災難。
因為這是一個沒有制度,沒有分工的專案
也就是一個無法監督與管理的專案
一個專案組織健全的專案
其專案品質是可以控制的,工作是可以分工的
品質是可以掌握的,而不是只有PM才知道專案的品質
當一個PM把計畫都擬訂好後,工作內容都清楚了
大家才知道怎準備,才知道怎分配時間,資源
怎麼管理進度,管理產出物。

這樣專案才能管理,所以專案最重要的一本文件,就是專案計畫
也是pm最重要的工作...
沒有專案計畫,一個專案根本無法管理..

如果一個一昧的依賴PM能力的專案,其品質只能依賴專案經理
專案情況 PM 說了就算
反正也沒人可以監督專案
但這樣的PM ,能同時處理幾個專案
萬一一個專案要花個三年
期間PM都說沒問題,等到要結案了
...一堆問題都跑出來了...
這樣的人是公司的資產嘛這種風險真的是公司可以承受的麻?

專案成敗都維繫於一人身上
如果PM走了呢
公司剩下什麼 ?
專案是否無以為繼 ?
只能讓專案失敗麻
一個沒有計畫可以參考得計畫
要其他人如何配合

如果專案經理對技術的深入大於軟體開發組長
甚至介入軟體開發中
那專案如何監督 ?

是我們要求PM要懂技術? 還是PM的工作包含要做技術部門的事 ?
還是資訊業的PM只能從工程師中挑一個 ?
我們該建立資訊公司的制度還是努力培養一個強而有力的PM ?
讓工程師可以在工程方面有所發揮
還是工程師幹久了,當了PM 就自然而然會專案管理

是希望工程師可以更專研技術
而PM能專研專案管理
兩個透過制度,取得合作的模式

還是逼
搞技術的得去搞客戶,搞專案
讓搞專案的得去搞技術
搞到一蹋糊塗

還是要像現在這樣,幹了幾年工程師,沒升起來幹pm 幹技術經理就好像沒出息一樣,而不是有一條資深工程師、系統分析師、技術總監的工程師伸遷管道
哪個對公司對軟體業是好的 ?
對我們現狀有改善 ?

大家不妨思考看看 ...
為什麼我們都會要求PM要懂技術 ?
是因為我們沒有人可以幫忙PM處理技術這段
沒有人可以幫助PM處理品管,處理構型
還是因為本來這些就應該是PM做的事
如果不是,何以要求PM要有幾年的專案開發經驗
要懂技術 ??
何以不是要求一個PM要懂專案管理,懂計畫擬訂執行,懂管理,懂溝通,懂協調

說穿了
不正是因為我們的軟體業根本沒有制度可言
才會逼著PM ,其實是做軟體開發的事
做的是軟體開發組組長的工作
而不是帶領整個專案組織的工作

這難道不是我們軟體業最大的痛
而大家卻一直認為這樣是對的 ?


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





發文: 128
於 2007-04-23 11: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
真是說到我的心坎裡了

不過至少有寫專案計畫
有把這些問題記下來
要靠腰也比較大聲

ray_linn wrote:
PM管需求变更时候去靠妖,靠的市场部,你这个需求一变,我这里得拖延十天半月;

PM管到底要几个人月写代码, 人不够,就是变也要变出来.

PM管老板你要同意这个项目要拨款要预算;

PM管XXX按进度和经验,你应该在昨天就拿出东西, then tell me why?

PM还管产品出来之后如何跟市场沟通,如何培训跟进,如何算这个项目给公司带来多少赢收.

PM也许不懂系统问题出在哪里,却能找来大牛级的人来处理这个问题;更好的PM,可能系统还没上马,就可以预测出问题的所在,并要求提前防范.

PM还得管项目结束后,带这些人去吃吃喝喝看美女秀...

PM还得管,所有的人对项目没信心的时候,他还的装得信心满满, 满世界去想办法....


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





發文: 128
於 2007-04-23 11:41 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懂技術,那我就要要求到要有技術經理一樣的等級
不然憑什麼做出正確的判斷 ?
懂皮毛那不是更慘,更難正確判斷

我想這是我們之間的歧見
但這也是我看過太多專案失敗的主因

singlelog wrote:
eriklin,

你說的沒有錯。如果這個案子很大,PM 本來就要去補一下這方面的knowledge。

不過也只是knowledge而已,從技術人員的角度來看,他是不懂技術的。不過從外人的角度來看,他是懂技術的。

不過就我的定義來看,我覺得他有這方面的了解與認知,可是一個PM懂不懂技術,要看他的這個了解與認知有沒有辦法幫他做出正確的決策。而正確的決策,其實受到專案管理與軟體工程方面知識與能力的影響比較多,受到純粹工程師所定義的”技術”這方面的knowledge了解深不深入比較少。


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

秒速5センチメートル

站長

發文: 8415
於 2007-04-23 11: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
我認為這樣有點太過偏激了
我自己遇過的pm有很懂也有懂一點的
就剛好相反, 懂一點的反而肯去聽,並且技術人員解說之後可以信任技術人員的方式
懂很多的反而認為自己最對,要求技術人員優先考量他的想法
最重要是那個pm懂得自己的立場吧,
當然我也是比較支持至少懂一點技術比較好,因為這樣當有問題時我門跟他解釋時他也可以大概了解問題所在.
我並不認為懂跟跳下來做是必然關係,
懂技術不一定要跳下來做,他只需要懂我們在幹麻就好

koji

kenchu wrote:
我個人認為
懂一點,比都不懂還慘
懂一點技術的PM ,常常固執己見
不尊重技術部門
然後胡亂答應客戶要求
反而都不懂的,還會帶技術人員去協助

如果要PM懂技術,那我就要要求到要有技術經理一樣的等級
不然憑什麼做出正確的判斷 ?
懂皮毛那不是更慘,更難正確判斷

我想這是我們之間的歧見
但這也是我看過太多專案失敗的主因


reply to postreply to post
JCConf Taiwan 2015 開始售票了!!
Facebook上的TWJUG社團,歡迎加入
作者 Re:有沒有不會寫程式卻在做系統分析的? [Re:eriklin]
kenchu





發文: 128
於 2007-04-23 11: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

所以PM做PM得事
累積PM的經驗
我想專案計畫書
並沒有需要有技術背景得人才能寫吧
不過通常一本計畫書
都不是PM一人獨力完成到是真

eriklin wrote:
專案計畫書,專案計畫書

這本書到底是哪來的,上帝傳真過來的神諭?

還不是PM要去寫

沒有相關經驗的PM,有辦法寫出來嗎?

就算要去改現有的計畫書

問題是,沒有兩個專案是完全相同的,寫書的PM還是要依照他的專案的情況來調整

找一個沒經驗的人來寫,寫的出來嗎?

也許會有一個Team,獨立於專案之外,來寫這本書

那好了

你是老闆,你會從寫這本書的Team裡面找個人來當PM

還是已經有這本書了,所以PM就可以省點錢了?


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





發文: 128
於 2007-04-23 11: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
其實每種案例都有
要說好的有好的
要說壞的有壞的

我們很難預期結果是好的還是壞的
只能把風險降到最低

不過我說的內容,是針對孤獨木大大的內容
因為他認為PM要懂技術才能幫助做出正確的決定
而這技術卻不是很深入的懂
只是概略
那這樣一來風險是否變得很大
所以與其懂皮毛的風險與都不懂的風險
兩個要取一,我會取都不懂然後把技術都交給技術部門處理

當然我說得滿偏激的
因為不是都是這樣
也不是一定都這樣

但多數例子是這樣,所以能避免就避免得好

koji wrote:
我認為這樣有點太過偏激了
我自己遇過的pm有很懂也有懂一點的
就剛好相反, 懂一點的反而肯去聽,並且技術人員解說之後可以信任技術人員的方式
懂很多的反而認為自己最對,要求技術人員優先考量他的想法
最重要是那個pm懂得自己的立場吧,
當然我也是比較支持至少懂一點技術比較好,因為這樣當有問題時我門跟他解釋時他也可以大概了解問題所在.
我並不認為懂跟跳下來做是必然關係,
懂技術不一定要跳下來做,他只需要懂我們在幹麻就好

koji


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





發文: 128
於 2007-04-23 12:02 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
您說的都是現實面
只是制度立意都好
但執行與否才是關鍵

身為一個台灣人
我們的文化是人治還是法治 ?
多少好得制度在台灣窒礙難行
其原因不是制度不好
而是我們都不願意去做

但坦白說
如果我們要做一個像 windows 一樣大的專案
一個太空專案....
沒有這些制度的話...
真有能力做得出來嘛 ?

我們可以維持現狀,我們可以從我們這些人開始做起
一念之間...

poshoung wrote:
說到cmmi管理,忍不住想插點嘴

話說前頭,我壓根沒有正統的學過cmmi
一切都是在旁邊看公司搞的印象
所以有錯請不吝賜教

cmmi在我的印象中是個很偉大的制度
把"軟體專案"切割成許許多多的功能作業與階段
再用許許多多的文件,確認書,說明書,評量表
追朔表。...etc來串接,評量,監督這些階段與作業的進行。
用意本是良善
偏偏台灣的環境,有幾個專案是經過詳細的評估有足夠的工時的?
評估沒做好,需求就沒有收斂,造成工時過份樂觀,最後deadline臨頭
第一個milestone來臨時,PM拿鞭子請您把文件交出來時。
明明昨天還在跟客戶夜間的聯誼活動後的宿醉中,今天突然間像變魔術一樣
出現一本熱騰騰的文件。其內容品質也許非常cmmi
但是真的是有用的東西嗎?

第一本不行,接下來的環環相扣後面就不用贅述了。

也許管理之所以是門學問就是在於沒有任何方法可以管的住人性吧
不管在上的貪婪鄉愿或是在下的蠢鈍偷機


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

換回來



發文: 416
於 2007-04-23 15:02 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,PM又怎能監督自己開發得東西

我想請教一點,你明明是懂技術的人,可是什麼叫做拋棄自己對技術的看法?

這一點是我覺得最不可思議的地方。我們如何在進行管理時,把自己懂的東西拋棄?

如果你指的是,不要有成見,不要有先入為主的觀念,那跟拋棄自己對技術的看法,這是一樣的東西嗎?

讓技術部門管理技術,跟你自己懂技術,這兩者有因果關係嗎?

為什麼每次我很明確的問你有沒有因果關係時,從來沒有得到答案呢?

因為到現在還會各說各話,最主要的關鍵,就是我覺得這種推理完全沒有邏輯的必然性在裡面。

一個PM有了技術,就不會讓技術部門管理技術嗎?就不會與軟體開發組進行溝通嗎? 如果這中間沒有邏輯上的因果與必然關係,那你的命題會是正確的嗎?

到現在為止還是不斷地重複做這樣的推理,為什麼一個懂技術的人,而不是說一個拙劣的管理者,不會放手讓技術部門管理技術呢?

PM領導軟體開發一定是危險的狀態嗎?如果案子很小,如果他就剛好是有能力的人,如果他要管理的案子不複雜,這有什麼問題嗎?

如果案子很大,那他不懂技術可以當到PM?

我是覺得,一個好的PM,需要有管理能力,也要有技術背景。當然啦,更高階的主管就不一定要有技術背景。可是真正帶隊的,沒技術背景其實很難把事情做好。而能不能把事情做好,最重要的重點當然是管理方面的能力。

遇到很大的案子還要自己身先士卒的人,是個愚蠢的PM。就像諸葛亮把自己累死,到底是爽到誰?他就算是一個很笨的PM。
kenchu wrote:
把軟體管理當成專案管理則是把岳飛當張飛
兩者有差異,有興趣可以看看高鐵那偏
那篇就偏軟體管理。

把軟體專案管理當做是專案管理,那應該算是把張菲當做是張飛囉?

軟體專案管理跟專案管理本來就分屬不同的領域。光是以專案管理的角度來看軟體專案管理,完全沒有考慮到軟體開發的特質,這樣的PM就會覺得懂不懂技術都沒差了。

我是覺得在這個業界裡面,最大的問題,就是外行領導內行,不懂的人又裝懂。我其實懂的很有限,不過我面對我不懂的事情,我其實就蠻坦白地承認這個我不懂。不過有些不懂的人就喜歡裝懂。似是而非的言論很多,要是拜託他們解釋他們高妙的推論中,各種推理的邏輯性,又顧左右而言他,只能請別人再去看看他們的計畫書。

以前我也遇過不少這種老闆,他們就喜歡引不知何處聽來的經典。然後每次我們要他們解釋他們的高明遠見,通常第一句話就是,這你們不懂啦。事實上,要是一個人沒有辦法把他想推理的過程表達的很清楚,我看,還是去做業務,或是只會陪客戶上酒家的PM比較適合。這個產業的PM很多種,不會技術,可是會陪客戶出去淫樂的PM,一樣可以把案子結掉。沒有人要求PM一定要具備清楚的頭腦。
kenchu wrote:
正因為我懂技術,也作過專案管理
我才深知,如果我們一昧的依賴PM監督專案,監督開發技術
那最後會是災難。
因為這是一個沒有制度,沒有分工的專案
也就是一個無法監督與管理的專案

如果你是一家大公司,會給不懂技術的PM很多協助,你覺得,這家公司會一昧的依賴PM監督專案,監督開發技術嗎?

我從來沒遇過這樣的大公司。

我遇過的大公司,都是有很多人不斷透過各個層級在針對專案進行控管。可是也由於這樣的大公司控管謹嚴,對於比較執行面的PM的技術要求很高。至於比較偏管理面的PM,大多也都是從下面一路爬上去的。

偶爾有那種什麼技術都不懂的歸國博士,通常就是講的一嘴好專案。會被那些懂技術的嫌到死,通常也真的就是一個專案的毒瘤。

我雖然待過的大公司不夠多,不過客戶倒是有那種全台最大晶圓代工公司之類的大企業。要做他們一些案子,常常要面對各個不一樣的監督單位。而且,要是PM不懂技術,我看馬上就被趕出來了。

kenchu你都不舉實例,你自己既然是懂技術的人,可以請教一下到底哪個公司,是採取你的管理模式呢?還是說那個大師是建議我們照你的方法這樣做呢?

至於有沒有制度,有沒有好的分工,這跟公司怎麼去管理他們的軟體開發流程有關,跟 PM的技術,有什麼關係嗎?

你所講的,一直是這個人有了技術就會有什麼樣不好不好的弊病。可是這些弊病,其實都是這家公司的process不對,沒有把權責區分好,這跟裡面用的人技術能力太高之間可以畫上等號嗎?

我是覺得不要倒果為因。一家公司沒把software development process弄好,卻怪東怪西怪到PM技術能力太好身上,自己不會生還牽託厝邊(鄰居),這種公司就不用待了啦。

kenchu wrote:
一個專案組織健全的專案
其專案品質是可以控制的,工作是可以分工的
品質是可以掌握的,而不是只有PM才知道專案的品質
當一個PM把計畫都擬訂好後,工作內容都清楚了
大家才知道怎準備,才知道怎分配時間,資源
怎麼管理進度,管理產出物。

這樣專案才能管理,所以專案最重要的一本文件,就是專案計畫
也是pm最重要的工作...
沒有專案計畫,一個專案根本無法管理..

我最近這兩年都在自己開發軟體產品。我必需坦承,我們沒有project plan。我們有充份的溝通,我們也有產出,我們的產出具有一定的品質,可是我們沒有project plan。我們最完整的文件是source code。

該有什麼feature是用討論討論出來的結果。該做什麼東西只有很模糊的想法。有時候PM,也就是我,說服不了Programmer,我自己又沒有動手寫,我們就沒有這個feature。

這個專案,可能也不算專案啦,沒有被管理嗎?Well,這就看你的角度是怎麼想了。我在一開始要規劃process時,就刻意依照我們的特性,採用比較偏向extreme programming方式的開發流程。目前為止,對於我們這種還在跌跌撞撞摸索使用者需求的網站還不錯。

我花時間去寫project plan 會比較好嗎?To me, defeinitely not.

當然,每個案子都不一樣,所以,有的PM比較好命,只要坐在家裡面寫project plan 就好了。不過對於那種寫了很多project plan的PM來說,寫project plan只是piece of cake。要是你做的管理就是寫一本project plan,那只能說,你的命很好。
kenchu wrote:
如果一個一昧的依賴PM能力的專案,其品質只能依賴專案經理
專案情況 PM 說了就算
反正也沒人可以監督專案
但這樣的PM ,能同時處理幾個專案
萬一一個專案要花個三年
期間PM都說沒問題,等到要結案了
...一堆問題都跑出來了...
這樣的人是公司的資產嘛這種風險真的是公司可以承受的麻?

專案成敗都維繫於一人身上
如果PM走了呢
公司剩下什麼 ?
專案是否無以為繼 ?
只能讓專案失敗麻
一個沒有計畫可以參考得計畫
要其他人如何配合

我只是想問你,你舉的這個例子,是因為PM有沒有能力造成的,還是因為你們專案內控制度沒有建立起來而造成的?如果你們的PM沒有技術能力,可是內控制度也付之闕如,本來要是他懂點技術,還有人知道狀況,現在又沒有懂技術的PM,是不是就死得更快?

我是一直覺得你倒果為因。講的都是專案內控制度沒有建立起來,可是卻把矛頭都指向是因為PM有技術,所以沒有專案內控制度。沒有專案內控制度,就純粹是高階主管怠惰短視的結果。不能跟PM有沒有技術扯上因果關係。

kenchu wrote:
如果專案經理對技術的深入大於軟體開發組長
甚至介入軟體開發中
那專案如何監督 ?

是我們要求PM要懂技術? 還是PM的工作包含要做技術部門的事 ?
還是資訊業的PM只能從工程師中挑一個 ?
我們該建立資訊公司的制度還是努力培養一個強而有力的PM ?
讓工程師可以在工程方面有所發揮
還是工程師幹久了,當了PM 就自然而然會專案管理

是希望工程師可以更專研技術
而PM能專研專案管理
兩個透過制度,取得合作的模式

還是逼
搞技術的得去搞客戶,搞專案
讓搞專案的得去搞技術
搞到一蹋糊塗

還是要像現在這樣,幹了幾年工程師,沒升起來幹pm 幹技術經理就好像沒出息一樣,而不是有一條資深工程師、系統分析師、技術總監的工程師伸遷管道
哪個對公司對軟體業是好的 ?
對我們現狀有改善 ?

大家不妨思考看看 ...
為什麼我們都會要求PM要懂技術 ?
是因為我們沒有人可以幫忙PM處理技術這段
沒有人可以幫助PM處理品管,處理構型
還是因為本來這些就應該是PM做的事
如果不是,何以要求PM要有幾年的專案開發經驗
要懂技術 ??
何以不是要求一個PM要懂專案管理,懂計畫擬訂執行,懂管理,懂溝通,懂協調

說穿了
不正是因為我們的軟體業根本沒有制度可言
才會逼著PM ,其實是做軟體開發的事
做的是軟體開發組組長的工作
而不是帶領整個專案組織的工作

這難道不是我們軟體業最大的痛
而大家卻一直認為這樣是對的 ?

你有沒有待過有良好制度的公司?你知不知道在這樣的公司裡面,PM需要有多高的技術背景?如果你待的公司都是沒有制度的公司,我很同情你的遭遇,可是就請你不要再繼續放大你的不幸,找一家有制度的公司吧。

我自己看過很多有制度的大公司,也待過有規模有制度的公司。而我在這種比較大型公司裡面看到的是,PM的技術背景其實還蠻重要的。原因很簡單,我們沒有那個美國時間等一個不懂的人聽到懂。通常只有老闆具有這樣的特權,可是要是講什麼action item,這個PM都一臉茫然,換一個比較快。

並不是所有的工程師都適合,也都想要走管理職系的工作。事實上很多不會處理人際關係的工程師,還是當一輩子工程師比較合適。可是想要走軟體專案管理這條路的朋友,你們需要多方面的能力。專案管理方面的知識,加上軟體工程的學問,加上怎麼處理人事問題的能力都是很必要的。

工程師沒有一條持續專注在工程職系的一條路可以長遠走下去,這是台灣很多軟體公司的問題。可是把一個不適任的人放在專案經理這個位子上,這個影響更大更嚴重。我是覺得,很多問題不要通通攪在一起當做是同一個原因造成的。因為明明就是不同的事情,工程師如果除了PM沒別的路可以走,這件事跟PM要懂技術有什麼因果關係嗎?我覺得兩件不同的事情,硬扯在一起講,以為可以混淆視聽,事實上就毫無因果的邏輯可言。

你要是覺得自己沒辦法fire一個人,沒辦法帶領一個team,那可能你就要認真想一想,你有沒有當PM的特質。光是會寫專案計劃書,這絕對是不夠的。


singlelog edited on 2007-04-23 15:13
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

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

換回來



發文: 416
於 2007-04-23 15:42 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
我把我的問題再精煉一下好了。

1.PM沒有專職管理,反倒跳進去參與開發,結果把一個大案子弄死了。這跟PM不需擁有技術能力就可以當好PM,可以畫上等號嗎?

2.公司沒有專案管理與內控制度,所以只有PM一個人知道進度與狀況,一離職公司就垮了。這跟PM不需擁有技術能力就可以當好PM,可以畫上等號嗎?

3.公司沒有為技術人員規劃一條長久走技術的路,導致工程師都想往管理職系上面靠攏。而公司也任用了一些缺乏管理能力的工程師來當PM,結果把專案做的七零八落的。這跟PM不需擁有技術能力就可以當好PM,可以畫上等號嗎?

我是覺得你的這幾樣推論,通通都把一些不相干的事都拖進來。就好像藍綠在討論要不要讓軍購案過,拿中選會組織法要不要政黨比例制把它綁在一起一樣。這樣的討論是不會有交集的。因為今天拿NCC綁軍購,明天拿中選會綁軍購,後天再拿總統候選人被起訴到底會不會喪失候選人資格綁軍購,這樣下去真正的問題根本就碰觸不到。

你要是覺得PM擁有技術跟這些東西都有因果關係,那就把論述著重在怎麼建立因果關係這一塊。

每個人都同意,軟體公司應該要建立制度。可是軟體公司應該要建立制度,跟PM不需要懂技術之間,中間有什麼必然性,這是你的論點的精華所在。所以應該著重在這一塊,而不是一而再再而三的告訴大家,台灣軟體公司的弊病就在於沒有建立制度。這個很重要,應該要懂建立制度,公司才會長治久安,才可以創造世界大同。

你要是沒有建立這中間邏輯的必然性,那這兩個就該被視為獨立事件。『軟體公司應該要建立制度』就不可以拿來當做支撐『PM不需要懂技術』這個論點。我覺得這是基本的邏輯概念。討論應該本於這樣的精神才對。

你可以繼續迴避這樣直接的質問,或者要我再去看哪位大師所寫的專案計劃書。不過如果是這樣的話,就請恕我不再回應了。因為我覺得如果完全不講邏輯概念的話,再講下去就沒有什麼意思了。


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

我的網站:diggirl.net

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

什么都不懂的小白

版主

發文: 540
於 2007-04-23 17:39 user profilesend a private message to usersend email to ray_linnreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我们知道一个项目大概分为:
concept, profile, planning, implement, deployment, post-deployment几个阶段...这好象是四海都准的东西.

那PM在哪里运用自己的技术背景呢, 我个人觉得是从concept -- planning,就足够了:

有技术,可以更好的理解项目的风险所在;
可以不会被PE虎烂,明明一天能搞定,非要拿个5天;
可以和各个相关团队更好的沟通, 兜售自己的想法;

.
但是一旦进入implement ,也就是叫工程师干活的时候, 千万淡化自己的技术色彩,除非除非是万不得已.


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

什么都不懂的小白

版主

發文: 540
於 2007-04-23 17:42 user profilesend a private message to usersend email to ray_linnreply 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更多是以团队职能为导向, 比如跟市场部, 财务部, 开发部去靠妖的人

SA更多是以程序智能为导向的


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

換回來



發文: 416
於 2007-04-23 18:16 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
planning, implement, deployment, post-deployment這都需要PM呀。Big Smile

你要去看看所有的process是不是照你plan的在走,專案的進度是不是照你規劃在走,然後要做各式各樣的事情讓專案回歸正軌。 Plan / Assessment / Action 。大概就是這樣的循環。我們以往常常是說就是在monitor專案,其實就是在看有沒有什麼意料以外的事情。有些人是說在做risk management,事實上這些事情就是在考驗專業判斷。

如果只會planning,不會control,也不知道take一個action之後,可能要面對什麼樣的狀況,這就淺了。就像醫生要開處方,要先知道病情是什麼,可以開立的藥方有哪些,每種藥有沒有什麼禁忌,吃了以後有沒有後遺症,如果產生併發症,需要進行什麼進一步的處理。

當然啦,有些人會相信,在夠大的醫院裡面,有良好的開藥輔助資訊系統,有藥理學的課本可以翻,醫生只要會依照門診看診計畫書就可以治病了。最好醫生不要懂得病理學,藥物學...(我也不知道還有什麼專門的學問。)只要會寫門診看診標準作業程序就可以了。開錯藥反正還有藥劑師在把關。

我是覺得醫生懂得越多越好。我不會想說有什麼不要把所有的醫術押在一個人身上。只要這個醫生走了就會是醫院損失之類的。每個好的醫生都需要有治病的能力,他離開一家醫院,醫院不會垮掉,可是醫院多少都會受影響。我是沒聽過哪家醫院的院長會說,要是醫生都走光了,那我的醫院就垮了,所以要用些不懂醫術的醫生來看病。只有聽說要是這個大牌走了,就去別家挖個臺柱回來。

那為什麼要幫專案找醫生,得要找個不懂醫術的人來當醫生呢?

當然啦,你可能會說,醫生比較像是team leader而不是PM。你心目中的PM不是專案的醫生,比較像是掛號排門診的系統。只要管排resource就好。

我自己是不知道啦,為什麼我們就可以把醫療這件事綁在醫生身上,卻不能把專案的成敗綁在專案經理身上?我也不知道的是,如果PM就成了個門診掛號系統,整天在看的就是這個醫生要接多少客,有沒有達到預定的milestone,那還要這個PM幹嘛?弄台電腦來就可以了嘛。


singlelog edited on 2007-04-23 18:39
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

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





發文: 89
於 2007-04-23 22: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
kenchu wrote:
但坦白說
如果我們要做一個像 windows 一樣大的專案
一個太空專案....
沒有這些制度的話...
真有能力做得出來嘛 ?


這段有疑問....<舉手發問狀>

是先有CMMI或是其他的制度後,才有Windows.....等等專案
還是先有這些專案了,才去歸納出這些制度,覺得在這次專案跑起來還不錯的東西
下次可以重施故智,覺得不順的地方,想想看要下次要怎麼避免.怎麼改進?


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

換回來



發文: 416
於 2007-04-23 23:02 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:
但坦白說
如果我們要做一個像 windows 一樣大的專案
一個太空專案....
沒有這些制度的話...
真有能力做得出來嘛 ?

咦,我也漏看這一段。

我有一本已經絕版的書,叫做憂鬱巨人-IBM (Big Blues - The Unmaking Of IBM)

這本書講到IBM怎麼樣在個人電腦的戰役中節節敗退。把一個大好的江山拱手讓給了微軟跟intel。

很諷刺的是,IBM就是當時standard process的代名詞。他們用非常嚴謹的開發方式在開發系統,所以開發的時間總是經年累月。每套軟體都要經過內部千鎚百鍊才會出來,然後是開發速度緩慢。

而當時的微軟則像是西部牛仔一樣,擁有許多個人風格非常強烈的天才程式設計師。他們不愛寫文件,可是智力高超。

IBM用line of code來計算生產力,微軟的工程師則是用最精簡的行數來寫出優美的程式。IBM的專案主管會畫出非常精妙的投影片,來證明微軟的生產力是負的,因為他們把程式碼的行數變少了。微軟的工程師則都是瞧不起,IBM的manager們只會打嘴砲,講的一口好程式。

執行同樣的功能,微軟的工程師寫出來的就是跑得比較快。所以,當IBM傾全公司之力投入OS/2的開發時,微軟則是一邊協助開發 OS/2,一邊在dos上面架個windows 3.1。

其實這段歷史也沒有太久,所以堂堂正正的IBM大軍被幾個聰明的天才組成的microsoft打敗。這件事到現在還是蠻有參考的價值。

我是不知道,yahoo/microsoft/google哪一家,在一開始起來的時候是有什麼standard development process,不過等到公司大了,可能制度就會完善一些。不過許多優美的系統,在剛起頭開發時,還真是沒有遵循什麼嚴謹的開發方式呀。

當你的團隊量小質精的時候,每個人如果數學能力又強,腦袋又清楚,寫起code來可是優美的不得了。

當然,對很大型的系統來說,因為聰明的人不夠多,就不得不寫出很多文件來以幫助溝通。不過如果變成這樣的話,這就累了。像是這樣的時候,就不得不有很多人員會參與進來。不過在這種時候,要是這個專案不找以往有開發這套系統經驗的人來當PM,反倒找個技術白癡進來,我一定會懷疑,這家公司的管理階層是不是瘋了。

太空專案可能就不太一樣,有聽過在車庫創業弄間軟體公司起來,沒聽說過在車庫創業發射艘太空梭進太空。所以這就是為什麼,軟體專案管理跟一般的專案管理不一樣的地方。


singlelog edited on 2007-04-23 23:50
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

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

什么都不懂的小白

版主

發文: 540
於 2007-04-24 12:13 user profilesend a private message to usersend email to ray_linnreply 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:
planning, implement, deployment, post-deployment這都需要PM呀。Big Smile

你要去看看所有的process是不是照你plan的在走,專案的進度是不是照你規劃在走,然後要做各式各樣的事情讓專案回歸正軌。 Plan / Assessment / Action 。大概就是這樣的循環。我們以往常常是說就是在monitor專案,其實就是在看有沒有什麼意料以外的事情。有些人是說在做risk management,事實上這些事情就是在考驗專業判斷。

如果只會planning,不會control,也不知道take一個action之後,可能要面對什麼樣的狀況,這就淺了。就像醫生要開處方,要先知道病情是什麼,可以開立的藥方有哪些,每種藥有沒有什麼禁忌,吃了以後有沒有後遺症,如果產生併發症,需要進行什麼進一步的處理。

當然啦,有些人會相信,在夠大的醫院裡面,有良好的開藥輔助資訊系統,有藥理學的課本可以翻,醫生只要會依照門診看診計畫書就可以治病了。最好醫生不要懂得病理學,藥物學...(我也不知道還有什麼專門的學問。)只要會寫門診看診標準作業程序就可以了。開錯藥反正還有藥劑師在把關。

我是覺得醫生懂得越多越好。我不會想說有什麼不要把所有的醫術押在一個人身上。只要這個醫生走了就會是醫院損失之類的。每個好的醫生都需要有治病的能力,他離開一家醫院,醫院不會垮掉,可是醫院多少都會受影響。我是沒聽過哪家醫院的院長會說,要是醫生都走光了,那我的醫院就垮了,所以要用些不懂醫術的醫生來看病。只有聽說要是這個大牌走了,就去別家挖個臺柱回來。

那為什麼要幫專案找醫生,得要找個不懂醫術的人來當醫生呢?

當然啦,你可能會說,醫生比較像是team leader而不是PM。你心目中的PM不是專案的醫生,比較像是掛號排門診的系統。只要管排resource就好。

我自己是不知道啦,為什麼我們就可以把醫療這件事綁在醫生身上,卻不能把專案的成敗綁在專案經理身上?我也不知道的是,如果PM就成了個門診掛號系統,整天在看的就是這個醫生要接多少客,有沒有達到預定的milestone,那還要這個PM幹嘛?弄台電腦來就可以了嘛。


no no ,从conecpt 到post deployment都是pm handling的东西, 偶只是在谈pm啥时候要强化技术背景,啥时候要淡化技术背景.


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





發文: 0
於 2007-04-24 22:41 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 最後以邏輯的觀點,批評kenchu的論述沒有邏輯,並不能証明懂技術和做不好pm的工作兩者之間有必然性。
可是同樣的檢驗singlelog的觀點,也並不能說建立了懂技術=好PM之間的邏輯關係,大部份都直接給答案並訴諸經驗,但經驗太受限於個人生活的軌跡,並不是邏輯的論証,和kenchu要大家去看書中的內容在本質上並無太大的不同,而且受限於個人經驗反而無法驗証,況且有這個經驗因個人觀點而詮釋出來的結果也是因人而異的。
所以我認為必須以要求kenchu的態度來要求singlelog本身也做好確實的論述才能說服持不同觀點的人。
另外singlelog 最後提醫生的例子,但在我的認知裡開藥看病的醫生比較像是專業人員而不像PM,這似乎也是個混淆視聽的例子哦


reply to postreply to post
(Total 33 pages)  
go to first page go to previous page  6   7   8   9   10   11   12   13   14   15   16  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