[討論] PM = Problem Maker !?
看板Soft_Job (軟體人)作者BalahBalah (裝忙是很辛苦滴)時間17年前 (2007/07/11 17:26)推噓9(9推 0噓 22→)留言31則, 6人參與討論串1/3 (看更多)
各位, 下午好
之前的文章以及推文, 看似大部分的新鮮人對 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
的技能核心.
加油 ^^
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.125.102.136
→
07/11 17:27, , 1F
07/11 17:27, 1F
→
07/11 17:28, , 2F
07/11 17:28, 2F
→
07/11 17:28, , 3F
07/11 17:28, 3F
→
07/11 17:29, , 4F
07/11 17:29, 4F
推
07/11 19:08, , 5F
07/11 19:08, 5F
→
07/11 19:09, , 6F
07/11 19:09, 6F
→
07/11 19:10, , 7F
07/11 19:10, 7F
→
07/11 19:11, , 8F
07/11 19:11, 8F
推
07/11 19:15, , 9F
07/11 19:15, 9F
→
07/11 19:18, , 10F
07/11 19:18, 10F
→
07/11 19:21, , 11F
07/11 19:21, 11F
推
07/11 19:29, , 12F
07/11 19:29, 12F
推
07/11 21:28, , 13F
07/11 21:28, 13F
→
07/11 21:29, , 14F
07/11 21:29, 14F
→
07/11 21:30, , 15F
07/11 21:30, 15F
→
07/11 21:31, , 16F
07/11 21:31, 16F
→
07/11 21:31, , 17F
07/11 21:31, 17F
推
07/11 22:31, , 18F
07/11 22:31, 18F
→
07/11 22:32, , 19F
07/11 22:32, 19F
推
07/11 22:34, , 20F
07/11 22:34, 20F
→
07/11 22:35, , 21F
07/11 22:35, 21F
→
07/11 22:37, , 22F
07/11 22:37, 22F
推
07/11 22:49, , 23F
07/11 22:49, 23F
→
07/11 22:50, , 24F
07/11 22:50, 24F
→
07/11 22:50, , 25F
07/11 22:50, 25F
→
07/11 22:51, , 26F
07/11 22:51, 26F
→
07/11 22:52, , 27F
07/11 22:52, 27F
→
07/11 22:53, , 28F
07/11 22:53, 28F
→
07/11 22:54, , 29F
07/11 22:54, 29F
推
07/12 14:09, , 30F
07/12 14:09, 30F
推
07/12 15:48, , 31F
07/12 15:48, 31F
討論串 (同標題文章)
以下文章回應了本文:
完整討論串 (本文為第 1 之 3 篇):
Soft_Job 近期熱門文章
PTT職涯區 即時熱門文章