看 andy 的《PM 如何突破工程师心防?》和《工程师如何不被 PM 欺负》感触了一下，欢迎拍砖，讨论。

从团队角度说产品经理和开发工程师应该是一条战线上的兄弟，因为大家的目标是一致的。无论是产品经理和开发工程师大家都想把产品和项目做好，这里我们可以说：“志同”。

但是产品经理和开发工程师因为在产品开发过程中所扮演的角色和工作内容不同，而且可能相互不了解工作内容，期间会有很多沟通的成本，沟通不是说话，而是改变行动。真正的沟通者关注沟通的效果。在沟通时，重要的不是你说了什么，而是对方理解了什么，所以对方的反馈非常重要。往往很多产品经理和开发工程师的沟通会出现 “驴头不对马嘴” 大家相互听不懂的情况，甚至会导致小摩擦，这时我们说：“道不合”。

“道不同不相为谋”，必定导致意见不一，甚至带来工作上心情不愉快的影响。不管是产品经理和开发工程师哪一方强势，或者在 “交战” 过程中哪一方 “得胜”，势必会给另一方造成消极影响，甚至颓废。导致的结果总会是这个产品或者性能，或者其他方面总是会有不尽人意的地方。项目结束，考核绩效或者项目总结的时候又会把责任推到对方身上，接下来就是大家相互抱怨，指责。然后产品改进时又是下一轮的 “战争”；长此以往，造成的影响不是产品做不好，不是主要的后果，这个产品做不好，我们可以改进，可以做下一个产品。最严重的后果是，团队分崩离析，一盘散沙，没有凝聚力。没有凝聚力的团队是绝对没有战斗力的，是绝对做不出好的产品的。这对团队和公司来说是致命的。

虽然很多人都明白这些，然而，这样的 “战斗” 或者产品经理和开发工程师的矛盾却时时刻刻在发生！大家可以看看知乎上两个问答：

1.《产品经理最讨厌开发人员的哪些臭毛病？》 http://www.zhihu.com/question/19629183 2.《开发人员最讨厌产品经理的哪些臭毛病？》 http://www.zhihu.com/question/19628273

如何解决这些问题，请看 andy 的《PM 如何突破工程师心防?》和《工程师如何不被 PM 欺负》，虽然在实际的过程中你未必能做到，但是至少我们可以从中得到一些启示。

=================================================

PM 如何突破工程师心防?

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

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

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

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

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

3. 工程师喜欢你去求他:

工程师很容易有某一种性格，是坐在那边希望大家都去拜托他。所以你不难想像要让这种人帮你做事的方法就是你要放低你的姿态。你要让他觉得是你需要他，不是他一定要帮你。即使你心里一直想「公司付你钱来上班本来就是要做这些的…」放低姿态。也许身为 PM 的你，在每个 project 有进展的时候和卡住没进展的时刻，拿饮料点的 menu 去问工程师要喝什么是个好方法。

4. 把所有 credit 归给工程师:

在公司里，因为很多产品是由 PM 规划的。因此 project 的成功，大家很容易觉得是 PM 的功劳。请努力在任何公开的场合、email，把这些 credit 归给和你一起合作的工程师。同样一个 spec，一个心情好的工程师，可以把它做成 100 分。一个心情不好的工程师，可以把它做成 60 分。两个都可以 100% 符合你的 spec，但是一个可以烂到有无数问题。因为软体不是事前可以想清楚的。所以一个不开心的工程师，可以看到许多问题但「视而不见」，也不主动来跟你说，那你就完了。所以一定要让全公司的人都觉得这些成就属于工程师的。你把 credit 拿走一次，下一次你就完了，因为没有人想为你卖命了。

5. 不要轻视「工程师的 project」

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

6. 姿态放软，但不能失去主导权

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

7. 不要 finalize 所有设计后，再交给工程师

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

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

=================================================

工程师如何不被 PM 欺负

转自：http://www.kuobrothers.com/article-127.htm

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

(1) 提高自己的能见度

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

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

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

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

工程师由于角色的关系，非常容易会站在「技术」的角度想事情，但往往常被主管否决而觉得灰心。公司的想法通常和 PM 的想法比较接近，都是站在公司的利益想事情，极少用「技术」的角度想事情。你要试着跟他们想的一样，你的日子才会过得快乐。举例来说: 假如我们公司现在要输入 10000 笔资料。有两个方案，方案 A 是「手动输入」，方案 B 是「用程式自动汇入」。方案 A 要请 10 个工读生，一笔一笔输入几乎都没有差太多的资料。方案 B 是支无敌厉害的程式，你开发一天，程式跑 3 秒钟就全部完成。但评估起来方案 A 的总体成本比方案 B 还要低。我相信极大多数的公司经营者，都会愿意找来 10 个人，做着重复的事情，一笔一笔 key in 资料。如果你以工程师的角度来想，你可能会觉得「这个这么简单，一支程式就好了」，然后开始觉得老板选择方案 B 真迂腐。你要试着让你的大脑跟公司的利益 sync，这样会让你好过很多。因为绝大多数的 PM 都知道他们的大脑要怎么跟老板 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，就认为这是你自己做出来的。因为这样除了自己感觉良好外，对职场生存没有帮助。想办法「言必谈 PM」。把自己和 PM 当成一个 team，这个 project 是我们一起做出来的。虽然很多 PM 会戏称自己是在旁边帮忙打杂的，但是他会很感谢你很体贴的把一些功劳归于他。

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

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

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

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

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

转自：http://www.css88.com/archives/4545