工程师如何不被PM欺负

2022-12-02 09:08:06| 收藏本文下载本文作者：椰椰芋头泥

下面是小编整理的工程师如何不被PM欺负（共含4篇），欢迎您阅读，希望对您有所帮助。同时，但愿您也能像本文投稿人“椰椰芋头泥”一样，积极向本站投稿分享好文章。

工程师如何不被PM欺负

篇1：工程师如何不被PM欺负

老师教我们怎么写程序，但从来没告诉我们在公司里，会有个叫做PM的人每天分派作业给我们，还逼著我们赶快做完，这是许多软件工程师进入职场的第一个惊喜。隔了不久，还会发现，这些可能把你压得死死的PM，多半一行程序都不会写。于是我们会面临一种很矛盾的心情，有时候会是一种有点被欺负的心理。这篇文章是前一篇文章《PM如何突破工程师心防》的心防的延伸，我们讨论的是工程师在这样状况下的生存之道。

(1)提高自己的能见度

在非常多的公司，上层的老板或公司的大老板只看得到一个project的PM，而看不到背后辛苦的工程师。也就是说，你的努力和成果，被遮敝了。我一直相信在职场上，让自己在老板或其他同事前有「能见度」是重要的。能见度除了在很多状况下(会议发言、讨论…)可以显现出来外。提供一个我有个朋友很厉害的一招给各位参考。身为一个工程师的他，在每个大的project进行完后，都会「不经意」的寄出一封「谢谢信」给参与这个project的每个人，顺便cc给本来根本不知道他在做什N的大老板。信e面一一点名感谢每个人给他的指导和这个project的协助。这种信每个人看了都很高兴，最重要的是最后大老板也对他有了深刻的印象。

(2)不要每天只埋头写程式：

工程师大部份很喜欢埋头写程式，因为这是自己最擅长，也是最不花力气的事情。但如果你每天100%时间写程式，我保证你会自我感觉良好，但是所有人都不知道你在做什么。所以也许该换换策略，让自己的时间有多一点的部份是用来「表现自己」。「表现自己」不代表做一些表面功夫浪费时间。而是以你的角色，来参与讨论，给出有意义的建议。工程师很喜欢只用电脑和其他人沟通，想要进度都用一个系统来追踪，想法都用email来讨论。在职场上，很重要的是你要学习少用email，多走过去和那个人说话。也许走过去多花了1分，但是你和其他人互动良好，会让你在职场上过得比较顺利。

(3)站在老板的角度想事情:

工程师由于角色的关系，非常容易会站在「技术」的角度想事情，但往往常被主管否决而觉得灰心。公司的想法通常和PM的想法比较接近，都是站在公司的利益想事情，极少用「技术」的角度想事情。你要试著跟他们想的一样，你的日子才会过得快乐。举例来说: 假如我们公司现在要输入10000笔资料。有两个方案，方案A是「手动输入」，方案B是「用程式自动汇入」。方案A要请10个工读生，一笔一笔输入几乎都没有差太多的资料。方案B是支无敌厉害的程式，你开发一天，程式跑3秒就全部完成。但评估起来方案A的总体成本比方案B还要低。我相信极大多数的公司经营者，都会愿意找来10个人，做著重复的事情，一笔一笔key in资料。如果你以工程师的角度来想，你可能会觉得「这个这N简单，一支程式就好了」，然后开始觉得老板选择方案B真迂腐。你要试著让你的大脑跟公司的利益sync，这样会让你好过很多。因榫大多数的PM都知道他们的大脑要怎N跟老板sync。在老板面前让自己显得比PM聪明的方法只有一个，那就是大脑和公司利益的sync做得比PM还彻底。

(4)用PM害怕的弱点有效去争取更多开发时间

PM很喜欢每个东西都如期上线，如果提早上线就更好。很多人会因为deadline而跟PM翻脸，这是不智的，

