[專案管理]弱勢專案管理與技術牛人的對抗問題延伸討論

發信人: chaobill (若我離去,後會無期), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Tue Nov 17 11:05:37 2009), 站內

一個專案裡面必須有人全懂
PM 至少要懂一些專案是什麼劃分的
舉個例子，你會讓一個 IT PM 去管理一個建築專案麼？
【 在 qingrun (青潤) 的大作中提到: 】
: 是的，技術的強弱有時候是有促進作用的，前提是PM頭腦清晰，不陷入自己對自己的過度信任中。
: 我這麼提也主要是為了反駁國內曾經一度十分盛行的所謂專案經理必須懂技術甚至必須是這一行業技術高手的說法和認識。呵呵


※ 來源:·水木社群 newsmth.net·[FROM: 211.99.222.*]

發信人: qingrun (青潤), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Tue Nov 17 11:38:01 2009), 站內

這一點你錯了，一個專案裡面不需要有人全懂，關鍵在於PM如何做。呵呵
你的那種想法，六七年前我也如此考慮，後來發現，根本是沒有必要的。
例子：
我， 本科學材料的，出來做軟體開發，05年進入自動化所模式識別實驗室做專案經理，軟體架構師。後續的專案都在我手裡做管理和開發，所有的專案進展都應該算是 很順利，剛開始的一些對抗三四個月後就被化解了，到現在關係都非常好，06年7月份離開自動化所後，這些弟兄一直在和我合作到現在。
難道說我全懂麼？至少兩年前我都沒有看到過模式識別方面的程式碼，也不可能懂得動態背景建模和一些高斯演算法如何處理的東西，但是，我一樣做好了我的角色。呵呵。
管理不是那麼弱小的東西，可以這麼說，隨便給我一個行業的專案，我都有能力做好，因為這是一個專案管理中處理事務的手段，而不是虛誇的一種操作方法。
再 早一些，我02年8月底進入電信某設計院，10月11號就帶著一個人一同去中國電信集團進行建設流程調研，四個月後我撰寫的技術、業務規範一次評審通過， 得到了很高的評價，就這五個月的兩篇文章就是50萬。各省公司和集團的那些老大都沒有認為我是個剛進入電信行業的人，才進入兩個月就敢過來調研他們最核心 的業務之一，進行規範的撰寫和定義。呵呵，03年3月電信集團直接打電話要求我去北京負責這個專案的實施，然後就給我辦了借調，前期是非正式的，04年1 月給我辦了正式借調，這在電信集團是從來沒有過的，以前的正式借調都只有省市公司的，三產這類企業的員工根本不可能辦理的。
【 在 chaobill (若我離去,後會無期) 的大作中提到: 】
: 一個專案裡面必須有人全懂
: PM 至少要懂一些專案是什麼劃分的
: 舉個例子，你會讓一個 IT PM 去管理一個建築專案麼？

--

※ 來源:·水木社群 http://newsmth.net·[FROM: 162.105.244.*]

發信人: wohutu (什麼也沒有), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Tue Nov 17 11:50:20 2009), 站內

同意你的

【 在 qlw (錢五哥) 的大作中提到: 】
: 同意qingrun的說法，我看到這個案例後的第一反應就是將大牛的方案
: 放入下個版本，不影響本次開發，但是在接下來的開發中要考慮到大牛
: 的建議，便於將程式碼重用到下個版本，同時也讓專案組成員逐步熟悉
: ...................

--

※ 來源:·水木社群 newsmth.net·[FROM: 123.116.117.*]

發信人: kabbesy (Arthas), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Wed Nov 18 09:41:46 2009), 站內

zan!

【 在 zhangmike (秦月) 的大作中提到: 】
: 我的建議：
: 1，測試或判斷當前關鍵功能的效能指標，如果能夠滿足12-31的要求，與大牛溝通，暫停重構。 沒有一鍵編譯和冒煙測試，重構的風險過大。
: 2，書面記錄重構和技術難點與及大牛兼職工作的風險，與上級交流。
: ...................

