1. 聚能聊>
  2. 话题详情

看程序“猿”花式虐产品“狗”,你想怎么玩?

资深产品狗如何和撸码猿神处得融洽自然?彼此间是保姆式关系更亲密,还是合作伙伴关系更牢靠? 我们一起跟着RDC男程序媛和女产品狗一起来看个究竟。

作为产品经理(或产品狗,PD = Product Dog),不同的公司和不同的团队有不同的风格(你可能已经有深切体会了),基本上可分为两大模式:

保姆式产品经理

保姆式,主要是服务于研发工程师,这类产品经理基本上是除了写代码不参与外,其他的所有交涉、规划和执行的工作都有产品经理来扛。

RDC女程序员与男产品经理之间相爱相杀剧照

如果做得好,会得到这样的评价:

  • “给研发工程师的感觉是:“除了代码,其他你来搞定”。
  • “给业务方的感觉是 :“只要我有想做的,你总能搞定”。
  • “给老板的感觉是:“这个产品,你是专家”。

如果做得不好,就会这样:

![RDC女程序员与男产品经理之间相爱相杀剧照]
(https://yqfile.alicdn.com/ecb20c7210f9ea0556c9f293d50d4943edaeb86c.png)

  • 给研发工程师的感觉是:“这个事你怎么不上心呀,产品规划什么时候出?”
  • “给业务方的感觉是:“我的需求排期了么?什么时候评审呀?能快点么?”
  • “给老板的感觉是:“又过去半年了,你怎么没有大业绩呀?”

合作伙伴式产品经理

合作伙伴式,对研发工程师来说,基本上按项目流程进行明确的分工,产品经理只做项目中产品经理的职责,其他的是由均由产品的各个对应部门的专职人员来完成。

![RDC女程序员与男产品经理之间相爱相杀剧照]
(https://yqfile.alicdn.com/2452dd46e497000ff3cea230d191aadda9f07dc5.png)

如果做得好,会得到这样的评价:

  • 给研发工程师的感觉是:“做事仔细、清晰,一丝不苟。”
  • 给业务方的感觉是:“流程清晰、节奏感非常强、不会发生冲突。”
  • 给老板的感觉是:“做事有条理,分工有分寸。”

如果做得不好,就会这样:

  • 给研发工程师的感觉是:“太官僚了,什么事情都要走流程,改个小按钮也要重新评审。”
  • 给业务方的感觉是:“太官僚了,这么点小需求都做不了主;排个期这么难,问个问题竟不搭理我。”
  • 给老板的感觉是:“都这么久了,还没有全面掌握产品的方方面面。”

另外可点击这里进一步了解RDC如何帮助产品经理推动需求落地 >

那么问题来了, 猿和狗怎样才能不再相爱相杀,说说你的看法吧,有小礼品随机送出

报出你的身份产品狗还是程序猿?你与对方相处还融洽吗?

你或你所期望的产品经理是怎样的?

参与话题

奖品区域 活动规则 已 结束

48个回答

4

巴洛克上校 复制链接去分享

136

   我一个朋友做产品的,项目做不好挨批,业务有时候会提出各种奇葩需求,紧接着还要和开发开展激烈讨论,开发不同意转过头又和业务去谈,需求变更还低哄着开发工程师改代码;做产品要受得了折磨、经得住挫败、耐得住寂寞、忍得住伤痛、熬得住青春、盯得住对手、转得过脑筋、放得下自尊、厚得了脸皮、搞得过开发、跑得了市场、懂得了运营、做得了设计、写得了文档、讲得了PPT、管得了项目、说得赢老板、看得透本质,最重要的,还要有十年磨一剑的钢铁般的意志。我还是老实的做我的码农吧!!

e0d7d2a20de235d6ae2ffcb927c0874d_b

光脉 回复

哈哈,这个太形象了。

评论
0

浮生递归 复制链接去分享

合作式的PD更适合团队的发展,毕竟一个人的精力是有限的。合理的分工才能确保项目的稳步推进。以牺牲一个人的超负荷运转来推进项目的进度是不能长久的,更不健康和稳固,容易出现意外。但是PD必须对整个项目的流程和进度非常清楚,这样才能及时发现问题、消除隐患。

RDC初看还找不出能在本质上帮上大忙的地方。对于项目团队,更重要的是项目流程管理。当然,在流程管理的基础上再加上应用RDC那应当是极高效的。钉钉里有个TOWER工作流管理应用,但是实际使用中还是问题多多。

光脉 回复

嗯,合作式是不少大型企业采用的一种模式。RDC对PD的帮助主要体现在需求记录、拆分、指派、跟踪等上面,更重要的是,RDC通过对敏捷迭代开发模式的支持,使PD和研发成为一个真正的团队,从而促进了整体效率的提升。点这里可以进一步了解:https://help.aliyun.com/document_detail/51868.html

明明网 回复

厉害了

浮生递归 回复
回复@光脉:

RDC一出来,我就关注了。因为一直期待一个通用的、高效的项目管理软件或方案。但是就像OA一样,每个单位的需求都不一样,不可能有一款即通用又能深度吻合的软件。RDC更适合团队里技术负责、技术总监、技术主管之类的岗位用来对开发工作进行规划使用,而不是PD这种,可能要对开发之前和开发之后的工作都需要进行调度、规划的岗位。所以RDC要是能有其他一款扩展的产品来补足一下,那就完美了。

评论
0

鼓励师锦铭 复制链接去分享

一直都是保姆式产品经理,作为一名运营妹子,一旦有了运营需求,然后就开始兼职产品狗。一个从需求提出,需求实现视觉demo,再到需求后端实现,前端开发,全程跟进下来。一个项目下来,掉几斤肉。以前还感觉不到问题所在,以为是自己不太懂开发,所以就得亲力亲为,掌控各个环节。但是当你发现,申请一个运营域名,你都得去和各个其他部门的人聊半天,我完全不懂的业务的时候,你会觉得工作已经到了天昏地暗的境地。所以后来学会用一些项目管理工具去定向指派相关人全程跟进,譬如你做后端开发,域名的事,是你负责这事的范畴之内。

采用合作式后,发现也不能全程撒手,也要适当去做助力器,当开发童鞋不善于沟通,有些需要靠外部支持和沟通才能解决的时候,他们会寻求你的帮助,这种互助互利的关系就能形成良性循环。而且他们提前完成了,及时push这个状态给他的leader,给他邀功;当他有延期的时候,及时在任务状态中同步透明。

以上的前提是你要有一个透明项目、产品工作状态的工具,否则,你还是一个保姆,开各种会议、站会、周报、日报去拿进度报告。

未来希望是一个既能和开发、设计,打成一片,又能独当一面,还能当程序员鼓励师,带着他们一起飞的酱油产品运营狗。

浮生递归 回复

域名拟定应该是产品和业务、运营共同确定,域名申请、注册及备案由办公室处理,域名配置才可以由后端开发负责

评论
0

advote 复制链接去分享

我不是产品经理

鼓励师锦铭 回复

人人都是产品经理 😝

浮生递归 回复

原来你也有看那个网站

评论
1

jackyliu 复制链接去分享

报出你的身份产品狗还是程序猿?
我是程序猿,敲代码多年的老猿

你与对方相处还融洽吗?
还是很融洽的。其实要想和产品相处融洽,共同推动公司业务发展,针对互联网项目的研发,我有一些个人的观点,姑妄言之。
1.先谋后动:在项目或者版本开始之前,产品要做好产品规划,整理清楚产品文档,技术要调研好技术可行性,可行则详细讨论需求,落实到伪代码级别,然后给出一个合理的工期。这个工期估计,是给老板和整个团队的一个心里预期,如果估计的不准,多数是延期,一而再,再而三的延期,会影响老板对大家的信任感,也会降低团队的士气;
2.各司其职:产品不该干涉研发的技术实现,研发也不该以无法实现、影响性能等等理由推脱或者驳回产品的需求,如果需求本身所需工期过长,则应提出,供产品决定。研发驳回产品的需求,这个应该是最常见的矛盾点。避免矛盾的要点就是各司其职,研发不能个人觉得“产品是傻逼”,就拒绝实现。
3.小步快跑:是指版本要小,迭代要快,要做每日集成测试,早日让产品看到效果,尽早提出修改意见。避免到版本结束的时候,产品问题一大堆,因为deadline已经接近,研发一怒之下,拒绝任何非文档约定的修改。这下就成死局了,要么延期,要么产品妥协,接受有缺陷的产品。

你所期望的产品经理是怎样的?
1.对软件项目复杂性有深刻认知的,给出合理工期的;
2.需求清晰,后期不会频繁变更的;
3.张小龙那样的,或者王者荣耀制作人那样,可以带领程序猿们走上人生巅峰的~~

另外,很惊讶的发现阿里云居然做了RDC,我们现在使用的是worktile,等我研究后,给团队推荐啊

送个T恤好么,谢谢~以上文字原创,保留版权~

1

璀璨阑珊 复制链接去分享

相爱相杀才乐在其中呀。产品经理是画图纸的设计师,程序猿是按图搭建的建筑师。他俩分工不同,但又紧密联系,都是为了同一个目标——构建优秀的产品!
我目前只是个程序猿,不过希望不久后成为产品经理。程序员讨厌被不停地催进度,也不喜欢不太懂技术的人指挥他写代码。产品经理协调整个团队、把控整个项目,做个保姆也确实很费心。其实,狗和猿找到好的沟通方式,相互理解信任,也能相处融洽。
只要搭档的好,大家完全都可以省心。专业的人,做专业的事!产品经理并不需要面面俱到,抓住重点,协调好团队即可。双方充分信任,留给对方充分的空间才能出好的工作效果。
双方看待事情的出发点和角度也是不一样的。原来作为程序猿,总想的是技术实现,苦练技术;现在,我在试着用产品经理的视角去看,以人为中心,思考人的特质。技术都是为人服务的嘛。相互理解最重要!还是做个合作伙伴好,不然累死产品狗,而程序猿也会觉得你是在管的太宽了。

1

szm. 复制链接去分享

作为一只程序猿,和产品狗的相处并不是很融洽,主要原因是专业有区别,导致在相同的问题上,观念不一致,产品经理更注重最后的结果,而程序猿更关注过程,这也是矛盾点。
我认为,要想处理好关系,还是需要双方互相学习对方看问题的方式,有时间了解一下对方的专业知识。

1

爵霸 复制链接去分享

1973573_d93a73cc24bb5def
我们先来看个段子:

去饭店,坐下来。

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

“好嘞!”

——————这叫原始需求

大厨做到一半。

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

“不放肉怎么做啊?”

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

“好的您稍等”

——————中途需求变更

厨房:

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

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

大厨:“行你大爷”

然而还是一点点挑出来了

——————改动太大,部分重构

餐厅:

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

“行,这个应该简单。”

——————低估改动成本

厨房:

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

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

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

然而还是去泡腐竹了

——————新需求引入了新研发成本

餐厅:

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

“您不是刚说不要肉吗”

“现在又想要了”

“...好的您稍等”

——————某一功能点摇摆不定

厨房:

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

服务员:“客户提的要求你日我干嘛?”

大厨:“你就不能拒绝他啊?啊?”

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

——————甲方是大爷

餐厅:

“服务员!服务员!”

“来了来了,你好?”

“怎么这么半天啊?”

“稍等我给您催催啊”

——————改动开始导致工期延误

厨房:

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

——————开发者请求重新排期

餐厅:

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

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

“行...您稍等”

——————甲方催活

厨房:

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

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

大厨:“再换我就死了”

——————开发者开始和中间人PK

餐厅:

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

——————因工期过长再次改动需求

厨房:

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

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

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

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

餐厅:

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

“好好好您稍等您稍等”

——————奇葩需求

厨房:

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

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

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

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

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

——————奇葩你也得做

餐厅:

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

“很快,很快...”

“再给我来杯西瓜汁。”

“...好”

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

“很快,很快...”

——————黑暗前的最后黎明

10分钟后

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

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

——————最终决战——————

你=客户

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

大厨=码农

请自行转换...

注:以上场景已极度夸张,实际生产生活中码农和PM是和睦友好的相亲相爱的一家人
编程语言,它终归是一门语言,只是它的使用者是电脑软件和硬件。产品经理和程序员对于需求理解的思维体系、语言体系、语言上下文环境不同。

比如这个需求:一包中华45元,产目经理给你50元,让程序员去买包烟把找的5块钱拿回来。

产品经理觉得非常简单,一句话的事。

而对于程序员而言:

50元是不是假钱?

如果不是假钱,去哪买烟?

如果去西安买烟,西安卖烟的地方关门了?是回去给产品经理说卖烟的地方关门了还是一直找,直到找到一个没有关门的卖烟的地方?

如果这里的一包中华是40元,或者一包中华是50元,买不买?不管多钱都买?还是征求产品经理同意后再买?

怎么判断买的烟不是假烟?还是不管真假买了一包中华就算?

买了之后是邮寄给项目经理?还是自己给带回来?还是让顺道的同事给捎回去?

如果买回来买的是50元一包的中华,产品经理嫌贵了怎么办?

如果买回来的是40元一包的中华,是给产品经理退5元钱还是给他退10元?

如果产品经理一定要45元的中华怎么办?

如果产品经理突然不想要这烟了,让你退回去怎么办?

如果卖烟的人不退怎么办?

如果产品经理让你退了重新在别的地方买一包怎么办?

如果卖烟的老王退了,但是再没有别的卖烟的地方了怎么办!

如果又找到一个卖烟的地方,并且一包中华也是45元。带给项目经理。项目经理听说你是从西安买的,他要抽北京买的烟怎么办?

......

你会发现问题没完没了。

这会你可能会说程序员太死脑筋。错!产品经理所说的,中华45元,给你50元,买完找5元。这句话是建立在一系统上下文语境,人类生活习惯,生活常识当中的。产品经理的潜台词是说找最近的有卖烟的买一包45的不是假烟的中华烟,找的五块钱给我。

而对于程序语言,还是开头那句话:编程语言是一门语言,它的使用者是软件和硬件。对于计算机而言,它没有情感,不理解人类的这一系统语言环境,生活习惯,生活常识。它只严格按照它的语言规则,编译原理一步一步,老老实实,丝毫不露地往下执行。如果没有分歧,一切妥当。如果有分歧,完蛋了。人类千百万年来进化形成的临机应变,相机行事等等这些本能,计算机及编程语言一丁点不具备。它就认准程序员写的程序,就乖乖地听你程序,指哪打哪。所谓的人工智能也只是程序员把每一种可能,人类面对问题所会面对的问题事先写好程序语言录入进计算机。如果意外在之前所料之中,程序完美执行,如果意外所料不及,那就是BUG,就是错误。而这些BUG和错误都要程序员去一点一点补充产品经理所谓“需求”之外的所有潜台词。

这是在需求确定的情况下,如果程序员正在买烟的路上,产品经理打电话说,剩下5块钱回来再买瓶水。那之前所有的逻辑程序员又得再执行一遍。如果产品经理过一会又打电话说再买个面包。。。那就折腾死程序员了。

从需求方面说完,再从程序员编码实现方面来说。还是刚才的需求:产品经理给程序员50元,让买一包45元的中华烟,找回来5元钱。

程序员一听,程序里面写死了,从线路1去西大街,买完烟再沿线路2返回。但是中途产品经理说你再买点零食回来。程序员傻眼了!!!得,只能程序重新设计,从线路2出发。

试想,从初中开始学英语,初中三年,高中三年,大学四年,十年下来,有几个人能面对外国人说一口标准的英语?编程语言也一样,有些程序员大学没好好研究编程,或者根本不是计算机系,上过几天培训班,知道编程是怎么一回事,会写if/else/for,就业所迫,就开始商业编程了。写程序必然是指哪打哪,别的情况我不管。这样的程序,脆弱的不敢碰,一有改动就是要性命啊。

最后一方面是,国内软件开发,开发流程不完善。有活就赶紧埋头干,干了不对再说。最终需求理解不到位,项目周期比火车还长,项目成本居高不下。

有时候拖着下巴想想,编程真是一门艺术活。

1

巴洛克上校 复制链接去分享

自从使用了RDC,工作效率牛掰了!

哎呀!我的天啊!!!

QQ_20170518125350

0

1501004153348641 复制链接去分享

爽就好了

0

magei 复制链接去分享

做一款贴心的产品🐶

0

1705996650862106 复制链接去分享

产品狗来站队 从保姆式到合作式,争吵、批斗、群攻都有过,就差群殴!需求提过去,技术大猿第一句话往往是这个不行!实现不了!!作为产品耐住性子死磕:哪里不行,怎么样能行,为何其他网站能实现,看这里这里……程序猿:行,能实现!耶!

0

1708495161415987 复制链接去分享

非常喜欢纪念T桖,想要一件

0

飘零ii 复制链接去分享

产品要学会沟通啊,毕竟不是所有的程序猿都会交流~程序员+1

0

一场 复制链接去分享

刚入坑,

0

1916095538361272 复制链接去分享

這只是一種尋找安慰的做法!

0

ctsky 复制链接去分享

真会玩

0

arvinson11 复制链接去分享

mmm

0

daobin 复制链接去分享

斯国一

0

1864190858921061 复制链接去分享

我表示 没话说

3