回到我那位工程师朋友的例子，他会和悦色的对PM说「我可以每天熬夜来把它做完，有可能可以如期上线，但我知道它会出现很多『我们』现在都没想到的问题，那可能会让老板(或客户)觉得我们很不仔细。但如果你可以帮我争取多一点时间，我可以让它品质好很多。」对PM来说，除了要「快」以外，东西如果出来很烂，也打到了他的痛点。我的工程师朋友用这个方法帮自己争取到了比较长的开发时间，和更好的睡眠。

(5)用PM的语言和他沟通

很多工程师会习惯用自己的语言和PM沟通，於是造成沟通不良。我们得试著让自己对他们的谈话，是世界上任何一个人都听得懂的语言。尽量少提技术的术语，尽量少让PM觉得你用你的技术优势在打压他。因为PM不可能学会工程师的语言，所以你们唯一能沟通的可能，就是你学会用PM的语言。

(6)变成工程师团队里面最受PM们欢迎的人

你会发现，如果叫PM们投票，从最喜欢合作的工程师，排到最不喜欢合作的工程师。大家的清单常常非常一致。而且你会发现，在清单名列前矛的人，通常在职场上容易步步高升。所以，想办法变成那个人吧! 因为PM们对你的评价，往往在公司里，和你的工程师主管对你的评价同样重要。

(7)上班前三个月，不要试着改变公司任何东西

公司的系统、公司的project、流程，所有的东西。会是现在这个样子，都必定有它的原因。有理性的原因，也有不理性的原因，也可能它的原因就是没有原因。但绝大多数的公司找你进去，是想要你把一个东西，在他「现在的架构」下开发出来。在前三个月，如果你觉得大家用的开发环境很烂、测试的流程很烂、任何平台很烂。请先忍耐一下，因为除了非常非常open minded的主管和同事，绝大多数的人不会对你刚进来就想改变一切的想法太欢迎。

(8)归功给PM:

EQ好的PM会把project归功给工程师。但做为工程师的你，如果EQ够好，应该再把它归功给PM。不要因檎馐悄阈吹code，就认檎馐悄阕约鹤龀隼吹摹R蛭这样除了自己感觉良好外，对职场生存没有帮助。想办法「言必谈PM」。把自己和PM当成一个team，这个project是我们一起做出来的。虽然很多PM会戏称自己是在旁边帮忙打杂的，但是他会很感谢你很体贴的把一些功劳归于他。

(9)不要为了enjoy自己的成就感，浪费公司的资源

很多工程师喜欢把公司当lab，去试验一些新的技术。如果这对公司「真的有帮助」的话，那当然很好。在做这些事或提议前，请试着用老板的角度想，在公司利益最大化的前提下(而非个人学习或成就感)，他会不会打从心e支持你做这样的试验。如果不会，那就千万不要做。因为在你做的很开心的同时，别人可能觉得这只是在浪费公司资源。

(10)变成一个更像PM的人

在技术上你应该向你其他工程师同事看齐，但在「性格」或「行为」上，通常你应该去模仿PM team的人。请相信我，在绝大多数公司，「性格」和「行椤菇似于PM的工程师，在公司e是最吃香的。

写这篇文章，也许还会再得到一些批评。但我只是单纯善意的，想告诉工程师们。我们应该提高自己的能见度，适度的让其他人看到我们的表现。以及让自己变成一个外表看起来像PM的工程师，通常在公司e会过得蛮好的。很多工程师会觉得自己被PM欺负，但PM通常不会欺负长得和他们一样的人。如果你喜欢这篇文章，也许你可以再看看这篇: PM如何突破工程师心防？

篇2：PM与工程师续

不久前我写了篇日志，讲我的一点经验，PM如何与工程师协作，但是知易行难啊，最近我们的工程师也有点小抱怨，认为需求变动较多，太折腾了。我听到以后很警惕，查了一遍，发现变动的需求大部分还算合理。半年多来一直强调敏捷，敏捷，有什么想法就快速发布出来，再根据上线效果进行调整。因此“一步到位”的方案是不可能的，而快速调整是必须的。

这时工程师就有意见了，觉得后续的修补太多，浪费时间，希望发布第一个版本的时候能够谨慎一些，周全一些。但这其实和“敏捷风格”是相悖的。

