为什么需要PM这个职位？

我觉得默认pm做所有决定领导sde本来就是错的，很多project是pod lead制，可以是高级别engineer/em去做可以是pm去做也可以是mkt/strategy head之类的，pm去organize的事情可以是辅助engineer去安排会议排spring催data拿approval解决engineer觉得麻烦的事情，也可以是兼职pod lead带领project的road map. 如果一个engineer lead一个项目没有pm帮忙，那只能默认这个engineer把pm不那么fancy的那些杂货都得自己扛，理论上不会有太多时间关注技术，代码和细节了，保证开会从早开到晚天天ppt，连搞个data sharing approval都得找他填form开会之类的浪费时间。如果是team里的engineer情商不高/英语不好/沟通不行，那也只能是pm来当pod lead了，如果engineer自己也乐意兼顾pm的工作，也是可以招一个pm到自己pod里分担project management的一些杂活自己lead 最重要的strategical items，这样的情况对engineer来说是最理想的，否则会比较容易stuck在一堆meeting里没时间发挥自己最大的优势，那显然易见不管是谁lead project pm role还是很有必要的。

大部分大厂PM都是business背景为主么？有没有CS本科／相关专业然后转PM或者读了MBA转PM？这样会不会好很多？

PM还是有其必要的把，只能说好的靠谱的PM凤毛麟角。PM对于一个团队的帮助是从customer的角度来审视产品做的逻辑。如果这个PM做过engineer那可能他提的feature就会是非常有用的。工程师自己plan最大的问题就是over engineering（工程师天天修bug，优化系统升职快还是干大feature，设计新系统升职快），明明不需要搞得那么复杂的东西，做工程的人就会跟你说要设置一大堆参数，考虑这个Corner case，有时候短期内撑死了就几百几千个人用，非要设计成几百万用的，结果就是产品做出来非常复杂难用，且不稳定。遇到太多senior engineer就特别愿意对着一个Corner case然后去设计一个复杂的UI去解决他。

往极端点看，一个互联网大厂的某个产品的VP通常是一个非常有product sense的Eng（因为大部分手下是Eng），他们自己就是Eng+PM的集合体。同org下，最多的就是普通的Eng，只做engineering的活。所以在这个之间的Eng TL或者manager，通常就是一些没有太多product经验或者视野的strong Eng。对于这一层，配备一些懂tech的PM是最好的，分工明确。

不过这样的好PM太少了

匿名者 发表于 2021-6-8 14:48
PM还是有其必要的把，只能说好的靠谱的PM凤毛麟角。PM对于一个团队的帮助是从customer的角度来审视产品做 ...

这个不就是对工程师的刻板印象吗？做决策本来就应该是工作的一部分，而不是因为你的title是engineer就注定不会从用户角度思考问题。我厂的产品组engineer还算有些bottom up的话语权不少人自己开坑做出来的impact也不小，优秀的工程师不少，有合适的土壤人家自然会成长会shine，然而角色分工却让pm拿走了高visibility的活和挤压工程师成长空间。

所以在角色分工上pm究竟有没有占便宜，抢credit刷visibility，挤压工程师的空间？职场上要成长，工程师锻炼综合技能的机会是不是大部分都给了pm？

yigexiaomajia23 发表于 2021-06-08 00:51:55
所以在角色分工上pm究竟有没有占便宜，抢credit刷visibility，挤压工程师的空间？职场上要成长，工程师锻炼综合技能的机会是不是大部分都给了pm？

是的，为了锻炼综合技能，是不是sales和marketing团队也不需要了？整个公司就保留engineer得了

Here are several scenario to consider:
1. Your team's new software needs to use another team's service, how do you get the other team onboard with your plan?
2. Your client tries to sneak in a bunch of P1 features into your P0 plan, how do you pushback?
3. Your company has set some rules, but for a pressing business need, your team will need to ask for an exception, how do you get it?

From business point of view, PM, not the engineer, is the owner of the product and team roadmap. Using engineer's metrics to judge PM's job role seems a bit unfair.

面向用户的内容还是需要 PM 的，虽然有很多 eng 的产品嗅觉也还不错，但是有的产品上，开发者自己跟目标用户差异巨大，就比较难通过直觉真正理解用户痛点。
而且 Eng 毕竟不是100%的时间都花费在理解用户，理解product market fit 和 协调不同功能的人上面，也很少有 eng 愿意花大量时间搞这些。与其用写代码和设计时间去做协调，很多 eng 还是更偏好做自己喜好的事情。

至于 PM 做计划，如果只需要计划 eng team的roadmap 那的确没啥必要。但是如果有需要跟数据组，marketing, sales, PMM, ops， finance 等协作的情况，那就有value add，这种情况下认为是产品的 mini CEO也非常合理。毕竟产品成败也不完全由代码的能做什么和可靠性来决定的。尤其在早期，product market fit 是一件需要有人一直专心去考虑的事情。

Eng 自身的优势和局限都是非常看重技术，如果不去刻意留意，则很容易出现over engineer的情况，像楼上说的，明明只需要几百几千，却非要设计一个支持千万上亿的分布式系统；明明内部 dash 偶尔才有人看看，但是非要坚持几个 9；明明修修补补还可以再用三年，却非要用最新出来的blingbling的技术；总体别留坑是好事，但是让产品中留多少tech debt，也要看产品发展来决定，越接近 MVP 的东西越乱，throw away的东西越多，太过坚持代码质量，对推动产品也未必有帮助。

沟通效率：eng 对eng 沟通效率还是不错的，但是eng对其他function和executive的沟通经常显得特别细枝末节，抓不住重点。当然很多人很注重这一点，也可以做到communicate at the right abstraction level，但是毕竟大部分时间花费在解决问题上面，只有投入更多精力去刻意思考才能抽身出来，所以 EM/PM有时候也起到一个沟通interface的作用。

带宽问题：就算eng 觉得 PM 做的事情自己也都能做，但是有没有时间精力和兴趣去做，也要考虑。会做的事情未必都要亲力亲为，如果手头有回报更大的事情，那delegate相对回报更小的事情给别人，也是增加自己impact and scope的必经之路。比如 manage up，比如深挖技术，学点新东西，甚至逃避烦人的会议等，是对很多 eng 都有value add的活动。

但是 backend infra 之类与其说要 PM 还不如要 TPM，最好是做过 eng的 TPM（不是指拿了 degree 就直接做pm/tpm的人，是指真的亲自做过eng的人）。遇到不懂技术的 PM 完完全全是浪费生命，只能增加负价值。这个方向有vision的 EM/TL 加 TPM 组合，技术眼界 + 高质量设计 + 快速执行 就很无敌，顶多需要designer给设计少量界面。PM 如果要添加价值，可能就在宣传上。尤其是有朝一日从公司独立出去做 2B 产品的时候，有人能做marketing + PR 还是必不可少的。

之前有人人觉得 TPM， scrum master 没用。。。
现在竟然觉得PM也没用了
PM很重要啊 没PM只有Eng很容易做出做出很fancy 但是没有人用的东西
是合作关系，PM偏向产品/市场需求，eng可以说这个不能实现 或者需要多长时间