上周,又看见有程序和PM(产品经理)吵了起来,大致是因为晚上就要上线了,下午的时候PM来说要改点需求,但程序不愿意。兴许是天气热了,大家都很烦躁,于是一言不合就发飙了,最终还是程序老大介入才解决了问题。



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

但程序和PM一定是对立的双方吗?显然不是,大家应该是同一个战壕的战友才对。回想起来,我也曾经和PM因为各种或大或小的原因有过争执(还好,没有打起来过
)。事后想来,其实很蠢,因为争吵根本不解决问题,反而引出新的问题。

那么,程序和PM怎么和谐相处呢,这其实需要大家刻意的去努力。本文记录一下自己在这方便的感想。

本文地址:https://www.cnblogs.com/xybaby/p/10923990.html
<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的主题颜色能根据手机壳自动调整”,或者“五彩斑斓的黑”。另外,程序和你沟通起来也会畅快很多,自然也会对你刮目相看。



做一个合格的程序

之前写过一个篇文章,怎样才算得上合格的程序员 <http://www.cnblogs.com/xybaby/p/7531620.html>
。在这里,简单补充一下我觉得怎么样才能与PM和谐相处。

意识到技术服务于业务

对于开发者个人而言,也许专业技术是自己最重要的技能。但对于团队或者给程序员开工资的公司来说,业务才是最重要的,再牛逼的技术如果不能支撑业务那都没有什么鸟用。

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

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

建议读读这篇很有意思的文章,PM 叫你去改一个 Bug,后来…… <http://blog.jobbole.com/105832/>

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

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

要想一次性把事情做到完美,就是 one take,但可望不可即 <https://www.cnblogs.com/xybaby/p/9607331.html>

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

尽早交付,及时发现问题


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

不要总是拒绝,也不要太快承诺


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

当然,如果没认真思考与评估,急于答应也不行,承诺了就要办到,不要把事情搞砸,才能建立自己的信誉。



总结

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

个人觉得,最重要的其实就是换位思考,换个立场,事情也许就会完全不一样。我们常说,旁观者清,当局者迷,但最重要的是我们要有意识从“当局者”切换到“旁观者”视角。

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

友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信