我想了想，问题并不在于工程师不认可这个敏捷风格，而是不理解为什么要做这个，为什么要调整那个。我们的PM把设计案写得清晰完整，这是“提交任务”的环节，可是还漏了另一个环节，即“解释说服”的部分。

去年看一篇介绍Facebook的文章，讲他们的PM权力很小，PM必须用自己的方案吸引住工程师，才能换得他们的投入，而工程师又必须去说动交互与视觉设计师，为这项开发提供支持。总之，如果不能说服配合你的人，在Facebook寸步难行。

初看这篇文章时，觉得简直是PM的噩梦，后来细细一想，又大有道理。如果某个方案都不能说服自己的同伴，是否隐患多多呢?换个角度，即便方案最后被证实是错误的，当初支持过它的所有人都会共同承担责任——主要是精神上的自责，而不会互相埋怨造成内耗。

只不过，Facebook这个管理文化还有两项大前提，轻易照搬不动。

1、只聘请最优秀的工程师，有较高的产品素养。

2、每个员工都是自家产品的用户，感同身受，有不错的用研基础。

所以其他公司盲目学习Facebook这一套，必死无疑，但其中的道理是共通的。怎样让团队齐心协力呢?必要条件是对自己的任务有认同感。这个认同感不是靠升职加薪换来的，也不是靠请吃饭拉关系换来的，而是你必须说服他，做这个事情是有价值的，值得你花时间去弄。大到产品方向，小到交互优化，都不例外。

每个月的月初，我会开一小时部门例会，滔滔不绝地讲近期的版本路线。每次花两三个小时来准备PPT。在我看来，在座的每一个人都是我的客户，我希望靠说服力(而不是权力)来打动他们，接受我的产品计划，

在每周的策划运营例会上，在我跟策划组与运营组的单独沟通中，这种演说不断持续——虽然有点嗦，但可以保证沟通充分，不存在对任务的抵触情绪。

PM与工程师的协作，也应该学习我这个态度。PM既不是请求工程师去做这个，更不是安排工程师去做那个，而是通过绘声绘色的说明，与工程师达成共识，我们下阶段就应该做这个做那个。

因此，我在每周四下午安排了一场30-60分钟的会议，PM与工程师参加。PM这边有一份庞大的需求总表，大约涵盖了2-3个月的开发需求，随时增补修订。然后在会议上根据优先级，对工程师讲解与讨论接下来的开发计划，并确定下周的发布内容(紧急需求除外)。对这种讨论之前其实是有要求的，但如果不予以流程化，制度化，就容易荒废掉，口号永远只是一滩糖稀屎。“提单-接单”的传统协作形式必须被“讲解-倾听-讨论”所替代。

上周我在新浪发了条微博，说产品协作的根本出路是让工程师加入设计讨论，共同确认方案，共同对结果负责。这条微博的回复很多。不少人提出，工程师哪里有这么多时间参与产品设计?又有人说，所有人都负责，相当于所有人不负责。这些都是误解。工程师只在几个关键节点(架构提出/方案确认/进度安排) 参与进来，占用时间有限;而所谓“共同负责”，意思是当初你不出声反对，事后就得同甘共苦;当初你接受了这份开发计划，便不会指责PM拍脑袋瞎折腾。对产品负责到底的必然是PM，他同时还需要说服所有同伴接受自己的方案。

在我这里，这个做法是可以被执行下去的。又有人留言说，第一，沟通能力足够强的PM比较少，没有能力说服别人;第二，对产品有感觉的工程师比较少，固执的工程师却很多。他说的也是常见情况。这属于团队建设的问题，团队经验与内部磨合都支撑不了协作上的民主，但换个角度来看，这样的团队是否也很难做好产品呢?与其独裁管理，不如多花心思在招聘与培训上。

另外还有一种情况，在创业阶段，打算做点创新的事情。由于用户反馈很少，多半凭主观感觉去摸索，说服力有限，容易发生分歧。而创业最怕的就是内耗，一争执，一慢下来就完了。这时PM与工程师的合力很难形成，更不适合搞一言堂——摸索中的试错成本加重了内部矛盾。肿么办?所以牛逼的创业团队都是技术主导，带头大哥兼具工程师与PM的双重属性，自己想清楚了，挽起袖子就写代码，雌雄合体知行合一，非此不足以杀出血路。

