Re: [討論] PM = Problem Maker !?
※ 引述《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
討論串 (同標題文章)
Soft_Job 近期熱門文章
PTT職涯區 即時熱門文章