※ [本文转录自 Soft_Job 看板 #1Wuk5J4n ] 作者: annedoo (安安) 看板: Soft_Job 标题: [讨论] 产品经理(PM)需要懂技术吗？ 时间: Mon Jul 5 18:39:11 2021 月经文来着。 我两年前曾经在板上问过这个问题， 偶尔也会有人站内信找我讨论， 所以就写了一篇文章分享自己的想法、跟大家交流交流～～～ Medium 有图有参考连结好读版： https://pse.is/3hk2n9 懂技术当然比不懂技术好，上知天文下知地理当然比什麽都不懂好。而会有人不断讨论这个问题的原因大概分为两个层面： 1. 想要转职，不知道技术知识到什麽程度才能找到产品经理的工作机会 2. 已在职中，身为 PM 不确定自己技术知识够不够，还能朝哪些方面加强 将问题拆解後，我们背後真正想问的是： - 若要成为一个及格的产品经理，对技术的了解要有多少？ - 产品经理有那麽多种技能要点，技术在这所有技能中有多重要？ - 为了转职/为了职涯发展/为了让工作与沟通更顺畅，我应该优先补足技术知识、还是精进其他技能？ 【文章目录】 - 产品经理什麽时候会用到技术知识？ - 所谓的「懂技术」是什麽意思？沟通技术的不同层次 - 怎样才算是够懂技术了？ - 如何跟工程师合作？ - 结语：产品经理技能树 这边先长话短说、下个小结，一般来说： PM 对技术的理解，要足够跟工程师沟通、安排资源、解决问题。 也跟工程师们喊话下： 你的 PM 乱答应需求、乱订时程不一定是因为他不懂技术， 有可能只是因为他不懂得沟通与拒绝的艺术。 ▍产品经理什麽时候会用到技术知识？ 目标：加速产品开发、确保团队在往对的方向前进 有技术知识的 PM 能够： - 了解产品的核心技术竞争力，对於在做的产品有正确的认识 - 分辨市场上其他竞品强不强，是强在技术还是其他地方 - 在做产品决策、优先级排序、规划与协调资源时更顺利 - 跟工程师与技术单位沟通时更顺畅 拥有技术知识，让 PM 在以下工作阶段更顺利 - 研究问题、讨论解法、优先级排序（需求方、使用者、客户） - 资源安排＆实作（设计师、工程师） - 处理紧急 issues（整个团队） 写程式不是 PM 的工作！ 有些人会有个迷思，好像 PM 必须要会写程式才能做好自己的工作。 问了一些工程师朋友和同事，PM 的技术能力要到什麽程度？他们的答案是「可以跟工程师沟通就 OK」「了解技术限制、复杂度、成本之类的就很棒了」「不会写程式没什麽关系啊」「写程式是我们的工作吧！」 如果你觉得学会写程式就能成为一个好的产品经理，那我会说你只是在偷懒而已。 拥有技术知识、懂产品背後的逻辑，并不代表你自己需要会写程式。会写程式当然很好，能更懂行话、也对跟工程师沟通有帮助，但与其自己实际练习写程式，我会宁愿花时间在其他地方。 ▍懂技术是什麽意思？懂技术的不同层次 PM 不用知道如何写程式，但要知道产品背後的逻辑与技术限制。 技术知识要能输出成为「理解能力」与「沟通能力」两个方面才有用：听得懂是第一步，能够参与讨论是第二步，有能力做出合理的判断是终极目标。 我将技术知识含量多寡以及能达到的成果分成以下几种类别。 【高】技术知识作为决策的一环 - 跟需求方讨论时，可以判断做不做得到、难易度如何、可能遇到的问题 - 排序产品与问题优先级时，能精准的将技术复杂度作为一个维度来参考 - 能够将核心技术转化成产品的核心竞争力之一 - 能够从头参与新产品、新服务的讨论，包含选择什麽技术来实作、资料库架构的栏位与内容、是否要找第三方的服务来串接 - 了解技术团队使用的外部服务（AWS、Sentry、CircleCI）的成本 - 了解什麽是正确的时机 refactor、解决技术债（Tech Debt）、Legacy Code 的问题 【中】良好的沟通媒介 - 接收需求时，能清楚厘清问题内容，以利後续跟技术团队讨论实作可行性跟时程 - 接收需求时，能判断是否跟目前逻辑相违背、有没有 dependencies 等 - 接收需求时，能描绘出改动的范围大小，并向需求方建立正确的期待 - 讨论产品解法时，能顾虑到技术限制、技术可行性 - 与技术团队讨论时，知道该问哪些问题、听得懂对方的解释、参与讨论 - 遇到 issues 时，知道怎麽回报、怎麽重现 bug 并提出可能的原因 - 若需要跟第三方服务或客户串接，要看得懂技术文件，或至少知道哪一部分需要跟技术团队确认 - 在写产品文件时，能将部分技术规格也纳入其中，并搭配工程师的 Techical Spec 【初】基础中的基础 - 了解最基本的网路产品如何运作 - Daily Standup 时听得懂工程师说明他在做的事、遇到的困难 - 遇到问题时不会问错人！前端、後端、Data Team 的工作范围都不同；就算都是後端，他们负责跟维护的部分可能也不同，要能判断这块需求或问题要问谁才对 - 能够和工程师一起处理 issues & bugs 【零分】能力不足 - 听不懂工程师说的技术名词却也不会问 - 不懂得厘清需求方的问题，要来来回回问工程师很多次 - 工程师回覆之後也无法好好解释给需求方，让需求方了解技术限制或 bug 发生的原因 - 规划产品时没考虑到技术问题，也没谘询过技术团队 【哎呀扣分】懂技术不是让你用来不尊重专业意见的 最忌讳的就是 PM 觉得自己懂点技术，所以就不尊重工程师的专业意见，因此自己压时程、乱答应、质疑工程师的判断。 有时候一个乍看很简单的东西，可能会因为自家产品背後混乱的 codebase 而变得难以实作，或是需要先进行 refactoring 才有办法开始开发。 每一间公司、每一个产品都会有不一样的状况，因此不要轻视彼此的专业、不要帮对方做决定，大家在能力上应该是互补的关系，而懂对方的语言的目的只是为了让内部沟通更顺畅。 另一种状况是 PM 太过关注技术复杂性。我曾经因为觉得某个东西技术上应该很难实作，所以就自作主张推掉需求，但後来才发现其实工程师能够想到其他很好的技术解法，这就是自以为懂技术的糟糕心态。 应该说，每个人各司其职、为自己的位置与角色发声才是最好的平衡。我不应该过度帮工程师担心技术的事情，而是应该带着我身为 PM 的想法与立场去沟通与搜集专业意见，同时设定好双方的期待。 PM 很常需要在中间当协调人或决策者，势必要能够听懂别人说的话、了解别人在意的事情，但不是取代其他专业同事应该要做的事。 【翻译蒟蒻】除了跟行内的人沟通，还要能够解释给外行人听 当老板、业务、客服问 PM 为什麽这个做不到、为什麽会发生这些 issues，你能不能用很简单的逻辑与案例解释给他听？ 当一个产品需求会被拒绝，有时候是需求本身不合理、有时候是设计上的难题、有时候是技术上的限制，PM 在接收需求的时候心中就要做简单的分析，知道这些问题该问谁、问完之後有哪些因素影响团队做决定（做或不做、优先级如何），跟产品团队讨论完後再回去找需求方沟通。 遇到 issues 的时候也一样，PM 就像一台翻译机，客服回报问题，PM 整理好问题影响范围、重现方式并翻译成技术语言给工程师听；工程师找到问题後告诉 PM 背後的根本原因和可能的解决方案、PM 再翻译回去给客服听，讨论该如何跟客户或使用者沟通。 最後是关於一些常见的技术问题，团队应该要建立起共同的知识资料库，避免一样的问答不断重复发生。PM 总是帮忙工程师回答问题也不是办法，文件化并分享知识给同事才是最有效率的作法。 ▍怎样才算是够懂技术了？ 标准答案：看公司！看团队！ 1. 最基本的技术知识 延续上面提到的技术与沟通等级，对新手 PM 来说，有【初】基础中的基础就不错了，其中的了解网路产品如何运作包含理解以下名词： Backend、Frontend Server、Client、Cloud、DNS Database、SQL FTP、API Cache、Cookies、Session Container、Docker、GitHub、CI/CD、Deployment 会使用 Browser DevTools 并大概知道每个区块的作用 2. 技能对应到工作需求 有些公司里面会有 Technical PM (TPM)、System Architect (SA)、Delivery Manager (DM) 的角色，在这些团队内他们会吃下很多技术相关的工作，一般 PM 对於技术知识的理解与沟通可以透过他们来协助。 但另外一些公司则可能会希望 PM 拥有一定的技术知识与背景，所以真正的问题是，我需要多少的技术知识，才能支撑我做好在这间公司、这个产品的产品工作。在面试前可以先： - 了解这间公司的技术架构，在使用的服务等等 - 找该公司的工程师或其他职位的 JD 来看，是否懂里面所有的专有名词 - 搜寻该公司的 PM 面试题目，看看是否有技术相关题目 Ref: IGotAnOffer — Product manager interview questions (the ultimate list) 如果面试的时候有跟工程师对到，在问问题阶段也可以反问他们对於 PM 的技术能力的要求与期待是什麽。如果你想进去的产业跟公司的产品技术含量高，技术背景就会是标准配备。 而每间公司、每个产品的程式架构都不一样，使用的服务、背後的逻辑也不尽相同，到了新的团队或换新产品的时候都需要重新学习跟理解。 在《产品经理就职手册：抓住四大学习重点，让你快速进入状况》中有提到，刚入职时可以请工程师带着 PM 了解目前产品的技术架构和 Tech Roadmap。 若产品经理了解技术架构与限制，也会多少对判断 Dependency 与了解可能的技术坑有帮助。针对这点可以请工程师跟你说明目前是使用什麽 Tech stack、前後端如何互相呼叫、有哪些主要的 API / Service / Database，以及我们是否跟其他团队在技术层面会有高度合作关系等等。 3. 基本的捞资料、分析能力 一样根据工作所需，有些基本的捞资料、分析是 PM 会自己做的： - 用 SQL 捞资料（知道资料库里有哪些栏位、怎麽存资料、关联性为何） - 用 Crawler 爬资料 - 埋点、分析 Events、A/B Testing ▍如何跟工程师合作？ 有的时候技术问题很复杂、或是程式过去是很多人共同在维护，技术知识学海无涯，工程师本人也不一定随时都知道技术问题的答案，可能会需要先花时间去看一下、研究一下才能跟你讨论。因此问问题与合作时先做功课、虚心请教、给对方足够的时间研究也是很重要的。 执行细节欢迎参考我们过去的文章： 【PM夥伴攻略】如何跟工程师合作？ 【PM夥伴攻略】番外篇：工程师雷区干话大全 【PM夥伴攻略】如何与工程主管 Engineer Manager 合作？ ▍结语：产品经理技能树 在 《从入门到卓越，产品经理技能检核表与职涯发展路径》中提到的「Technical Sense — 对技术理解的能力」主要集中在 Senior PM 的职涯阶段。不过在这个产业工作，多了解点技术相关知识总还是非常有帮助的。 做产品就是在商业价值、使用者体验、技术之间取得平衡，三种技能一定都会点到，但每个 PM 的兴趣和专长都不同，长远的职涯发展朝向不同方向，相对应所需的知识和技能就会有所不同。 最重要的是，PM 跟商业团队、技术团队、设计团队其实合起来是一个全方位的产品团队，大家做好份内的专业外，自己的能力能够跟团队成员互补、并持续进行知识交流是很重要的，大家要一起成长，才会变成更棒的产品团队！ 以上，欢迎 PM、工程师们一起来交流， 拥有什麽样的技术知识才足够成为及格的产品经理。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.162.152.200 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1625481555.A.131.html ※ 编辑: annedoo (1.162.152.200 台湾), 07/05/2021 18:40:36 ※ 编辑: annedoo (1.162.152.200 台湾), 07/05/2021 18:42:00

※ 发信站: 批踢踢实业坊(ptt.cc) ※ 转录者: annedoo (1.162.178.22 台湾), 07/07/2021 19:36:26