产品经理和程序员的那些“恩怨情仇”

产品经理和程序员的那些“恩怨情仇”

相信大家读听过“五个程序员杀了两个产品经理”的故事,虽然故事有点夸大,但却反映了程序员和产品经理之间长久以来的“恩怨”。做为开发中的两个关键角色,程序员和产品经理的冲突在哪里呢?

首先,我们先来总结一下,冲突发生在哪里?

第一点,产品经理不尊重技术规则,程序员不尊重产品经理的创作用心

这方面可以总结的例子很多,举一个极端的例子:程序员调了一天的bug,产品经理过来看了看,直接就说一句:“今天什么都没改嘛”,甚至有的产品经理就可能说出这个程序员“很懒”的话来。

Bug有很多种类。很多不懂技术的产品,大多都以为程序员解决的问题都是自己操作上用到的或者看得到的功能,对一些纯技术层面的东西是不大了解,更不懂得做这些事情需要花费的时间。只要界面不变,操作不变,就觉得程序员没有在做事情。对于一些有难点的技术问题,程序员“当机”好几天的情况还是会有发生的,这个需要产品经理多去理解。

还有一种“Bug越改越多”的情况,这个估计也是不懂技术的产品经理无法理解的。项目开发催得越紧,程序员自顾不暇,出状况的概率也会变高;不经意修改了核心代码的某个部分,连锁效应就会影响到很多关联部分的代码,对正在验收的产品经理来说,就是一夜回到解放前的感觉;甚至会觉得是程序员在“使坏”,故意搞的。

另一方面,程序员跟IT的关联更为密切,对计算机、互联网的产品的了解是随着兴趣、从学习开发语言的时候就开始了,所以对于互联网产品都会有自己的见解。但往往也会因为这样,对产品经理的工作指指点点,甚至把对产品原型的不满情绪带入开发当中。

同类的问题很多,产品经理若懂得技术,那固然是好事情。但这个要求不大合理,那需要的就是需要双方各自尊重对方的“专业”。产品经理对技术不要盲目揣测,程序员也要尊重产品经理的专业性,多体会产品经理创作产品的用心。

第二点,关于开发进度

有的时候,程序员迫于压力和暂时的效率自信,预估的工期本身就是短了的。进度问题已经发生,程序员在努力赶进度的时候,产品经理来了:“为什么这么慢?不是说好什么时候做完的吗?”;或者一个功能一个功能地过“这没做完,这个也没做完”;甚者“最多给你两天,后天一定要做完”。进度没有完成,产品经理的心情可以理解,但是这些有帮助吗?时间用在这些方面了,谁来写代码?搞到程序员心情烦躁,还能指望着效率的提升吗?

进度问题的产生,需要产品经理和程序一起总结,共同探讨解决的方案。但毕竟这是共同完成的一个项目,双方的信任还是必须要有的,另外还是需要把精力用到开发上面,而不是没完没了的争执和总结。

同时为了确保开发进度,产品经理需要多做一些“细致”的工作。有些产品出的产品原型,是只有“主线”的页面的,看图能理解开发的是个什么样的产品,大致怎样的流程和处理方式。但在开发中间,程序员会发现有很多的“缺失”而走不下去。极端的情况,有直接给程序员产品原型和一两张主要界面的UI图,就让程序员去开发的,各种去操作的界面让程序员去脑补,或者是需要的时候再去要,再去补。这样自然会影响进度。这部分的图可以晚点给,但进入开发之前一定要提前交给程序员。

关于工期的预估,产品经理也需要和程序员提前进行沟通,不要自己做工期的预估,如果产品经理的经验更丰富些,对于一些程序员过于自信的估计,要有自己的坚持。

第三点,关于“改动后”的需求

这个冲突的根源,更多是产品经理和“老板们”关起门来开了个会,脑细胞激荡后,赶出原型和UI图,之后交给程序员的就是“圣旨”。“反正我们就这么定了,你照着开发吧,技术问题自己解决”,更可怕的再来一句“这个改的不多,工期还是按照原来的哦”。

如果是懂技术的产品经理,对当前开发的程序架构有充分的了解,并且对改动后的需求已经有了明确且可行的技术解决方案,倒也无可厚非。但是,如果到了程序员哪里,真成了要“大动干戈”的事情,那这个怎么去收拾?产品经理再去和“老板们”头脑风暴?估计很多产品经理是不愿意这么去和“老板们”重来一遍的,那么就变成了对程序员的“收买”或者是“战争”。

我的建议,但凡是涉及到“需求改动”的,产品经理最好是先和程序员讨论一下方案的可行性。尤其是对那种“层级关系”比较分明的公司,这点尤其重要。

