※ 引述《BalahBalah (裝忙是很辛苦滴)》之銘言： : 各位, 下午好 : 之前的文章以及推文, 看似大部分的新鮮人對 PM / SA 有很高的期望, 但是老手卻對 PM : / SA 有很深的怨念, 讓我有些感慨 : 工程師到底往 PM / SA 的路走是不是正確的? 資深的工程師該轉職什麼樣的缺? : 合理的大型專案成員, 應該有哪些職缺? : QA / QC / Project Assistant ----- : / | : / | : PG Assistant --- PG --- --- SD --- Architect |---TPM --- PM : \ | : \ / Business Discoverer | : \ SA | : \ Analyser ----- : 依照國際大廠的區分法 : 資訊業的專案經理 PM 有兩種 : 1. Project Manager (大PM) : 2. Technical Project Manager (技術經理 TPM) : TPM 負責專案裡頭的技術問題控管,技術資源分配,版本控管等,等同是本專案的技術主管 : 大PM則負責多個專案的流程/成本/需求控管,這也是為什麼國外PM不少需求的學位是管理 : 科系, 如果各位有時間也想往 PM 走, 可以利用 google 搜尋一下 PMP 的相關教材, 裡 : 面沒提技術性的要求,都是談論規劃,控管,文件然後就是重複的控管,更新一堆文件紀錄 囧 : SA 也有兩種 : 1. Business Discoverer (需求訪談者) : 2. Analyser (系統分析者) : 先針對該專案/產品會接觸到的使用者進行問卷調查 (Questionary), 依照問卷調查的結 : 果排出客戶最希望第一時間解決的問題排名 (Issue Priority),與客戶約定時間訪談確認 : 功能以及問題被確實的涵蓋在解決範圍內, 將需求轉交付分析者落實需求確認/分析文件. : 那麼尷尬的情況就出現了 : 公司因為成本, 組織架構, 人力部位等問題, 無法排定完整的專案開發團隊. : 通常產生的情況會比想像中更艱辛, 不是大 PM 兼任 TPM, 甚至大 PM 兼任 SA, 就是 : PG 兼任 SA/SD, 不然就是 PM + PG 兼任 QA/QC, 或是如板友所說的, PG 直接兼任 PM : 假設依照大廠的人員實際素質, 這個專案不亂才有鬼. : 不懂技術的大 PM 跟資訊中心胡扯, 讓 PG 擦屁股, 而派 PG 跟 User 訪談雞同鴨講, 讓 : PM 去罰站, 不然就是只熟 coding 的 PG 管理時程, 時程 Delay 讓公司跟客戶跳腳. : 既然各位挑選產業, 挑選 User / Vendor Side 的時候會考慮到除了技術以外的個性等 : 因素, 事實上在資訊業或軟體開發產業, 技術以外的特質也深刻的影響到個人能力的發揮 : 工程師是資訊產業的基本 (當然行政文書等除外), 身為新手工程師的同時應該往未來3~5 : 年依照個人興趣,特質, 個性等條件學習下一關的技能,安排轉職的準備. : 喜愛coding , 對技術有狂熱, 不諳溝通的特質, 可以往 QC/QA/SD/TPM/Architect 的路 : 走, 熱愛與人互動, 喜歡交際結識人, 可以往 SA/PM 走 : 之前版友舉例的某 PG 直接跳 PM 靠著嘴砲工作, 那以這樣的人才來說, 45K 我都覺得浪 : 費公司的資源, 這樣的狀況一再發生之後, 久而久之 SA/PM 的薪水當然直落到心酸,當公 : 司花費高薪聘請到號稱專業的 PM 卻搞出一堆大便案子之後,下次公司對 PM 的定位以及 : 薪資也會從原本的高薪向下修正到欲求職 PM 職位的人難堪. : 我個人的作法是當我去面試新工作的同時, 我會跟主考/面試官說明本人的性向以及做專 : 案的定位, 如果是木訥型的技術高手, 請跟公司說明你是屬於 TPM 類型的人才, 不要讓 : 公司誤會或產生不正常的期望,否則等到正式 on side 到客戶端卻過於木訥或無法流利 : 與客戶溝通的時候再來雙方後悔, 是可以被避免的, 我個人的經驗是合格稱職的 TPM 薪 : 水也不會比大 PM 來的少, 又能讓喜愛技術的人員繼續深耕, 也是好事, 如果有機會能 : 坐上 Architect 的職位, 那薪水待遇跟地位, 比之 PM 有過之而無不及阿. : 因為覺得 PG 賺的錢少, 認為 PG 沒前途等理由而強迫自己轉到不適應或不合個性的職位 : 去, 只是加重該職業的惡性循環, 當不適任的人才充斥人力市場, 一個原本有心往上爬到 : 該職位的新手, 也會膽怯, 當新手依照自己的特質以及期望, 一步一步往上爬, 這樣合格 : 又稱職的 PM, 我想給個四五萬的薪水我也說不出口. : 題外話 : 有不少公司的職缺寫著 "專案經理" 但是內容卻是業務專員的工作, 發現了嗎 ^_^ : PM 本就是著重人員互動, 客戶經營的職缺, 若是落入 PM 不會技術就該死, 不會 coding : 就很爛, 那是形容 TPM, 不是管理型的 PM, 既然帶著技術的 Team 去開發, 技術的issue : 就交給技術經理去傷腦筋. : 我知道很多人看到這點就會有意見想噓, 反過來說, 公司人力不足的情況下什麼狀況都可 : 能發生我也清楚, 我只是希望各位在往上升遷或是轉職的同時, 以除了金錢外的各方面條 : 件也當成考量的指標, 在只有 TPM 的專案團隊中, 也能夠學習到大 PM 的溝通技巧, 是 : 應該學習的目標, 如果真的特質不合, 也不用氣餒或是硬轉, 只會讓自己跟公司還有客戶 : 都受傷. : 套句我常跟團隊說的 : 沒有不能達到的功能, 只有不能接受的客戶. : 與其為了某個技術問題跟客戶爭執, 不如以溝通或交際手腕讓客戶改變主意, 才是大 PM : 的技能核心. : 加油 ^^ 小弟可以延伸問一個問題嗎 常聽到 SA/SD，到底SA和SD的差異細節是哪裡 這一點一直困惑的小弟 畫畫UML，流程圖，規劃Data Model等等 是算在SA嗎 還是SD 小弟有作過從 需求訪談 UML等文件製作 到Coding一手包辦過的專案 但是如果以正規軟體工程來細分 SA和SD最大的差異在哪 感謝解惑 ^.^ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.169.114.18