做为程序员，不再想和PM干架了

上周，又看见有程序和PM（产品经理）吵了起来，大体是由于晚上就要上线了，下午的时候PM来讲要改点需求，但程序不肯意。兴许是天气热了，你们都很烦躁，因而一言不合就发飙了，最终仍是程序老大介入才解决了问题。

程序和PM的最大矛盾应该就是需求：提需求、改需求。

但程序和PM必定是对立的双方吗？显然不是，你们应该是同一个战壕的战友才对。回想起来，我也曾经和PM由于各类或大或小的缘由有过争执（还好，没有打起来过 ）。过后想来，其实很蠢，由于争吵根本不解决问题，反而引出新的问题。

那么，程序和PM怎么和谐相处呢，这其实须要你们刻意的去努力。本文记录一下本身在这方便的感想。

本文地址：http://www.javashuo.com/article/p-xfoaeata-bb.html

和谐团队必备要素

团队不是我的的简单叠加，团队的良好协做须要团队中的全部角色（PM、程序、交互、测试）的共同努力。

一致的目标

大了说，是公司的愿景、使命；小了说，是团队的近期目标。只有你们向着同一个方向努力，才能尽可能避免1+1 < 2。做为一个职场人，一个很直观的目标就是尽职尽责把产品（业务）作好。但这个看似很明确的目标，也是有歧义的，也许PM是想尽快上线，抢占先机；而程序是想，把代码架构作得通用、可扩展，以便后续的需求更改。团队负责人应该多和你们沟通项目的长远目标和短时间目标，消除歧义，只有当你们达成共识，才能劲往一处使，才会追求双赢。

平等、相互尊重

产品经理带有“经理”二字，彷佛有管理的问道，但其实和“程序猿”、“运维狗”同样，都是来干活的，只是分工不一样而已。我是程序猿，并不十分了解有没有PM自认为高人一等，但我确实知道一些老程序员会鄙视新人PM。PM和程序，任意一方太多强势，都不必定是好事。

承认其专业性

团队中，最忌讳的就是质疑他人的专业性。好比PM说：“这都作不了”，程序员说：“你啥都不懂，瞎逼逼”。若是出现了相似的话语，都会火大，谁还来解决问题。

若是你不是对方领域的资深人士，那么最好是认可其余角色的专业性，常怀敬畏之心。相信你当前拥有的，都是最好的。固然，也会有真的很不专业的人存在，那么找你的leader或者他的leader去反馈，不要直接人身攻击。

有效沟通

沟通的重要性无需赘言，不少时候矛盾不是由于事件自己，而是沟通的方式不对。冷静、友善；对事不对人；以解决问题为目标，应该是一些最基本的原则。

换位思考、同理心

换位思考，即主动站在对方的角度，用对方的思惟方式去思考一样的问题，这样才能相互理解，相互宽容。

有了换位思考，就不难想到下面的每一点。

我所期待的PM

除了上面提到的通用准则，那么从一个程序员的角度出发，我想与之合做的PM还应该有什么特质呢

提需求表达问题而不是解决方案

有的PM会直接过来跟程序说要作什么，可是不耐烦、或者不肯意、或者根本没有意识到要跟程序说说为何要这样作。也就是说，PM表达的，常常是某种解决方案，而不是须要解决的问题。

诚然，PM在需求方面可能更专业，但开发也许会有更好、更便捷的方案来知足需求。并且抱着一块儿解决问题的态度，而不是PM命令开发，也能激发开发人员的自主性，更愉快的去完成任务

改需求要有理有据，最好有数据

程序员最烦的就是改需求、反复地改需求、上线以前改需求。改需求不可怕，关键是这些需求是否通过深思熟虑，最起码，PM得先说服本身，而不是拍脑壳。

若是能够，最好用数据，用事实说话，程序员喜欢说“talk is cheap， show me the code”，那么PM应该用数听说话。若是一个程序员知道这个修改可能增长多少点击率、转化率的时候，我相信他是愿意去修改的。

以最小的代价试错

