※ 引述《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