在軟體業界，相信很多人都曾經碰過工程師和PM摩擦的狀況。這種情況通常都是公說公有理、婆說婆有理。但不管是從台灣多數大企業和新創工程團隊的職務分配、還是從工程社群的輿論看來，許多工程師和專案經理之間的對立，都是相當不健康的。
而這種不健康且充滿誤解的合作方式在國內被當作常態，實際上是一種專案和工程管理方法尚未成熟的病徵。 或許是時候檢討一下如何改進合作方式，並且突破對立的情況。
工程師眼中的專案經理
首先我們先來討論許多工程師對於PM（專案經理）的刻板印象好了。
在台灣，許多工程師普遍認為PM是因為沒有足夠能力當工程師所以只好做專案管理，而PM的工作一般而言就是「只要不是開發相關的工作都歸PM管」。
換句話說，PM就是老闆和工程師的打雜工，專門處理各專案的相關雜事。基本上包山包海的各類雜事，從跟客戶接洽、排時程表、追蹤專案進度到協調各方合作，通通都是PM的責任。基本上只要工程師不想做的事情，PM都應該去打理。
推薦閱讀：如何跟資料科學家合作？
三不五時，工程師就會抱歉PM沒有足夠的技術背景去理解技術工作的複雜性，因此PM開出的時程表只是「許願清單」，沒有實際技術上的參考價值。更因為這種對於PM工作的輕視，很多工程師甚至認為沒有技術背景的人無法勝任PM工作。
而在這種工程師看不起、也不尊重PM的情況下，專案時程幾乎沒人遵守，公司因此會有許多突發狀況，而這些突發狀況最後又要再借助PM的人力去協調解決。
專案經理眼中的工程師
再來，聊聊很多PM眼中的工程師好了。
人是互相的，PM們當然不會不知道工程師對於專案管理的輕視，更不會不知道工程師與PM之間薪水極大的差距。
在很多PM眼裡，工程師其實就是一群沒有常識和其他技能的阿宅，不但溝通能力、情緒管理能力奇差，許多甚至完全沒有自律能力。但是礙於台灣的工程文化，只有寫Code的講話才能大聲，因此PM每天在辦公室就是得不斷地去吸收來自工程師的工作和情緒壓力，但是自己卻沒有還手反彈的機會。
因為到了最後，公司在薪資上就已經告訴PM了，工程師是公司中最有價值的員工，就算工程師無理取鬧、徒增問題，反正PM很便宜，公司都可以多請幾位PM來使喚。
因此在許多台灣公司中，PM工作是很多人都不想承擔、也吃力不討好的工作。
到底是誰的錯？
說實在的，在這種公說公有理、婆說婆有理的情況下，代表雙方都有錯，因為一個銅板是敲不響的。而事實上，錯的還有第三方：老闆或上司，因為如果上司的管理方法得當，也不會放任這種失衡的合作模式繼續下去。
因此，我們要多方檢討。
國內的專案管理方法斷層
過去聽過一些外商公司、台企和新創的PM訴說自己工作的辛酸，而基本上有一些狀況是國內到處都輕易可見的，其中一點就是：PM需要的能力是包山包海。
而事實上，這種思維其實就是完全誤解了專案管理到底是什麼。因為如果我們把專案管理當作一門專業，沒有什麼專業能力是「包山包海」的，專業一定是有其專精的方法論。
所以說PM到底在做些什麼？
很多人普遍認為PM應該去見客戶談需求，不好意思，這是AM（Account Manager）的工作，不是PM。正常科技公司的PM是不見客戶的。
而很多人也普遍認為PM需要花時間跟工程師討論客戶的需求，不好意思，不管是PM還是工程師都沒有權力去討論需求是否合理，這兩方討論的是解決方案架構的Specs，不是需求。正常的科技公司應該是由AM去洽談和管理客戶需求，再由PM主導和工程團隊去規劃解決方案。PM和工程師都沒有權力去擋需求的。
另外也有不少人認為PM應該深度理解工程師的工作量並且提出合理的時程表，而也很不好意思，這件事情嚴格上來說比較算是EM（Engineering Manager）的工作。在正常的科技公司中，PM和EM是密切合作的，PM是代表AM提出的需求來推動解決方案的開發、而EM則是代表工程團隊的各種考量去跟PM協商一個雙方都能夠接受的時程與方案。
也就是說，其實國內很多人刻板印象中PM應該做的事，大部分其實都不是專案管理工作。講難聽點，PM在台灣就是被當作打雜工，什麼都得做，而且什麼都做不好。
大家可能會以為將這些角色分開，就是要有很多人。其實不是這樣，很多美國科技公司（尤其是新創公司）的PM也是身兼多職，但是如果同時兼任PM和AM，或是兼任PM和EM，那這個人就應該同時擁有兩種專業，而不是像國內這樣完全沒有專業訓練，把人當傭人使喚。
那應該什麼才算是PM的專業呢？其實PM在公司裡面的角色，應該是資源管理（Resource Management）、用量管理（Capacity Management）、組合管理（Portfolio Management）和風險管理（Risk Management）的專家，不管今天團隊的組織結構如何，都要能有效地吸收資訊、觀察情況、調整資源配置並且追蹤團隊各方的狀況。
現在國內多數的PM的專業程度不夠，主要也是因為國內科技產業的整體思維仍是可笑地認為寫Code才是產出，而不去講究管理流程、執行流程和檢討流程的專業。
推薦閱讀：當PM的第一年學到的三件事
國內的工程師訓練斷層
講完了PM的專業訓練缺口，工程師們也別高興地太早。
台灣的員工因為教育制度和社會風氣的關係，原本受到的邏輯分析能力、彙整簡報能力的訓練就非常差，今天講到工程師更是不敢恭維，這個可以算是國內工程師訓練的最大致命傷。
台灣的科技業有種非常可笑的術語，那就是「工程師個性」，認為工程師不需要溝通、不需要解釋，只要能夠寫Code就好了。雖說世界各地工程師都是相對寡言內向的一群，但是會認為基本的時間管理、計畫簡報和溝通責任都是PM的事情，還真的是國內科技業最奇葩的現象。
這種窘境原本還可以透過擁有良好的EM來化解，但很不幸地，EM以能力上來說就是工程部的內部PM（再加上技能管理的專業），因此在專案管理方法落後的情況下，基本上工程團隊上不會有很專業的EM來協助馴服工程師。
以國際上大的科技MNC來看，大家在外面霧裡看花都以為裡面工作環境是很自由的、基本上沒有什麼硬性的管理制度。但事實上，在大家當作神主牌在拜的G牌、F牌、A牌、M牌等科技巨擘內部，工程師都必須具備獨立作業的能力，而且要能夠用清楚的言語去參與會議、交代自己的計畫、主動提供其他成員協助，並且碰到任何問題都主動回報並與其他成員合作解決問題。
並不是像國內許多人認為一樣，工程師只要能寫程式當個「碼農」就好了。
有常跟國際團隊合作的人應該都理解，台灣的工程師其實是很難合作的對象。首先，什麼都不願意溝通，問有沒有問題都說沒有，但是事後又在抱怨；再來，就是缺乏時間管理和自我管理能力，如果PM每天盯進度和交代工作還可行，但是如果一個禮拜交代三、四個工作，常常都會丟三落四，一定會有事情做不完、做不好；事後再埋怨說PM或主管不能體諒他的辛勞（但是你為何不溝通呢？）；最後，就是先前提到的不尊重管理專業，因此自己浪費很多時間在做沒有效果的事情的同時，又不誠心跟PM和主管配合解決問題。
這種現象是從國內新創公司到上市科技都是一樣的，這也是為什麼台灣的軟體業其實工程產出效率跟歐美國家相比很低，其實並不是工程師Code寫不出來，而是公司從上到下都不尊重管理專業，因此浪費很多時間在沒效率的溝通和協作流程，才會淪為人事肥大的血汗工廠。
如何攜手共進？
所以到底工程師和PM應該如何才能有效地合作呢？
首先，不管是PM和工程師，所有的員工都應該要加強溝通和簡報彙整能力的訓練。 碰到問題不回報、一副事不關己的員工，如果不願意改進溝通方式，基本上都可以資遣了。而說到簡報彙整能力，這不是什麼PM或主管的工作，工作職場上每一個人都應該要有基本的論述能力。公司內部開會溝通協調事情都應該事先準備好簡單明瞭的議程，並事先寄出相關參考資料，而實際開會時間應該控制在一個小時內，而且應該在議程中就要定義好會議應該解答的問題為何，才不會有那種兩三個小時鬧哄哄的會議後完全沒個結論的窘境。
第二，工程師應該養成習慣，碰到問題先溝通想法，再開始開發。 而不是聽到什麼，轉身就自己先在那邊敲敲打打，浪費幾個小時去做一件不對的事情，然後事後又無法去跟團隊交代。
第三，PM應該接受專業訓練，公司也應提供更多資源協助PM的工作。 現在國內不管是在上市公司還是在新創，PM清一色都是用人頭以及個人「自由心證」的方式在分配工作。而事實上，到底東西做不完，是因為事情太多？是因為有人在偷懶？是因為人的技能不足需要訓練？是因為溝通成本而耽誤？還是因為外部需求者造成的延誤？目前來講國內真的可以把每個專案和多個專案的資源配置、合作流程設計和人員訓練需求做到得心應手的PM是少之又少，主要都是在於訓練不足而且產業環境不佳所致。這應該是公司改善合作模式的重點。
第四，公司的高層該破除台式企業「養老臣」的慣例。 若PM受過專業訓練後開始針對專業管理流程和團隊狀況提出建議，公司應該要有決心去改革團隊：引進積極且專業程度高的員工，並且資遣被動且合作能力差的員工。
最後，公司老闆們自己要懂得：省錢不見得一定要在薪水上和單元成本上動手腳，長遠的系統性和文化上的投資會有更巨大的成本效益。 被動的工程師和缺乏專業訓練的PM，到頭來也是因為老闆為了成本考量而縱容這些難搞的員工在公司裡面鬥法，而事實上這種沒效率的團隊多請幾個，產出反而會比少數訓練有素的團隊更低，而且會浪費公司更多的人事、時間和金錢資源。
責任編輯：陳建鈞
《數位時代》長期徵稿，針對時事科技議題，需要您的獨特觀點，歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw，文長至少800字，請附上個人100字內簡介，文章若採用將經編輯潤飾，如需改標會與您討論。
（觀點文章呈現多元意見，不代表《數位時代》的立場
