程序员最烦两件事,第一件事是别人要他给自己的代码写文档,第二件就是差您经理的需求有变动”;产品经理想杀一名程序员,不需要用任何武器,只需要改三次需求;在产品眼里,什么都是简单的,在程序员眼里,产品说的所有变动都是复杂的,是找事的。因此,程序员与产品经理之间确实会存在矛盾,但说不共戴天却是夸张了说法了。

产品经理和程序员,如何避免矛盾?

产品汪和程序猿

一、产品经理和程序员最讨厌的三句话

产品经理和程序员,就像一对情人,若即若离,有时还会撕逼,和谐的时候一切都好,撕逼的时候两败俱伤。

你知道程序员最讨厌的三句话是什么吗?

1、这个需求很简单,改一下就好了

2、你先大概弄一个,我看看再说

3、我先下班了,加油啊

我想任何一个程序员听到这样的话都会气炸了,不撕逼才怪,你作为程序员会如何回答这三句话?

1、这个需求很简单?你行你来啊!

2、大概先弄一个?请问先生(女士),什么叫大概?

3、你大爷的

你知道产品经理最讨厌的三句话是什么吗?

1、这个需求做不了

2、这个需求工作量太大了,估计要搞3个月

3、这个变更没时间做,往后排吧

产品经理在前端,有用户、有老板、有销售,版本发布的压力很大,听到这样的话估计心情也好不了哪去?

1、这个需求做不了?又不是我提的,还不是那个2B用户提的

2、要做这么长时间?养你们有什么用,还不如我自己来

3、变更没时间搞?随便,等老板来拍你吧。

二、产品经理和程序员本质上的差异是什么

奶爸干过程序员,也干过项产品经理,深知这两类工作的差异,各有各的不易。

总体上来看,做产品更侧重于创造和方案能力,不需要精密的逻辑,所以试错成本相对比较低,大不了改改原型,改改方案,这个成本是可承受的。

程序员的工作是非常精密的逻辑,一个看似很小的变更有可能对代码产生很大的影响,所以试错成本非常高,弄不好可能会因为需求的变化导致系统的重构,这时候程序员的挫败感是可想而知的。

三、产品经理和程序员友好相处的清单

1、产品经理收集需求后,在需求分析阶段,需要把一些不合理的需求尽量和用户沟通去掉,避免不合理需求造成产品发布时间延迟和没有必要的成本浪费,当然这需要产品经理去说服用户,不能只做用户的传声筒。

2、需求分析时,产品经理应该根据经验,敏锐的发现一些在技术层面实现有困难的需求,及时让研发介入,评估技术可行性,避免后续出现需求定下来,研发说做不了的情况。

当然这需要我们的产品经理对软件技术架构有一定了解和预判能力,你不能所有的需求都要在需求分析阶段让研发介入,这个成本也是极高的,所以要把握好这个度也是一项能力。

3、原型还是需求沟通的最好方式,这样是避免产品和研发在需求理解上有差异的最好手段,只靠写一些文字的需求说明书很难达到好的效果。

但这里面要注意一点,产品经理绘制出来的原型一般是非高保真原型,是为了更好的沟通需要,所以不能完全按照原型做,需要基于我们自己的前台架构进行定制。

4、需求评审的时候,研发可能会有一些不一样的意见,他们做了很多年的开发,会有很多好的经验,好的经验要虚心接受,不能觉得自己是产品就是老大,就是要按我说的做,这样很容易造成矛盾,求同存异,目标一致,这个是最好的结果。

5、研发说这个需求做不了的时候,有两种情况,一个是觉得这个需求实现起来比较麻烦,故意骗你;另外一种情况就是他的知识盲区,他可能确实不知道这个事能做。

产品经理需要有能力和研发进行谈判,比如采用类比法(类似的需求在其它项目上咱们就做过),比如去找架构师探讨技术可行性。

6、研发有时候评估的工作量会比较大,整个上线计划拉的比较长,产品经理可以要求研发出详细的资源配置清单,这样能清楚的看到一个需求被分解成了多少个研发任务,每个任务的起止时间,由谁负责完成。这样产品经理大概能看出任务的前后置关系是否合理?工作量是否合理等。

产品经理绝不能说,这么简单怎么要搞这么长时间,类似的话一出,绝对会激怒对方,还是要有理有据进行谈判。