PM与工程师要相亲相爱。

作者：纯银

篇3：PM如何突破工程师心防

PM常常遇到一个难题，就是有好多东西想要做，到无奈什N事都得透过工程师，没办法自己动手，於是因为和工程师不太美好的关系，最后实际的a品都没有设计时看起来好，我这边讲的是「网路公司」的状态，PM泛指那些规划出产品的人。其他产业也许也有类似情形，以下这些「教战手则」，提供给正在摸索自己生存之道的PM一些参考。

0、先弄清什么做得出来、什么做不出来:

常常有PM会提出一些天马行空的idea，以致有时候让工程师觉得合作起来相当吃力。这是由于并不知道什么可以做什么不能做。以网站来说，这其实很容易知道，不需要太多的学习和知识。如果有一个功能，你在两、三个网站都看得到，99%它是做得出来的。例如你想要有一个页面，填地址时选完「县市」，下一个选单就会载入你选的这个县市的行政区。如果你做些功课，就可以发现这样的表单在很多网站都出现过。那99%就是做得出来。如果你想出一种呈现的方式，从来没在任何地看过，那就比较有可能是做不出来的。在对工程师沟通时，假如你想做一个像这种选「县市」的下拉选单，你最好请工程师去看别人的那个网页，而不是用你自己的方式描述。工程师通常有不想输的性格，如果别的网站做得出来，他不会想要自己做不出来。

1、永远不要和工师辩论任何和技术有关的东西:

当PM能学一点点网页的概念是好的，但跟工程师合作，你可能常常会听到「这很难做」的feedback。它可能代表几种不同的意思。可能代表真的很难做，也可能代表他不想帮你做。如果是第二种，有很多种方法可以让他妥协。但戳破他和找他辩论绝对是最差劲的方法。当他说这个技术上有困难时，绝对不要跟他说「这个只要… 就可以了呀!」这样也许让自己看起来比较聪明，但你们的关系已经完蛋了。而且工程师的性格容易有非常强的自尊心，所以千万别这么做。而且，technical的领域，你可能永远也辩不赢他。很多「这个不能做」的问题，不是来自于理性，而是来自于不想、不愿意、觉得这个没意义、或真的很花时间。真的要做的话，99%的东西大概都可以做。因此当这种看起来由technical角度来拒绝你的状况发生，如果你真的很想坚持你的想法做下去，请试著脱离technical的讨论，你该了解他所提出technical的障碍，但绝对不要和他在这个领域上辩论。因槟惚缬或输都没有任何好处。

2、工程师喜欢你去求他:

工程师很容易有某一种性格，是坐在那边希望大家都去拜拖他。所以你不难想像要让这种人帮你做事的方法就是你要放低你的姿态。你要让他觉得是你需要他，不是他一定要帮你。即使你心里一直想「公司付你钱来上班本来就是要做这些的…」放低姿态，

也许身为PM的你，在每个project有进展的时候和卡住没进展的时刻，拿饮料点的menu去问工程师要喝什N是个好方法。

3、把所有credit归给工程师:

在公司里，因楹芏嗖品是由PM规划的。因此project的成功，大家很容易觉得是PM的功劳。请努力在任何公开的场合、email，把这些credit归给和你一起合作的工程师。同样一个spec，一个心情好的工程师，可以把它做成100分。一个心情不好的工程师，可以把它做成60分。两个都可以100%符合你的spec，但是一个可以烂到有无数问题。因槿硖宀皇鞘虑翱梢韵肭宄的。所以一个不开心的工程师，可以看到许多问题但「视而不见」，也不主动来跟你说，那你就完了。所以一定要让全公司的人都觉得这些成就属於工程师的。你把credit拿走一次，下一次你就完了，因槊挥腥讼槟懵裘了。

4、不要轻视「工程师的project」

