singlelog wrote:
唉，就跟你說了，不懂人事，不懂財務，可以當人事經理，可以當財務經理，這也不是我說的，是kenchu。是kenchu。並不是我扣這頂帽子在他頭上，是他自己說的。不懂投資銀行，可是他可以當一個投資銀行的好經理，這也不是我說的，我就是覺得很唬爛，才會扯這麼久。可是我講了半天，你就一直說我冤枉他。你要不要自己去問他？

njuck wrote:

coding能力很強就代表能夠處理好整個專案的所有事件嗎？
而擁有管理能力的管理者就沒辦法處理好在軟體工程裡的事件嗎？

njuck wrote:
何謂什麼是只懂管理，不懂技術的PM？
明明kenchu大大是認為PM只需要專注好管理，
不用去在意技術。

但是不代表kenchu就是說路上隨便抓一個阿狗阿貓小學畢業的人(用這來形容什麼都不懂的人)都可以來擔任PM。
而且當PM在進行專案管理時，就已經會從中學習到管理層面的技術能力了。他只需要稍為了解就好了，有必要還要什麼技術能力都擁有嗎？

如果說你問我PM需不需要技術佐身，
我會回應：不需要。

如果你問我PM有沒有DOMIN或是技術，
我會回應：有。

singlelog wrote:

我對於技術的定義在一開頭就講過，我在數百篇的問答中，要不斷提及，我認為PM除了software development process以外，其他要懂的技術有個最低標準，符合就好，就是要聽得懂，要可以做判斷。也就是說是個肉腳就可以了。結果kenchu不斷地把它轉化成，PM要是一個超強的技術強人，難道故意忽略我要表達的東西，就會讓你變成對的嗎？

singlelog wrote:
我解釋過了前因後果，而且kenchu在上面也證實了，他指的確實是不懂投資銀行這個領域的專案經理，也可以管理投資銀行這類型的專案。

我在前幾篇還以為我誤會他了。看來也沒有。

singlelog wrote:
njuck，我就直接問你好了，你會覺得當一個軟體專案經理不用懂得技術人員在說什麼，不用懂軟體工程嗎？一個只懂財務的投資專案經理人，插到軟體專案也可以管得動？這是我覺得最大的差異。

singlelog wrote:
至於我後面的比較，就是因為你提了問題，又講說拿管理能力相同的兩個人去做比較是不對的。不過既然你說你沒這個意思，那就是個誤會。ok?

好吧，就算是我又犯了錯，可是我相信我並沒有在誤導什麼人。我的文章應該都做了一定的前後假設，如果是假設出問題，或者這不是參與討論的人的本意，那就是假設不成立。if then else的 statement剛好在條件句不成立的時候，那就是後面這一大個block不要看吧。

可是如果我的algorithm 是對的，除了這個假設是誤會以外，表示這程式丟進系統還會跑，只是永遠跑不到那一個block，可是還可以work的很好，那就表示恭喜這個版，又被我多灌了一篇水。

ianhong wrote:
我想生氣的人應該滿多人的.

PS: Windows 是 product, 所以 user experience 滿重要的. 所以應該算是 Product Management. 這裡的 "技術" 可能又被定義為 產品開發流程, User experience, marketing, 甚至含 technology capability. 然後PM 應該會被要求了解廣度, 而不是深度.

singlelog wrote:
我講了很多次，不懂技術，我指的也就是不懂軟體工程，我是認為這樣的人，在軟體專案管理這個領域裡面，就不足以成為擔任一個好的PM。

至於kenchu一直要我們體會與了解的，其實就是專案管理與專案的領域無關。也就是說，不懂軟體工程的人，也可以來當專案經理，還會管理的很好。

這些東西，對於一個不是這個領域的人來說，並不是那麼容易就可以理解跟掌握的。或許他鑽研個很久，鑽研通了，就會是個很好的PM。可是，就我的定義來說，他的技術就已經進化了，變成一個有技術的人。

我並不覺得軟體工程應該被歸類為管理方面的學問，我也不覺得應該是什麼要加強管理或是不要加強技術。你要吃這行飯，你兩個都要會。這些東西並不是互斥的，你自己要當一個不適格的管理者，那請便。

要當一個專案經理，當然管理能力最重要。可是技術能力就不重要嗎？像是軟體工程，這對你的工作上是天天會用到的東西，你可以不會嗎？你可以找個顧問來幫你分擔就好了嗎？

每次舉的例子，都是一個技術很強的人被升到經理。這樣的人有什麼好討論的？管理能力不行，就是要加強專案管理方面的能力呀。可是一個別的行業的專案經理要來吃我們這行飯，為什麼不用加強自己對於技術方面的了解？然後答案永遠是他可以不需要了解？

kenchu wrote:
專案經理管的是工作項目，組織的運作
讓術業有專攻
讓工程師可以專心做工程
讓專案可以有所制度
如需求要怎驗證、規格要怎驗證、功能要怎驗證、測試要怎驗證、品質如何保證...
這些其實都是PM的工作，要建立一個專案組織，訂好組織流程，做好產出物的管理。

secretguest0824 wrote:
有導入CMMI的話,這些好像是SEPG就該規範出來的咚咚
所有人都要follow去做
產出的文件QA會負責去盯
我印象中是這樣哩,姑且不論執行上是否有困難
的確有這樣一個方法論存在
但應該不是PM去擬定制度，PM只是follow制度去做事而已
至於做什麼，這就要看各家公司制度怎麼定了
CMMI只是原則 並沒有規範PM該做什麼

提供點參考出來囉

singlelog wrote:
我是比較贊同做高階主管不用懂技術。可是如果到了PM 這個層級，大的軟體公司反倒很少看到不懂技術的PM。

hearenly wrote:
終於把32頁的文章看完了，呼~真是累死人了，先小小的吐糟一下，

從第22頁起真的是在無窮的迴圈，後面都是在說前的有的，只有小部

份是新的東西。

也順便說明一下，看完之後的心得，我比較偏重singlelog的說法，但我並

沒有排斥kenchu的說法。

第一個差別點:以一個外行人的我來說，我要的是證據，singlelog大大的說法
，有比較多的根據，也有說明出出處，和書本來源，讓我對他的說詞可以有
在一步驗證的地方，這對這個"外行人"而言是正面的，有分享性，求證性，
教學性，通用性(老手新手都通用)，方向性，也讓一些想往這方面發展的人
有目標。而kenchu的說明，有很明顯的排他性，就我看完32頁來看，我好像
只記得二個佐證，一個是CMMI一個是ISO的規範mil-std-498，除非是同一個
領域的人，或者是有相關背景，有接觸的人才能明白，這對這個外行人而言
，其內容一知半解，而且也沒有相關的佐證，連要進入的點都沒有，讓人不
得其門而入。

第二理念的論點上:kenchu的論點有其高規格化，以kenchu論點得知，其
公司的完整度，和各方面的資源必需有某一定的程度，而其PM的能力是
建構在這些方面上，所以其適用度被定死在某一點上，就一般而言就是比
較完整的大公司，或是國際公司，而singlelog的說法，以現在的台灣來說
，是符合多數的，而且也適用其國際性的公司。

第三現實與理念的衝擊:kenchu大大的論點其實是正確的，一個站在金字塔
頂點的PM是可以忽略其技術性這一環，因為底下的結構強韌，但重點是這
個PM是在金字塔的頂點，但在現實面上又有多少座這種金字塔可以讓那麼
多PM站，反觀singlelog的論點，比較貼近現實面。

所以這些讓我比較偏重singlelog。以上是外行人個人的看法。~不要打我><"