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

最新推荐文章于 2021-05-24 14:41:51 发布

小二人

最新推荐文章于 2021-05-24 14:41:51 发布

阅读量377

点赞数

分类专栏：职业发展

原文链接：https://www.cnblogs.com/xybaby/p/10923990.html

版权

职业发展专栏收录该内容

12 篇文章 0 订阅

订阅专栏

和谐团队必备要素
我所期待的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的主题颜色能根据手机壳自动调整”，或者“五彩斑斓的黑”。另外，程序和你沟通起来也会畅快很多，自然也会对你刮目相看。