你合作的工程师可能说他现很忙，因为他正在「重写一些function」或是「让资料库的速度快一点点」。很多PM在听到这些的时候，并没有很知道他们在做什么，於是表现出来的会是对这些project没那N在乎或甚至不觉得他们重要。通常工程师最喜欢做这种隐性的project。因樗们可以不用听PM的指挥。对於一个健康的公司来说，一定会有一定比例的资源投在这些project。要不要做通常是由老板，或更懂得这些东西的人来决定。但你一定要在工程师的面前让大家觉得你看起来对这些非常认同。

5、姿态放软，但不能失去主导权

虽然前面说你姿态要软，但你绝对不能把你的project交给工程师后，你就失去了主导权。因为这样会让你在老板面前，看起来变得没有太多价值。你最少要继续掌握你project的「时程」和「内容」。也就是你一定要维持你的「主导权」，对该坚持的东西继续坚持，对一些东西妥协，但不能全交给工程师决定。

6、不要finalize所有设计后，再交给工程师

绝大多数的工程师对这样的流程很反感，所以请想办法在设计阶段，就去请教一下工程师的意见。他也许说他很忙，你想就好。即使只是得到这句话，都有很大的价值。这表示他放弃了他未来因为你在project早期没找他先过过，以致他责怪你的权利。

总之，因为工程师的心情很难捉摸。所以「情绪」的处理问题，可能比「技术」、「功能」上的讨论都更为重要。如果你喜欢这篇文章，也许你可以再读一读这篇的「相反版」:工程师如何不被PM欺负?

篇4：PM与工程师交互设计

过节前看到一篇文章，讲产品项目就应该由工程师来主导，但国内让PM去驱动项目，搞得乱七八糟，很恼火，怎么可能做出一款好产品来呢？

很显然，写这篇文章的是一位愤怒的工程师，Angry Engineer！我跟他至少有两点共鸣：

1、国内的PM确实常常折腾工程师，甚至不乏“把工程师当工具对待”的情况，

2、如果工程师有开阔的产品视野与全面的设计素养，知行合一，由工程师来驱动项目是一个完美的选择。

可惜由于教育环境的问题，国内通才太少。一个优秀的工程师，同时又是一个优秀的PM，凤毛麟角，只能人任其长，各自做自己拿手的活儿。这时候更擅长需求分析与产品设计的PM来驱动项目，也是不得已的选择。

说来惭愧。需求不靠谱，或是来来回回修改，折腾工程师的事儿我也做过不少，直到最近一年多才算是大有好转。我应该忏悔……虽然能做好PM的工程师极少，靠谱的PM其实也不算多，最后大家都得写周报对不对？

在产品行业远远不够成熟的现阶段，痛苦的来回折腾难以避免。但最起码，PM应该把工程师作为伙伴而不是工具，想法设法地站到一条战壕里去，争取他们的理解。因此抛开难以鉴定的需求的对错，仅仅从协作流程的改进上，我积累了以下的经验。

首先要得到工程师对整个项目的认同。每个月都有一场一小时的部门月会，对着PPT，我来讲下个月乃至下个阶段，我们的任务规划是什么，目标设置又是什么，详细解释制定规划与目标的原因，近景与远景分析，为咩做这件事情为咩这样去设计等等。希望工程师能认可他即将做的事情是有价值的，值得为之而努力的。为接下来PM与工程师的沟通做好铺垫。

月会上还有一个环节，详细分析本月发生的所有数据，尤其是最近发布的新功能的数据。这个环节也是为工程师准备的，使他们了解自己的工作能产生多少实际效果。

至于月会上送出的新功能礼品（以前讲过许多次），最开始是为工程师专设的彩蛋，再后来才将PM与运营包括了进来。我得承认自己对工程师偏心眼，因为有信心能激励PM与运营，却出于沟通深度不足，需要借助更多的手段来激励工程师投入项目。

项目任务分两种，大版本与小模块。对于大版本，在基本框架定下来之后，PM提前向工程师讲解，听取技术视角对设计方向的建议。整个设计过程中还会反复讨论三五次，为技术上的合理性征求意见。小模块则在策划案基本敲定之后，与工程师共同确认一次，视觉稿出来后再通报一次。（所以PM与工程师坐得近是很有必要的）

