作者aoksc (重出江湖)
看板Soft_Job
标题Re: [讨论] 大家觉得PM需要有技术背景或会写程式吗？
时间Sun Nov 10 10:45:12 2019
我觉得这问题答案是「有技术很好，但没技术也没差」
不管是产品经理、专案经理都是PM
他们专注的点本来就该是在产品功能跟需求本身
会技术当然有助於他们可以比较明确的评估「这做不做的到」「做这个要多久」
但没技术就不能当好PM吗？也未必
重点还是PM能不能帮忙挡需求
说服User天马行空的幻想
懂得安抚RD
当起User跟RD之间的沟通桥梁
这才是PM该做的事
如果PM不能够站在RD的立场
那PM会技术搞不好更糟
「我也以前（十年前）也是有写过程式，这个应该很简单」
「我以前也写过类似的功能，给你一天的时间应该够吧」
（但可能环境的不同时间要更多）
遇到本来就不懂技术的PM你可以安慰自己人家就是没写过程式
但遇到这种写过又喜欢把以前经历套用到现在的PM你拳头才真的硬到不行
所以我认为PM应该还是专注在产品功能面上
当然可以去试着理解专案用到的架构与技术特性
但做这些事目的也是为了要在与User谈判时
提高对於需求的可行性以及时程预估的准确性
但最重要的还是PM能否担任与User之间的沟通桥梁
这才是PM在团队中最重要的任务
※ 引述《annedoo (安安)》之铭言：
: 大家好，我本身是产品经理、专案经理都做过的PM，
: 大学念的科系名字里有个「资」字但非本科生，
: 好奇身为软体工程师的各位，认为PM到底需不需要是技术背景、甚至会写程式呢？
: 我大学的时候也有程式设计的课，
: 但就是在那时候发现自己写得不快、写得不好、也没兴趣，所以很挫折，
: 因此觉得这辈子绝对不会做跟写程式有关的工作！
: 最近突然看到一个粉专（我是PM，有兴趣自己查，他们来板上发过文），
: 写了篇文章说明为什麽PM需要有技术背景：
: （以下不完整节录）
: 作为一个技术出身的 PM，我会建议产品经理们真的要懂一些技术。更准确来说，PM 要懂的不是技术，而是用技术解决问题的思维。这样不仅可以帮助 PM 更好的和 RD 沟通，也帮助 PM 从更多面向思考如何解决用户需求。
:
: 什麽是技术解决问题的思维，我们可以简单理解为四个要素：前端、API、後端、资料库。
:
: 举一个最常见的需求：用户注册。以四个要素分别来看的话可能会拆解成如下步骤：
:
: 1. 前端：用户输入注册资讯并送出
: 2. API：接收用户资讯，传递到後端
: 3. 後端：验证注册资讯是否合规，处理资料格式
: 4. 资料库：於 users table 写入用户资料
:
: 接着可能还会需要回传对应的结果并展示在前端等等，我们这里不作讨论。这样分解下来，每个技术环节分别要做什麽就十分明确了，RD 脑内也能开始把这样的逻辑转化成程式码。
:
: 那 PM 对於技术该懂到什麽程度呢？越多越好。如果一个 PM 技术力越强，RD 就会对你越尊敬。一来他们知道你跟他们有共同语言，是跟他们站在一起的；二来他们也知道，若不接受你提出的需求，你完全可以跳过他们自己动手。
:
: 最後也是最重要的，PM 如何提高技术能力？
:
: 1. 向 RD 学习：回到开头的情境，有的 PM 可能会在被 RD 拒绝後灰心丧气，甚至直接怒言相向，但这其实是一个锻链技术思维的好机会。这时候我们可以根据上面的四要素，来和 RD 沟通是哪些环节碰到问题。对於实现不了这件事情，是因为现有架构的限制，还是说超过了技术本身的能力。於是，RD 可能会如此回覆你：「因为资料库里没有这个栏位，我们也就没办法展示在前端给用户看」，这才是真正的原因。一次两次後，你会发现问出笨问题的频率越来越低，你越来越常帮 RD 们挡下技术上不合理的需求，团队的关系也会变得更紧密。
:
: 2. 动手写程式：要锻链技术能力最好的方法莫过於自己动手写程式了。其实写简单程式并没有太难，不需要买很多书来看，不需要懂计算机概论，只需要在 Youtube 上找些简单的教学来看，然後订一个题目来实作就行。
:
: 简单开始的几个步骤：
: 1. 完成开发环境的建置
: 2. 了解变数宣告、if/else 判断及 for/while 回圈等基本语法
: 3. 完成一个「Hello world!」
: 4. 完成一个小题目：例如 To-Do-List
:
: （以上不完整节录）
: 1. 不知道大家认不认同这个文章的想法呢？
: 2. 在自己的经验中，PM有/没有技术背景造成了多大的差异呢？
: 3. 在了解技术这方面，有什麽可以给软体业产品经理、专案经理的建议XD
: 我身边有/没有技术背景的PM都有，
: 私心认为两种都可以做得很棒，在团队内部可能也会是不同的定位取向，
: 不过自己说不准，感觉还是要合作最密切的工程师大大来分享比较实际～
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 150.117.240.188 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1573353915.A.CD8.html
1F：→ bheegrl: 但是PM不懂技术怎麽知道USER提得是天马行空的幻想? 11/10 10:55
首先
User想的到的需求基本上RD一定做的出来
因为User提需求必定是从他个人过往经验
或者是目前系统上他觉得没有的东西来跟你许愿
但重点是「做这个功能的目的是什麽？」「做这个是为了要解决什麽问题？效益多大？」
「真的有需要这个需求？」「是不是有更简单的方式达成User要的东西？」
这些问题的探讨都不太需要什麽很深的技术底
就纯粹需求面的讨论
PM应该要先确认需求的必要性
因为有时候就真的只是User自己想到
这功能也没说非要不可
PM口才够好的话也许就能说服User这需求其实没必要
当然现实中未必那麽顺利
真的没办法说服那就是带回去跟RD讨论评估可行性以及所需时间
或者是跟RD讨论有没有其它替代方案
之後再跟User继续厘清跟说服
除非每次开会就要马上决定
那顶多就是带一个Tech Leader或者是资深的RD去开会
※ 编辑: aoksc (150.117.240.188 台湾), 11/10/2019 11:12:00
2F：→ bheegrl: 不懂技术的PM不一定是差的PM，但是上限就是比懂技术的低 11/10 10:59
3F：→ bheegrl: 当然秀下限的就不论了，半瓶水响叮当是自古皆然 11/10 11:01
4F：推 jej: 有些狗屁不拉杂的PM 完全不考虑团队技术能力的满足客户脑补 11/10 11:20
5F：→ jej: 做出来烂东西後责任全部是RD 的而这种PM却活的好好的 11/10 11:20
6F：→ jej: 然後平常只会嘴责任他扛 这种PM被fire掉才是大快人心吧 11/10 11:20
7F：→ jej: 就是一堆没有专业的课程不断教导PM不需要技术 11/10 11:23
8F：→ jej: 才造成台湾软体一直没有很强的原因 因为沟通层很弱阿 11/10 11:23
9F：→ jej: 然後又一直强调PM有PM的专业 11/10 11:23
10F：推 jej: 这就像是交响乐团的指挥不会乐器乐理一样 11/10 11:35
11F：→ jej: 怎麽可能听的出来音乐的差异 11/10 11:35
12F：推 abccbaandy: 想到前阵子对岸很红的：根据手机壳颜色变换手机背景 11/10 11:52
13F：推 citycode: 所以指挥有指挥的专业，他不用跟乐器的人比乐器专业， 11/10 12:06
14F：→ citycode: 乐理本来就是指挥必须要会的专业。 11/10 12:06
15F：推 citycode: 不会指挥的人，乐器再厉害也当不了指挥。这不就是各有各 11/10 12:13
16F：→ citycode: 的专业？ 11/10 12:13
17F：→ cool413: 如果遇到不懂技术 又自以为这功能很简单 然後跟客户签完 11/10 13:17
18F：→ cool413: 才回来报工时跟压交期的呢？ 11/10 13:17
20F：→ BeardSmallGG: 指挥不用比演奏的人还会演奏 但指挥要完全不会演奏 11/10 14:00
21F：→ BeardSmallGG: 一种乐器是不可能的 一堆垃圾PM完全不会写程式 11/10 14:01
23F：推 AMAKOTO: PM跟RD的专业有部分交集，没把交集以外的部分补完，如何 11/10 14:51
24F：→ AMAKOTO: 做好一个PM?这不就是各有专业? 11/10 14:51
25F：推 yamakazi: 你们公司都没Architect? 11/10 17:40
26F：推 jej: 架构师在交响乐团的角色叫做作曲者 11/10 18:28
27F：→ jej: 和讨论中的指挥与乐器有段距离 11/10 18:28
28F：推 aria0520: Architect是RD升上去的工程职好吗.... 11/10 18:33
29F：→ aria0520: 工程师 -> 资深 -> 主任 -> 架构 11/10 18:36
30F：→ remmurds: 主任听起来很传产 11/10 19:09
31F：推 GGFACE: 主任就是principleㄚ 11/10 19:23
32F：→ GGFACE: pal啦 11/10 19:23
33F：推 zased: 这版大多是RD，用RD看天下，不懂管理一直纠结技术，完全没 11/10 23:08
34F：→ zased: 搞懂何谓PM。你这篇真的很委婉了哈哈 11/10 23:08
35F：推 aria0520: 可惜台湾一堆PM根本不懂管理^^ 简直就是欠嘴 11/10 23:34
36F：→ aria0520: 一堆PM PM看天下 自以为多会管 然後在那炫耀自己多闲 11/10 23:35
37F：→ aria0520: 快笑死 11/10 23:35
38F：→ aria0520: 为什麽大多RD对PM有这印象 好好反思一下 别再缩在同温层 11/10 23:37
39F：→ aria0520: 然後自己取暖说他们都没搞懂何谓PM QQ 11/10 23:37
40F：→ aria0520: 傲慢 觉得自己完全不用去了解技术的这些PM 哈 11/10 23:38
41F：→ aria0520: 好的PM带RD上天堂 可惜台湾一堆这种傲慢PM 哀 11/10 23:40
42F：推 OhNo386: 但若真不懂点技术，你怎麽知道rd可以做还是不能做跟做多 11/11 06:57
43F：→ OhNo386: 久？时间管理就已不合格了 11/11 06:57
44F：推 OhNo386: 讨论与对话的前题基本上双方水平是一致的. 不然谁开个需 11/11 07:00
45F：→ OhNo386: 求天马行空，时程也压不准，最後也只癑沦为老板的传话桶 11/11 07:00
46F：→ OhNo386: 而已 11/11 07:00
47F：→ OhNo386: 台湾最缺的反而是管理而不是rd 11/11 07:02
48F：→ OhNo386: 但也是有你说的站在双方立场思考的pm，但毕竟是少数。遇 11/11 07:08
49F：→ OhNo386: 过的大部分都是单向传递资讯（命令）而不是真的想跟你沟 11/11 07:08
50F：→ OhNo386: 通（可能说了也不懂），所以造成沟通断层而一连续的问题 11/11 07:08
51F：→ OhNo386: ，产品出不来、rd离职、客户弃单 11/11 07:08
52F：推 OhNo386: 基本上没有一点沟通天份的不要当pm对大家都比较好，技术 11/11 07:11
53F：→ OhNo386: 部分反而可以跟rd套交情慢慢学。但若说都不需要技术就有 11/11 07:11
54F：→ OhNo386: 点言过其实了 11/11 07:11
55F：→ OhNo386: 因为不懂技术的pm有可能整天被rd耍还自己不知道。 11/11 07:16
56F：推 jej: RD到底可不可以作？我还看过傲慢的PM脸很臭的和RD说 11/11 07:38
57F：→ jej: 所以究竟是可不可以？ 造您这样说PM应该要能判断才对 11/11 07:38
58F：→ jej: 但实值上却是傲慢又不专业的PM居多 11/11 07:38
59F：→ keke0421: RD都需要跟PM合作，那为啥一堆ＲＤ都觉得PM很废= =? 11/11 08:54
60F：推 sean2449: Google的PM就一定要技术 11/11 09:06
61F：推 Csongs: 好奇PM薪水是多少 11/11 09:24
62F：→ bosshsieh: 不懂技术能估时间我想也是乱估的 11/11 09:33
63F：→ shooter555: PM需要的技术就是画图 排流程 跟嘴炮 11/11 09:54
64F：→ oherman: 现实是得罪RD比得罪客户活得久，所以无理的要求PM照法漏 11/11 10:30
65F：推 v7q4: 前几天我PM说:「C#和Java语法几乎一样啊 我之前有学过! 11/11 10:30
66F：→ v7q4: 所以把Java的程式改成C#应该很快吧!」 11/11 10:31
67F：→ Ekmund: 抱歉 我完全不觉得提的需求RD一定做得出来这句话成立... 11/11 11:06
68F：→ Ekmund: 当组织稍微大一点 分工细 权限死 但是窗口、规格混乱时 11/11 11:08
69F：→ Ekmund: 没产业或技术经验的PM唯一能做的事 一样是压时程 11/11 11:09
70F：→ Ekmund: 搞到这种地步 RD自己下去做需求访谈才有救 11/11 11:11
71F：→ Ekmund: 不破坏规则玩不下去的情况太多了 11/11 11:12
72F：推 tony3939: 所以那些完全不懂技术的PM到底怎麽当上PM的 11/11 11:16
73F：推 jej: 楼上 这是一个很奇妙的问题 更奇妙的问题是 11/11 12:29
74F：→ jej: 就连PMP这麽大的招牌 课本上没有地方说PM可以不需要技术 11/11 12:29
75F：→ jej: 但上课老师却拼命的灌输PM不需要技术这观念 11/11 12:29
76F：→ jej: 只想速成的老板们根据老师们的说法就上了 在构成没技术也行 11/11 12:29
77F：→ jej: 从老板到员工一条鞭更是软体业的问题啊 11/11 12:29
78F：推 jej: 像是CMMI PMP的课本开宗明义就说了PM需要适当的了解产业知识 11/11 12:33
79F：→ jej: 但被扭曲成软体业不需了解程式 这才是最神奇的地方 11/11 12:33
80F：推 hotkt247: 有些user提出来的需求看似很合理，但大部分都是在开始co 11/11 13:02
81F：→ hotkt247: ding的时候才发现根本不符合程式逻辑，或是前面根本没 11/11 13:02
82F：→ hotkt247: 建置资料却要莫名生出来啊！不懂技术乱接案到後面真的 11/11 13:02
83F：→ hotkt247: 很可怕。 11/11 13:02
84F：推 linkmusic: 我是业务偶而会兼PM,如果你觉得PM不会技术也行那可能你 11/11 13:53
85F：→ linkmusic: 们家PM重要度太低，重要度低的PM就不要谈什麽管理了， 11/11 13:53
86F：→ linkmusic: 你有见过工程师头是靠所谓管理专业驾御底下的人吗？讲 11/11 13:53
87F：→ linkmusic: 难听点没有一点技术底你连要唬弄user或说服工程都编不 11/11 13:53
88F：→ linkmusic: 出个合理的说法，你说有技术长那也要技术长把自己程度 11/11 13:53
89F：→ linkmusic: 降10你听的懂才行，如果全部推给技术长去对user那PM的 11/11 13:53
90F：→ linkmusic: 存在意义？ 11/11 13:53
91F：推 shadow0828: 通常我们家我都要求PM去谈一定要带工程师去 11/11 14:24
92F：→ shadow0828: 工程师听一下user的需求 有些很快就知道怎麽写了 11/11 14:25
93F：推 appleboy46: 楼上正确啊，没带工程师去是要谈什麽 11/11 15:33
94F：→ hotkt247: 可是如果PM会技术的话又何必带工程师出门？coding的工程 11/11 15:40
95F：→ hotkt247: 师真的没有那麽多时间出门开会呀！ 11/11 15:40
96F：→ stkoso: 一定要工程师谈的话那要PM干嘛 11/11 16:07
97F：推 oherman: pm负责辣滴塞让客户爽就好了，这点是rd做不到的 11/11 16:25
98F：→ rucarl: 还要带 RD 开会的话，不就显得这 PM 不行吗？ 11/11 16:35
99F：→ linkmusic: 还有一种业务(PM)顾客关希很好，就算自家Rd开天窗桶楼 11/11 17:07
100F：→ linkmusic: 子还是能把客户按耐好，给自家人很多buffer或CP很好， 11/11 17:07
101F：→ linkmusic: 但这种厉害的是业务能力不是什麽管理能力，就算不太懂 11/11 17:07
102F：→ linkmusic: 技术还是有Rd帮卖命，这才叫各有专业 11/11 17:07
103F：→ linkmusic: 但这类客户会卖面子的大约都管理级的了 11/11 17:08
104F：推 KanzakiHAria: 这篇正解 重点不是会不会技术 而是挡掉 11/11 21:30
105F：→ KanzakiHAria: 大家看不起的废物PM是因为只当传声筒 只会转发邮件 11/11 21:31
106F：→ KanzakiHAria: 这种垃圾存在反而浪费公司资源 11/11 21:31
107F：→ KanzakiHAria: 反之 好的PM可以有效运用公司资源 11/11 21:32
108F：→ bitcch: User想的到的需求基本上RD一定做的出来？ 11/11 21:48
109F：→ DCTmaybe: 身为一个RD我必须跟楼上说确实如此,只是有没有必要罢了 11/11 22:15
110F：→ stkoso: 要做是真的都能做 但现实上还要考量效能与时程 11/11 22:44
111F：→ stkoso: 如何在多方角力中取得平衡才是专业所在 11/11 22:44
112F：推 aria0520: 其实很多纯软公司都是RD-PM轮调双修啦 11/11 23:48
113F：→ Ekmund: 抱歉 还是不可能 RD并不负责成本 11/12 00:32
114F：→ Ekmund: 遇到机器效能不足 或是欠缺某些需要license的场景 11/12 00:34
115F：→ Ekmund: 跟不可能是等义的 但总会有许愿这种事的User在 11/12 00:35
116F：推 leveger0903: 好的PM带公司上天堂 不好的PM可能会把公司搞垮 11/13 12:55
117F：→ leveger0903: 我觉得懂技术有会沟通又有同理心的PM是上上之人 11/13 12:56
118F：→ MagicMomo19: 看看求职网,pm薪水顶多5,60k顶天了,是能要求多高 11/14 10:23
119F：推 sxy67230: 一堆人可能没看过客户有需求就说好的PM，产品流程弄得 11/21 20:07
120F：→ sxy67230: 乱七八糟，把一堆功能都挤在同一页，最後loading大爆炸 11/21 20:07
121F：→ sxy67230: ，在叫RD善後的 11/21 20:07
122F：推 sxy67230: 还有那种客户押不可能的时程还在跟人说好，快爆炸在找RD 11/21 20:10
123F：→ sxy67230: 加班到吐血的 11/21 20:10