※ 來源:·水木社群 newsmth.net·[FROM: 114.243.227.*]

發信人: kabbesy (Arthas), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Wed Nov 18 09:47:29 2009), 站內

牛人！
最起碼是牛的管理人員
不過我還是支援：“好的管理者必須專業，最起碼儘量專業”  這個論點

“隨便給我一個行業的專案，我都有能力做好”有點言過了

【 在 qingrun (青潤) 的大作中提到: 】
: 這一點你錯了，一個專案裡面不需要有人全懂，關鍵在於PM如何做。呵呵
: 你的那種想法，六七年前我也如此考慮，後來發現，根本是沒有必要的。
: 例子：
: ...................

※ 修改:·kabbesy 於 Nov 18 09:48:17 2009 修改本文·[FROM: 114.243.227.*]
※ 來源:·水木社群 newsmth.net·[FROM: 114.243.227.*]

發信人: qingrun (青潤), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Wed Nov 18 09:53:38 2009), 站內

最起碼儘量專業也代表你已經同意我的觀點了。我是一個實踐人員不是一個理論推行者，所以，沒有那麼高的噱頭，只有操作過的例項。
至於後面那句，隨便大家看待吧。呵呵
【 在 kabbesy (Arthas) 的大作中提到: 】
: 牛人！
: 最起碼是牛的管理人員
: 不過我還是支援：“好的管理者必須專業，最起碼儘量專業”  這個論點
:
: “隨便給我一個行業的專案，我都有能力做好”有點言過了

--
我很傻，但是我很能幹
個人blog：blog.csdn.net/qingrun

※ 來源:·水木社群 http://newsmth.net·[FROM: 162.105.244.22]

發信人: kabbesy (Arthas), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Wed Nov 18 10:15:47 2009), 站內

haha

其實說遠了，錢才是王道
技術強弱，技術強勢，管理和溝通技巧，這都是放大的手段而已

【 在 qingrun (青潤) 的大作中提到: 】
: 最起碼儘量專業也代表你已經同意我的觀點了。我是一個實踐人員不是一個理論推行者，所以，沒有那麼高的噱頭，只有操作過的例項。
: 至於後面那句，隨便大家看待吧。呵呵

※ 來源:·水木社群 newsmth.net·[FROM: 114.243.227.*]

發信人: lvchunchen (我的2008), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Wed Nov 18 15:57:05 2009), 站內


劈一個分支,請那個牛自己重構,自己抽時間結對一下.重構效果好慢慢和團隊融合.


重點還在團隊開發程式上.


【 在 redolence (雷德隆…還有一個斯) 的大作中提到: 】
: 關於專案管理的
: 專案開發了一半，專案組加入一位牛人，於是發生了這些事：
: 1.大牛說原來寫的程式碼效率不高，構架繁冗，不方便後期維護，要求重構程式碼和資料庫。
: ...................

--

※ 來源:·水木社群 newsmth.net·[FROM: 119.108.176.*]

發信人: pupop (lient Applications), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Wed Nov 18 20:52:32 2009), 站內

問題是，人家大牛可以完全不弔你

【 在 qingrun (青潤) 的大作中提到: 】
: 五哥，我覺得，專案經理如果不懂得技術，也可以做好專案經理，那就需要更好的態度和更多的配合和詢問，更多的增加內部的交流，但是，他必須有足夠的邏輯判斷能力，而不能糊塗，畢竟專案經理要負責整個專案的成敗，失敗了，他應該是責任承擔者，絕對不能推卸責任。這樣的
: 強勢專案經理可以在一些判斷中，先下結論執行後解釋，而若是專案經理永遠要以解釋和討論為主導，後下結論或者說後執行。這樣的形態，加上好的態度，也一樣 可以很好的控制專案的進度——我05年-06年在中科院自動化所模式識別實驗室的角色，就是若是專案經理的做法，畢竟

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/257598/viewspace-620144/，如需轉載，請註明出處，否則將追究法律責任。