目录
- 和谐团队必备要素
- 我所期待的PM
- 做一个合格的程序
- 总结
正文
上周，又看见有程序和PM（产品经理）吵了起来，大致是因为晚上就要上线了，下午的时候PM来说要改点需求，但程序不愿意。兴许是天气热了，大家都很烦躁，于是一言不合就发飙了，最终还是程序老大介入才解决了问题。
程序和PM的最大矛盾应该就是需求：提需求、改需求。
但程序和PM一定是对立的双方吗？显然不是，大家应该是同一个战壕的战友才对。回想起来，我也曾经和PM因为各种或大或小的原因有过争执（还好，没有打起来过 ）。事后想来，其实很蠢，因为争吵根本不解决问题，反而引出新的问题。
那么，程序和PM怎么和谐相处呢，这其实需要大家刻意的去努力。本文记录一下自己在这方便的感想。
本文地址：https://www.cnblogs.com/xybaby/p/10923990.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当头一棒，极不礼貌，至少应该先详细解释原因。其次，这样的话说多了，在别人看来就是不负责、能力也不行。
当然，如果没认真思考与评估，急于答应也不行，承诺了就要办到，不要把事情搞砸，才能建立自己的信誉。
总结
回到顶部
说了这么多，其实有些凌乱。
个人觉得，最重要的其实就是换位思考，换个立场，事情也许就会完全不一样。我们常说，旁观者清，当局者迷，但最重要的是我们要有意识从“当局者”切换到“旁观者”视角。
另外，也许你很牛逼，但请用一个普通人的标准要求对方，严于律己，宽以待人。
本文版权归作者xybaby（博文地址：http://www.cnblogs.com/xybaby/）所有，欢迎转载和商用，请在文章页面明显位置给出原文链接并保留此段声明，否则保留追究法律责任的权利，其他事项，可留言咨询。