PM的需求来自市场或者说用户，而开发的需求来自PM。相对来讲，对PM的需求更模糊，对开发的需求更具体。这就致使，PM更难一次性把事情作对，PM不少时候无法本身验证本身的想法，须要借助开发的力量。可是，一个合格的PM应该认识到，若是本身作错了，那么浪费的不只是本身的时间，还有别人的时间。所以应该尽最大努力减小试错的次数，保证交给开发的需求已是通过足够的市场、竞品调研，有了充足的思考与讨论。

跟进需求的进度

PM是项目或者某个功能的第一负责人，那么应该实时了解进度。信息在传递的过程当中会失真，你们对同一句描述的理解也会有歧义。那么程序员所理解的、所开发的内容是否符合PM最初的想法呢，这个就须要PM主动去了解、跟进了。最怕的就是，程序员辛辛苦苦干了一个月，结果PM说作出来的东西不是本身想要的。

并且，在没有实物参考以前，PM可能也没完全想清楚本身想要什么，所以要尽早验证本身的想法。

及时向上汇报

这一点跟上一点有类似之处。

有的时候，一个大项目会有多个产品经理，每人负责一部分功能，好比游戏开发通常都会多个策划。若是一个PM自知专业水平不是足够高，或者说本身也想不清楚，那么最好及早向直系老大负责汇报，在有完善的交互、或者一个可展现的demo时就像老大汇报。避免等程序作完以后，老大不满意，致使推翻重来。

加分项：懂技术的PM

懂点技术的PM，首先不会提出变态的需求，如“APP的主题颜色能根据手机壳自动调整”，或者“五彩斑斓的黑”。另外，程序和你沟通起来也会畅快不少，天然也会对你另眼相看。

作一个合格的程序

以前写过一个篇文章，怎样才算得上合格的程序员。在这里，简单补充一下我以为怎么样才能与PM和谐相处。

意识到技术服务于业务

对于开发者我的而言，也许专业技术是本身最重要的技能。但对于团队或者给程序员开工资的公司来讲，业务才是最重要的，再牛逼的技术若是不能支撑业务那都没有什么鸟用。

业务的发展会倒逼技术、架构的成长，反之则不能。

好的程序员，努力让代码去适应业务，同时让代码更具可读性、更具扩展性、更加优美。可是万一与业务需求冲突，那仍是应该先知足需求吧。

建议读读这篇颇有意思的文章，PM 叫你去改一个 Bug，后来……

意识到需求迭代是没法避免的

程序员都知道，代码是不大可能一遍就写好的，尤为是敏捷开发、快速迭代的模式，因此才会有代码的重构。咱们也常听大牛说，好的架构不是设计出来的，而是演化而来的。

要想一次性把事情作到完美，就是 one take,但望尘莫及

度己及人，PM也很难一次就将需求提对，也须要实践、验证、改善，反复循环。而程序应该作的是，参与到需求迭代中，用本身的专业知识缩短迭代的周期以及次数。

尽早交付，及时发现问题

上面提到，需求的迭代无可避免，为了减小浪费的时间，那么程序员应该尽早交互，只要有可体验的版本、甚至只是可见的界面，都应该让PM来看看。虽然前面提到，PM应该主动及时跟进进度，可是程序员也应该主动参与，这也能为本身节省时间。

不要老是拒绝，也不要太快承诺

有的程序员老是习惯生硬地抛出“作不了”这几个字来拒绝PM，也许是真作不了，也许是本身不想作。首先，这样说直接给PM当头一棒，极不礼貌，至少应该先详细解释缘由。其次，这样的话说多了，在别人看来就是不负责、能力也不行。

固然，若是没认真思考与评估，急于答应也不行，承诺了就要办到，不要把事情搞砸，才能创建本身的信誉。

总结

说了这么多，其实有些凌乱。

我的以为，最重要的其实就是换位思考，换个立场，事情也许就会彻底不同。咱们常说，旁观者清，当局者迷，但最重要的是咱们要有意识从“当局者”切换到“旁观者”视角。

另外，也许你很牛逼，但请用一个普通人的标准要求对方，严于律己，宽以待人。