如果实在无法压缩工作量,如果增加人力能解决问题的话,可以考虑找领导申请资源。如果还是不行就要砍需求或者改方案了。

7、在版本计划定好的情况,尽量不加需求,这样很容易打乱开发的节奏,如果一定要加进来,一定要和研发说清楚,这个是用户领导或者老板的强制要求,转移矛盾。如果可以的话,增加了需求尽量推迟上线计划。

8、开发过程中如果需求有改动,需要及时更新需求文档,同时发给我们的研发同学,否则只是靠嘴说一下,很可能研发的同事就不做了,所以一定要落到纸面上。

9、上线的时候要坚持和研发同事一起加班,这样大家才是一个团队,赢了一起狂,输了一起扛。

10、最后一点,就是要多交流,没有什么问题是一顿火锅解决不了的,大家关系好了,很多事情沟通起来自然容易,而且也会更信任对方,这样就万事OK了。

讲真,产品经理就是这样频繁改需求被程序小哥打死的...

拉勾网Lagou

“终于知道产品经理为啥总被程序员嫌弃了,看完下面生活中的一个常见场景,你会对产品经理这个高危行业有更加深入的了解...当然,如果你想打死产品经理,请算我一个

你去饭店,坐下来。

“服务员,给我来份宫保鸡丁!”

“好嘞!”

这叫原始需求

大厨做到一半。

“服务员,菜里不要放肉。”

“不放肉怎么做啊?”

“不放肉就行了,其它按正常程序做,不就行了,难吗?”

“好的您稍等”

这叫中途需求变更

厨房:

大厨:“你大爷,我肉都回锅了”

服务员:“顾客非要要求的嘛,你把肉挑出来不就行了吗”

大厨:“行你大爷”

然而还是一点点挑出来了

改动太大,部分重构

餐厅:

“服务员,菜里能给我加点腐竹吗?”

“行,这个应该简单。”

低估改动成本

厨房:

大厨:“你TMD,不知道腐竹得提前泡水?炒到一半才说?跟他说,想吃腐竹就多等半天”

服务员:“啊你怎么不早说?”

大厨:“早说你MLGB我怎么知道他要往宫保鸡丁里放腐竹”

然而还是去泡腐竹了

新需求引入了新研发成本

餐厅:

“服务员,还是把肉加回去吧”

“您不是刚说不要肉吗”

“现在又想要了”

“...好的您稍等”

某一功能点摇摆不定

厨房:

大厨:“日你啊,菜都炒过火了你让我放肉?还好肉我没扔”

服务员:“客户提的要求你日我干嘛?”大厨:“你就不能拒绝他啊?啊?”

服务员:“人家是客户嘛。”

甲方是大爷

餐厅:

“服务员!服务员!”

“来了来了,你好?”

“怎么这么半天啊?”

“稍等我给您催催啊”

改动开始导致工期延误

厨房:

大厨:“催你M催,腐竹没泡好,我还得重新放油,他要想吃老的也行,没法保质保量”

开发者请求重新排期

餐厅:

服务员:“抱歉,加腐竹的话得多等半天,您别着急哈”

“我靠要等那么久?我现在就要吃,你们能快点吗?”

“行...您稍等”

甲方催活

厨房:

大厨:“我日他仙人板板,中途改需求又想按期交付,逗我玩呢?”

服务员:“那我问问,要不让他们换个菜?”

大厨:“再换我就死了”

开发者开始和中间人pk

餐厅:

“服务员,这样吧,腐竹不要了,换成蒜毫能快点吗?对了,顺便加点番茄酱”

因工期过长再次改动需求

厨房:

大厨:“我日了狗啊,你TM不知道蒜毫也得焯水啊?还有你让我怎么往热菜里放番茄酱啊??”

服务员:“焯水也比等腐竹强吧,番茄酱往里一倒不就行了吗?很难吗?”

大厨:“草。腐竹我还得接着泡,万一这孙子一会又想要了呢。”

频繁改动开始导致大量冗余

餐厅:

“服务员,菜里加茄丁了没有?我去其它饭店吃可都是有茄丁的”

“好好好您稍等您稍等”

奇葩需求

厨房:

大厨:“我去他二大爷他吃的是斯里兰卡三流技校炒的宫保鸡丁吗?宫保鸡丁里放茄丁??”

服务员:“茄丁抄好了扔里边不就行了吗?”

大厨:“那TM还能叫菜吗?哪个系的?”

服务员:“客户要,你就给炒了吧。”

大厨:“MB你顺道问问他腐竹还要不要,我这盆腐竹还占着地方呢不要我就扔了”

奇葩你也得做

餐厅:

“服务员,还要多久能好啊”

“很快,很快...”

“再给我来杯西瓜汁。”

“...好”

“我再等10分钟,还不好我就走了,反正还没给钱。”

“很快,很快...”

黑暗前的最后黎明

10分钟后

“咦,我上次吃的不是这个味啊?”

从厨房杀出来的大厨:“我TM就日了你的狗...”

最终决战

——————

你=客户

服务员=客户经理+产品经理

大厨=码农

请自行转换...

——————

注:

1)以上场景已极度夸张,实际生产生活中码农和PM是和睦友好的相亲相爱的一家人

2)对于做2C产品的公司,你=公司大boss

-END-

为何大多数程序猿会转行做产品经理的?背后的原因有哪些?

为何大多数程序猿会转行做产品经理的?背后的原因有哪些?下面就我们来针对这个问题进行一番探讨,希望这些内容能够帮到有需要的朋友们。

“我是一名程序员,想转做产品经理,改行求业难度系数大吗?”小G在某互联网技术社交网络平台上提出问题。在程序员这一人群中,有小G这类念头的实际上并不在少数,大部分搞程序流程的人,除非是对程序编写真的是发自内心衷心的喜爱,要不然一定会在职业发展的某一个环节感觉产品经理是一个特别出色且相对性专业对口的发展方向。

还记得先前和一位程序员好朋友闲聊,他说道程序员想转产品经理汇总出来无非就四个原因:第一,做技术性又累又枯燥乏味,并不是真的喜爱写程序的人难以在这个行业有很大的造就;第二,觉得做技术性较为低贱,要被产品经理各种各样摸透;第三,爱慕虚荣作怪,产品经理好赖是个“主管”,程序员顶多便是个农民工;第四,自身掌握怎么写代码,了解要求完成的途径,往产品经理转有着先天性的优点。

写作到这儿,我迫不得已给诸位程序员朋友泼个水,千万别由于“主管”这两字添加这一领域,也千万别小看了产品经理这一职位,不然进去以后你也许会被暴打。

实际上,产品经理并不是只需懂技术性就到达了出道的规范,其职业发展目标是为商品的一整个生命期承担,从需求分析到设计产品到要求审查,再到项目风险管理、结果总结,这种阶段都必须产品经理去核心把控。除此之外,产品经理还需要按照设备的生命期,融洽产品研发、营销推广、经营等,明确和组织实施相对应的市场营销策略,及其其它一系列相应的产品经营主题活动。

不难看出,产品经理这一职位必须相应的职业素质,技术专业的知识与技能,不同寻常的岗位职责,且必须按照不一样工作中情景饰演者不一样的人物角色,可以称之为是综合性优秀人才,非通过多年学习培训实战演练不可以担任。

“产品经理新手入门很容易,可是要想搞好则是十分难。”先前大家荣幸邀约到贝壳找房产品总监刘炯来干了一场有关产品经理的直播分享,在共享最终他也针对从程序员转产品经理发布了一些见解。

“与别的岗位对比,从产品研发转商品的确有先天性优点,因为你了解这一需要的建立途径。但这一优势通常也成为了一个特别大的挑战,在你来想产品方案时,会特别关注这一要求怎样完成,这一侧重点方位就产生了误差。假如你准备从产品研发转商品,一定要将你的优点忘记,你需要潜心去想要做这件事情是不是有效,并非关心它是不是能完成换句话说它的完成逻辑是什么,你不能被‘实现的概率’拘束住‘对商业本质的探索’。”

那到底哪一类目的产品研发转产品经理会更易于获得成功呢?刘炯直播间中也得出了一个回应,“现在我关心到好的的产品研发转商品十分顺利的,大多数是中后台管理商品。由于这一商品方位对思维逻辑规定很高,或是要化解的问题大多数是相对性可预测性的问题,相对而言合适产品研发开展产品经理的改行。”