工程师和产品经理之间的恩怨情仇，一直是科技圈茶余饭后久盛不衰的一个话题。“产品狗”摧残“码农”的故事、或者工程师吐槽产品经理什么也不懂只会乱提需求的段子屡见不鲜。那么，产品经理和工程师到底能不能和谐共处，成为一个战线上的好伙伴？
其实，一个优秀的产品经理不仅能和工程师有效合作，甚至可以让工程师觉得跟定了你，没你不行。
在硅谷，我们常说一个顶尖的产品经理每次跳槽，都能拉走一堆优秀的工程师，究其原因：一是，这样的产品经理确实不多见；二是，遇到一个好的产品经理，工程师可以把更多精力花到他们感兴趣的、有巨大影响力的方面，可以更有效率地做出优秀的产品。
在硅谷的很多顶尖科技公司，都是 “工程师导向”的文化，也就要求产品经理不能像监工一样告诉工程师应该做什么。如果产品经理对工程师指手画脚，那工程师会顿时失去工作的兴趣，吵着嚷着要换组、换产品经理。
但是，一个真正优秀的产品经理能够让工程师兴奋起来，满腔热情地投入到产品开发中；而这种热情一旦被激发出来，产品经理就再也不用担心工程师会拖延工期、消极怠工，相反工程师甚至会比你更积极。
那怎么才能激发工程师的能动性呢？我至少和百位不同背景、不同资历的工程师工作过，在无数次“踩坑”后，我总结了下面的这些建议。
第一，作为产品经理，你应该知道这个工程师在乎的是什么。
他是一个刚毕业不久、满腔激情、想赶快升职加薪的工程师？还是一个想解决最高难度的技术问题，哪怕产品没人用，只要解决的问题难度足够高就高兴的工程师？还是一个满肚子主意，极其讨厌产品经理告诉他该做什么的“点子大王”？还是一个有些害羞、很多想法都憋在心里，但其实特别希望自己有存在感的人？
知道了他在乎什么，你才能知道怎么激发他的能动性，以及该让什么人做什么样的项目。
想升职的工程师肯定喜欢做老板能看得见的项目，哪怕这些项目没有多高的难度，帮助这些工程师在老板面前“出出风头”，他们肯定对你死心塌地。
技术宅？那你就给他们强调一下，这个项目的哪些技术问题是其他工程师想想就头疼、根本解决不了的，满足他们的虚荣心。
“点子大王”？那就找机会表扬他的点子又多又好，就算这个想法是你先想出来的，你也可以在和他交流时循循善诱，引导他说出你的想法，然后赞叹他的想法真厉害。
比如，如果你认为应该在视频平台上做一个让用户发弹幕的功能，不要直接和“点子大王”说：“你负责做弹幕”，而是要从问题出发，你可以说“我们的视频互动性太差，用户都不喜欢发评论”，然后引导他说出做弹幕的主意。
至于害羞的工程师，你可以在开会的时候刻意给他们表达自己的机会，他们绝对对你感激涕零，期待和你继续合作。
知道工程师要什么，想办法在现有的项目里给他们相应的机会，会让你们之间的合作事半功倍。 至于怎么知道工程师要什么，你不如和他约个时间喝杯咖啡私聊一下，了解他的个人情况，你甚至可以直接问他：“你是如何决定自己做的事情有没有价值的，你在乎的是什么？”
第二，产品经理应该知道怎么和工程师沟通最有效率。
很多工程师最讨厌的就是开会，因为30分钟的会议打断了他们的思考时间，拖慢了他们写代码的进度。
所以作为产品经理，虽然你每天要花很多时间在开会上，但是要考虑一下这个会到底有没有必要让工程师参加，可不可以安排到这个工程师其他会议之前或者之后的时间， 这样尽量少地打断他们的思考，以便于他们有效率地编程。
你还需要思考，除了开会之外，还有没有其他可以高效做决定的方式，比如发个邮件。
第三，产品经理要弄清楚什么决定需要自己领导大家做，什么决定可以放心地交给工程师们自己做。
比如，某个按钮是100像素还是120像素，类似这样的决定，是不是可以让工程师和设计师自己决定？
很多产品经理常犯的错误是，自己做出所有的决定，和工程师交流时只是要求他们按照指定要求来做，但实际上有些要求根本就不切实际。 更或者，按钮是100像素还是120像素，可能对于产品的成败来说，并不是最重要的决定， 你完全没必要在这种决定上花时间。
还有些产品经理只告诉工程师要做什么，从来不解释产品的目的、成功的标准，工程师完全不知道这些决定背后的策略和思考过程， 结果就是事事都需要产品经理告诉他们要怎么做。
其实，一个好的产品经理一定会清晰表达产品要解决的问题、如何衡量成功、需要最先解决的用例以及原因，让产品团队的工程师、设计师、数据科学家等都有足够的背景信息。 这样，很多的小决定完全可以让团队成员自己做，从而既可以大大提高产品效率，又可以提高团队成员的能动性。
当然，这并不是说产品经理什么决定也不用做，一个优秀的产品经理，会确保自己的时间花在“非我不可”的事情上，其他决定都会交给他人。设想， 如果一个产品经理把每天的时间都花在解决按钮是100像素还是120像素这种问题上，他们哪还有时间去和客户做一对一交流、制定产品战略、思考“脑洞大开”的新功能。
第四，产品经理应该帮助工程师解决开发过程中的一些困难。
很多工程师在开发过程中会遇到一些困难，比如因为其他组工程师进展缓慢而导致开发工作停滞，因为开发的新功能被律师认为风险太大而面临一些质疑，等等。因此，产品经理应该积极询问工程师：“你需不需要我为你提供一些帮助”，帮助工程师解决开发过程中遇到的障碍。
因此，帮助工程师扫清开发路上的各种障碍，可以提升你的产品开发效率，而这正是优秀的产品经理需要做的事情。 比如，我常常对工程师说：“现在有哪些工作是你不喜欢做的，告诉我，无论是脏活累活，我来帮你做”。其实，这也是一个帮助你和工程师建立信任关系的过程。
这个问题是很多刚入行的产品经理最担心的，我的建议是，让工程师先自己估计需要的工期，然后再设定截止日期。如果他们预估的工期太长，我可能会提出一些问题，弄清楚为什么需要这么长时间，看看哪些部分可以砍掉，到底值不值得为截止日期砍掉这些功能。
工程师估计完自己需要的时间后，我会和工程师说明我们的发布计划， 比如某月某日营销团队会开始宣传产品功能、 某月某日我们需要开始运营工作等等，这样可以让工程师了解其他部门的进度，增强他们的归属感。
刚入行不久的工程师估计工期的能力比较差，如果他们的工期估计得太长，我就会想方设法让他们告诉我工期是怎么估计出来的，然后跟他一起讨论，哪些部分可以用现成的API，哪些部分可以少花一些时间。
如果遇到确实要将截止日期提前的情况，我会告诉工程师需要提前的详细原因。这样做的目的是，让工程师觉得你和他是一起的，让他感觉到你的信任、你在思考如何一起解决工期提前的问题。
所以，我一般不会直接说要花多长时间，而是让工程师先估计工期，如果我觉得估计得过长，我会诚恳地告诉他我们需要加快进度，看看有没有什么方式能够重新组合一些计划，以加快工期。
在这里，一定要让工程师觉得自己是有掌控权的，而不是产品经理一拍脑袋，就决定个截止日期。 就算这个截止日期是你自己拍脑袋决定或者老板要求的，在表达日期的时候也要尽量体现出对工程师的尊重，用问问题的形式表达自己的看法，积极地和工程师一起寻求提前工期的方式。
改产品需求是一个非常常见的过程，有些时候前期计划做得很好，开始Beta测试时却发现，用户对某个功能根本不理解，还是需要改动。
其实，开发本来就是一个不断迭代的过程，所以应该首先认识到，产品开发不是产品经理闷头花几个星期写一个文档， 然后再抛给工程师让他们按照这个文档执行的过程。
但是，改需求并不代表产品经理可以在产品需求文档上胡写乱写，做出一些不靠谱的决定，这是在浪费工程师的时间。这里我就跟你说说有哪些方式能够避免在开发后期改需求，如果真的要改需求，如何和工程师有效沟通。
尽早和工程师进行产品功能设计的讨论，让他们提前了解各种背景信息。我平时的工作方式是，先在产品需求文档中写明需要解决的问题、如何判断成功，并写几个产品方案的初稿，和工程师、设计师们进行讨论，回答他们的问题，让他们一开始就参与进来。通过这个讨论过程，我可以知道有什么技术上的局限性，然后根据大家的反馈修改产品需求文档。这样可以避免在工程师花费大量时间后才发现问题，然后重新来过，导致工程师做无用功。
如果确实需要让工程师们重新写已经写好的东西， 或者砍掉他们已经写好的东西，一定要积极承担责任。 这种情况，可能是因为你作为产品经理少考虑了某些情况，也可能是突然发生了一些变故，比如公司改变了策略、竞争对手突然“搞事情”。虽然这并不一定是你的责任，但是这时你还是应该积极和工程师交流，主动承担责任，告诉他们：“这个赖我，辛苦你了”。
其实很多时候，就算产品经理自己主动承担责任，工程师也不会“顺杆爬”埋怨你，他们反而觉得你是个靠得住的好产品经理，甚至会过来安慰你。
积极承担责任，说句“抱歉，辛苦了”，虽然对你来说就是一句话的事儿，但这可以很好地安抚已经努力工作了一个月、每天加班加点儿的工程师。很多时候，给工程师们一些鼓励和温暖，虽然看上去微不足道，但却能让他们干劲儿百倍，对你死心塌地。
最后，我来给你提炼一下今天的要点。
要做到和工程师的有效沟通，你作为产品经理需要做到：第一，知道这个工程师在乎的是什么；第二，知道怎么和工程师沟通最有效率；第三，弄清楚什么决定需要自己领导大家做，什么决定可以放心地交给工程师们做；第四，帮助工程师解决开发过程中遇到的困难。
接下来，我还跟你分享了怎么催工程师加快进度，以及怎么处理改产品需求这种常见的棘手问题，归纳起来不外乎这几点：第一，尽早和工程师进行产品功能设计的讨论，让他们提前了解各种背景信息；第二，积极承担责任，把过错往自己的身上揽，而不要抛给工程师；第三，要让工程师觉得自己是有掌控权的，而不是产品经理一拍脑袋就决定了截止日期和产品的需求。
你的一个工程师平日少言寡语，从不会主动表达自己的想法，会议的时候也不怎么发言，但是你在产品开发的过程中发现，他并不完全同意大家的决定，所以也不能很顺畅地执行，那么你作为产品经理应该怎么做？
你的一个产品功能，因为测试的体验太差，有被砍掉的风险，而这个主意是你自己提出来的，你会怎么和工程师沟通这个糟糕的结果？
你的一个工程师鄙视你没有工程背景，在做决定的时候并不信任你提出的建议，你该怎么取得他的信任？
欢迎你给我留言。
评论