我曾经在部门月会上公开承诺说，任何一个需求，只要工程师认为是不合理的，都可以停下来不做。直到PM能说服工程师为止。如果死活谈不下来，才由我和技术经理出面来协调。强硬要求服从的情况在我这里基本上没有，被工程师说服倒是时有发生，按工程师提出的意见来改方案。我也常常跟PM讲，小分歧你们都听工程师的，没有必要坚持己见。你让他爽一点，开发速度就快一点，大家都获益。再说你多听听技术伙伴的意见有什么不好呢？帮助你转换思考的角度，共同找到提高开发效率的方法。

最后方案定下来了，PM说OK，工程师也觉得方向大致没错，细节基本合理；进度方面则由工程师进行评估。PM觉得时间太长接受不了，再找到我和技术经理一起商量，看是分阶段砍需求呢，还是加把力加点班。除了极少数紧急修复任务外，不会由PM单方面确定开发时间安排。包括一系列任务的优先级安排，也由PM先提草案，工程师根据开发情况来调整顺序，再共同确认。

在PM提出需求的整个流程里，始终在进行不断的协商，保证工程师对任务是理解并且接受的，不会出现抗拒，或者是麻木的心态。如果遇到突发性的需求变更，更加会向工程师反复解释，请求谅解，因为浪费了他们的工作成果而心存歉意。为此而花费的时间对比更高的开发效率，稳赚不赔。虽说具体协作时还有一些不到位的地方，但态度总归是好的，基本的效果也是有的。

当然，这套流程的实施得具备两个前提。第一是有稳定的团队，如果变成提单协作，这个月一起干下个月分道扬镳，那就不可能实现共同的项目归属感。第二是工程师的个人素质基本靠谱，沟通顺畅；尤其是技术经理可以服众，协调好分歧而不护短。比如说一个功能能不能做，至少开发多久，我和PM都搞不掂，主要靠技术经理来做最终判断；如果出现开发过程中的失误，或是不按照约定好的方案进行开发，则由技术经理进行处罚。我对开发组更多作行政管理，全靠这位技术核心伙伴来负责业务管理，他也会更深入地参与到产品的结构设计，任务规划里来。

这样做，也就撇开了把工程师当工具对待的嫌疑，

我觉得把任何同事当工具都挺可耻。怎样才算是伙伴呢？比如交流必要的信息，理解对方；比如能站在对方立场去换位思考；比如多一点点鼓励与帮助。

换个角度看，我这边曾经出现过由工程师来提出大致构思，PM认可并负责细节设计，再由这位工程师来实现的情况。结果皆大欢喜。我后来多次在月会或别的场合征求工程师的创意，换一换视角，引入新鲜的想法与灵感。即便想法不一致，也会非常温和地解释反对原因，绝不可能一口否决。唯恐工程师们默不出声闷头干活——听不到技术伙伴的意见是多大的损失啊。

以上来自：/uidesign/20110503/91582.html

也谈：PM与工程师

来自：/uidesign/20110503/91582.html

看了纯银写的《PM与工程师》，也参加了PMCAFF深圳3月份的活动聚会，就这个话题聊聊自己的感想。

PM与工程师最容易产生冲突的地方在于需求和进度：产品需求变更折磨工程师、项目进度延迟、产品质量不过关，影响到产品的上线和运营。

大体上，可以通过下面几点来避免：

(1) 认同，归属感

在产品规划阶段，跟工程师多聊聊，聊一聊项目背景、市场机会、我们做这个产品对公司有什么好处、以及很关键的一点是产品的成败对我们切身利益的影响。建议工程师的认同感，归属感，并唤起他们的主人翁意识。

归属感这点：在抄送邮件时，我也会主动提起某某工程师的名字，对他们的配合表示感谢，对他们的工作表示赞同。

（2）产品评审，可行性分析

快速产出一个产品DEMO，召集工程师、运营人员等相关人员评审，简单再讲讲产品背景，我们要做的是什么；这个版本是拿来投石问路的，一方面是可行性分析，另一方面集思广益。

在这个评审会议上，产品的主要方向和功能点都能确定下来。