轉職 PM 是很多軟體工程師正在考慮職涯發展的目標之一，不過問題是，究竟軟體工程師有沒有辦法轉職 PM 呢？
其實軟體工程師是一個還不錯的職業吧，薪水高於平均，工作風險低，生活品質也還可以，所以一定是有一點什麼原因，或遭遇一些問題，工程師才會開始考慮轉職。
這篇來聊聊，到底有哪些理由，會讓工程師想不開，想要轉職，再來講講 PM 的職責，看看是否跟你想像的一樣？最後來說說轉職 PM 可能會遇到什麼問題。
為什麼不繼續當工程師？
工程師的未來發展性，其實還挺不錯的。在大公司，可以從普通工程師、資深、主任、副理、經理、總監、一路當到技術長等等，所以若是從發展潛力的角度來看，應該不會是想轉職的理由，比較多的應該會是職務適性的問題。
通常在越大的公司裡面，因為分工越細緻，一個工程師負責的事情會越小，雖然能夠將一個技術、功能研究的很透徹，但相對的，因為只負責整個產品的一小部分，很難感受到全貌，甚至可能會覺得自己對公司的貢獻程度很低、無足輕重，缺乏成就感，會想要接觸更多不同面向的工作，想要接觸更大的任務。
或者是，有些人雖然程式寫得還可以，學習新技術理解速度也算快，但其實對於技術並沒有熱忱，這些人並不特別在意新的程式語言出現了，或是又有了什麼新的技術來了，覺得反正都差不多。但相對的，會比較在意商業邏輯、公司的運作、或是人的管理等議題，這樣的人也會不安於現況，會開始想嘗試別的角色。
再來，有些人覺得當工程師的壓力比較大，畢竟東西能不能完成，就要靠工程師們的努力。對一些人來說，寫程式不是輕鬆的事情，雖然能做，但是總感覺追不上其他天資聰穎的同期或是資深的同事，會有一些心理壓力。於是會開始思考自己是否不是和當工程師，開始想想其他出路。
所以為什麼不繼續當工程師？大概就如上述，因為成就感的問題、因為興趣的問題、因為能力的問題，所以會考慮改變跑道。
PM 的職責是什麼
想要轉 PM，但你真的知道 PM 是什麼嗎？PM 對你來說只是一個出一張嘴的傳聲筒嗎？不是的，這並不是一個好的 PM 該有的樣子。
首先，PM 其實是一個很模糊的名詞，PM 的 P，可以是 Project、Product、Program，分別是專案經歷、產品經理、計畫經理。
一般工程師，比較容易做到的應該是 Project Manager，因為 Product Manger 需要更多的商業面的知識，所以接著會以專案經理為主。
產品經理通常負責決定一間公司的產品該有的樣子，決定公司產品的走向，會需要有一些商業領域的知識，才能夠勝任。至於計畫經理，或稱為專案總監，其實會同時負責好幾個專案，某種程度上是更高階的專案經理。
好的，所以說，專案經理到底在管什麼？
抱歉這邊又要給一個很模糊的答案了，因為每間公司的 PM 說實在的，職責真的都不太一樣，取決於公司規模跟組織架構，我盡量把共通點拿出來講。
時程管理
一個專案一定有開始跟結束，PM 做的事情就是，專案如期開始，如期結束。
在過程中，要確保所有的事情都有按照排程進行。如果有意外發生，必須要去釐清，並排除困難與障礙，盡量降低對專案時程的影響。
你會好奇，管理時程有什麼困難的？
在一個組織裡面，很多時候，很多決策跟行動，都跟你手上負責的專案有很大的關係。業務可能要等需求開發完成，才有辦法跟客戶交代。行銷可能也要等你專案上線了，才有辦法做出行銷活動。甚至其他部門，也都很需要系統的支援，所以時程亂了，會影響到公司很多部分。
時程管理困難的地方就在於，隨時都會有意外發生。同事 A 突然有狀況，沒有人可以遞補他的工作，怎麼辦？老闆突然插了一件更高優先序的東西進來了，手上的專案怎麼辦？你說這不合理，對，但這就是意外的一部份，所以時程才需要被管理。
如果 PM 一開始就有考慮到一些可能的意外發生，把時間抓得比較寬裕，那就比較能夠面對意外。但，PM 又不可能把緩衝時間抓太久，這樣會讓整體沒效率，老闆會覺得團隊都在混。
又或者，你要想辦法讓意外發生的可能性降到最低。老闆的隕石砸下來了，你要怎麼接招？想辦法告訴他你手邊的事情更重要，或是想辦法讓老闆把隕石砸向別人啊！
需求管理
一個專案會出現，就代表有一些事情要去完成，而要完成什麼事情，這就是需求。
需求也是需要被管理的。專案開始前，要先確認這個專案的參與者是誰，需求者是誰，他們需要什麼等等，把這些意見需求全部都蒐集完畢後，才開始進行專案的規劃工作。
而在專案進行中，需求可能會改變，也會有一些需求在實作的過程，才發現問題。這些需求要怎麼處理才好？處理得不好，可能會影響品質，可能會影響開發時程等等。在專案結束後，又要怎麼確認需求是否都有達到，如何讓專案順利結束。
又例如，如果有很多需求在眼前，那要怎麼幫這些需求排優先順序？先進行某個需求，會不會卡到某些事情。
這些看起來很繁瑣的事情，其實相當重要，很多時候就是這些瑣事，讓一間公司沒有效率。
其他職責
PM 當然也還會有其他的職責，但其實可能大部分時候，也都是圍繞著時程跟需求跑，也就是資源啦。
例如，可能會要負責跨部門溝通，那這其實就是會需要去跟其他部門協調資源的分配，像是那些工作是自己負責，那些是別的部門負責等等。
總之，PM 就是負責想盡辦法，利用手上的各種資源，把事情完成的人！
前面提到的時間跟需求管理，內容講得比較概括，對於更專業 PM 來說，可能只是幼幼班程度的內容，主要是讓想轉職 PM 的工程師，對 PM 的工作內容有一些想像。
工程師轉 PM 會遇到的問題
心態轉變
工程師喜歡凡事自己來，但是 PM 需要靠團隊成員的幫忙才能夠完成事情。當工程師轉職為 PM 後，不能一直想要插手管技術的事情，而忽略了其他面向。
所以在心態上，必須要了解，自己已經變成了一個統籌規劃的角色，而不只是一個專案的其中一個執行者而已。如果心態沒有正確轉變，很容易陷入思考盲點，讓專案沒辦法正常完成，也會做不快樂，沒辦法專心寫 code，也沒有辦法管好專案。
管理也是一種專業
對工程師來說，一個東西有明確的答案跟做法，可能才是一種專業。但現實世界沒辦法這麼精準、變數沒有辦法簡化到最少，有太多沒辦法掌握的事情，資訊不透明不對等的部分，所以要怎麼在這樣的相對模糊的世界中，摸索出一套邏輯，也是一門學問。
管理需要很多實務經驗，你要實際工作過，才會知道執行的過程會發生什麼問題，知道哪些議題需要被管理，以及管理的價值在哪裡。這也是為什麼很多管理學院的學生，在學校念管理的時候，都沒有感覺。
那要強調的事情是，管理技巧必須要不斷的精進跟反省，就像寫程式一樣，可能會有更好的寫法，不能夠不把管理當一回事，能夠做出正確決策的管理者，才是有價值的管理者，然而，沒有人天生就很會做決策，是需要不斷調整的。
薪水問題
最後一個問題是比較現實面的問題，PM 的薪水，通常啦，會比較低，當然不是絕對，還是有些強者 PM 可以拿到不錯的薪水的，但相對工程師的而言，就僧多粥少。
簡單想想就知道，一個軟體專案可能需要很多個工程師，從低階到高階都有。但大部分時候，一個軟體專案都只需要一位 PM 就能負責，就業人口比例本身就有差距。
另一方面，從資深工程師轉成資淺PM，在職場上的價值，某種程度上本來就是降低的，會需要一段時間才能成為資深PM，才有足夠的價值可以要求對應的薪水，這也是一個還算合理的事情。
看完這麼多，還是想轉 PM，該怎麼做？
要直接去找 PM 相關工作，很快就會遇到一個問題，那就是你沒有管理的經驗，公司不願意讓你面試。這種時候你就只能找更初階的職位，從頭做起。
想辦法接觸到 PM 的工作
我的建議是，可以在公司的內部，先想想辦法接觸到 PM 相關的工作。例如主動跟主管爭取，要負責某個專案，如果情況允許的話，就可以成功累計 PM 經驗，這樣有助於轉成真正的 PM。
但這確實也需要機運。我個人第一次有機會接觸到 PM 的工作，是因為我主動提出我要負責公司的一個新案子，那時剛好其他 PM 都在忙，沒有人可以負責管理專案，所以我才有機會可以接下這個案子。
雖然說靠機運，但也要平時有所準備。其實 PM 有各種能力要求，如果要在公司內部做轉換，至少要讓主管得知，你有其中一個面向的能力，比如說，擅長溝通、或是擅長規劃、安排，或是讓人感受到你的責任感。這樣在跟主管要求的時候，比較有機會達成。
最後
要能夠勝任 PM 這個角色，要有承擔責任的決心，並把事情做好的想法，並不能夠只是為了逃避當工程師，就說自己想當 PM，這樣真的很容易成為只是個出一張嘴，沒什麼功用的傳聲筒了。
最後祝福大家轉職順利，能成為自己理想中的角色。