第四点,关于“反技术”的原型设计

这点我想单独拿出来说一下,因为对于创业公司来说这点尤其重要,“反技术”的设计意味着成本大幅度升高。

大多数产品由于不懂技术,不清楚不同操作系统有什么不同,iOS有的,非得安卓的APP也要,也不考虑当前可用的开发能力,即便只有一个程序员也要求各种细节的提升和完备,各种“极致”。

对创业项目来说,能充分利用现有的资源,对开发必然会有很大的帮助,但如果一个项目,各种组件、各种操作都是“新”的,都需要程序员去研发,甚至超出程序员的当前能力要求,这似乎就有点不应该了。

如果要避免出现这种状况,在原型确定前多和程序员沟通是很有必要的。

第五点,关于验收

大部分的项目团队,验收都很靠后,都会等到beta版本出现之后,才进入验收环节,一旦出现问题,就是各种修改。

中途介入验收,能提前进入验收环节,把验收分散于整个开发的环节当中,提升产品的品质。但是需要有合适的配套工具,否则也会导致工作量的增加。另外需要转变验收的心态,不能把半成品当成是成品来验收,或者是当成是盯程序员工作进度的工具“这个做了这么多时间,那个简单点的,为什么也要用那么多时间。”等等。

第六点,不得不说的BOSS

是谁在阻止“程序员”和“产品经理”的相爱?

作为产品经理,需要一款产品让自己扬名立万,而这个产品出自你身边的程序员之手;

一款好的产品,也能给程序员带来资历的提升,提升自己的身价。

所以,还是好好相爱吧!

往期精彩回顾,点击浏览

程序员如果没有自学能力,不如尽快转行

Java程序员编程学习之路资源合集

20套Java项目200套Android项目200套小程序

Java自学?Java自学编程大放送

原文发布于微信公众号 - Java社区(Java5206868)

原文发表时间:2018-05-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java一日一条

让程序员/技术主管/项目经理最可怕的事情是什么?

到现在我已经专业地构建软件超过10年时间了。我热爱我的工作,并且我希望能在这一行一直干到成为老程序员的那一天。一路走来,我遇到过很多可怕的事情,让我觉得我的工作...

521
来自专栏服务端技术杂谈

这个时代,写给我们这些浮躁的程序员

2010 年初写过一篇博客(我们是一群和平年代充满浮躁与抱怨的程序员),一年过去了,社会好像更浮躁,也有网友问我这方面的问题,于是有了下面这篇文章,再次写 给我...

28811
来自专栏AzMark

公号运营中的一些认知

932
来自专栏Java学习网

程序员从优秀到卓越的几点建议

程序员从优秀到卓越的几点建议 和其他技术一样,编程也有层次阶段之分——业余爱好者、普通级别和专家级别。关于这个问题我问过很多很多次—— 如何从优秀到卓越?这是一...

2519
来自专栏大数据钻研

作为一个新手程序员该如何成长?

大纲 找一种你喜欢用到工作中的语言 修复问题 (公开)发布工作 写博客 保持健康心态的小技巧 引言 “哦,天那。相比其他开发者,我又笨又没准备。老板会知道我是多...

3437
来自专栏CSDN技术头条

别再做一个“不会说话”的程序员

沟通是职场中一个非常重要的技能,程序员常常被认为是最不善于沟通的一个人群. 他们中大部门人往往实力过硬,技术超群,但却常常因不善沟通而错失良机,不...

4249
来自专栏JAVA技术zhai

聊聊程序员的职场“围城”,给出作为过来人的一些建议

大部分人选择离职跳槽其实是因为对当下的工作不满意,或者自己处于一个职业的低谷期才考虑的,关于员工离职,马云说的两点原因可谓一针见血:1、钱,没给够,2、心,受委...

3646
来自专栏无原型不设计

拿起鼠标就画原型?交互设计师大咖告诉你该怎么做

在我介绍我的交互设计思考流程之前,我希望先说两个交互设计中设计师新手们常犯的错误,设计走进死胡同往往正是因为: 1.把设计当模仿。 我不是说参考优秀竞品不...

3004
来自专栏phodal

从初级到资深:程序员的职业生涯思考与可迁移技能培养

551
来自专栏java思维导图

思维导图结构化梳理Java进阶方向

写在前面 公众号的后台有读者给我留言说,对java每一阶段应该会什么技术感到迷茫。有个几年经验的爪娃们都经历过成长的阶段,但每个人成长阶段接触到的技术不尽相同。...

3759

扫码关注云+社区