如何不被程序员嫌弃——写给那些血气方刚的产品经理

进入微软、亚马逊,谷歌等美国IT企业工作人才项目,起薪40万,百度搜索(MUMCS)

最近有位刚做 PM(产品经理)的小伙跑来跟我控诉,说公司技术部的 RD 们(程序员)个个不给力。需求过了千百遍还是理解错,或者就是简单回一句“做不了”,表情如死灰。

这位 PM 血气方刚,张牙舞抓,脑子里总有一千万个新产品需求的想法扑腾着。他咄咄不停的抱怨 RD 们不配合,能力差,懒惰,没思考能力,没品位,顺带连抠脚味儿太大这种事也强烈谴责了。“擦,老子明天就去学编程!” 哎,我发现 PM 们都特喜欢说这句无比励志的话呢!

面对他,我的心突然惆怅起来。几年前的自己也差不多是这个模样,懵懂如白纸,但谁又知道这样的 PM,在很多 RD 的眼里就是个傻逼吧。身为一位女性 PM,我至今为止并肩合作过的 RD 团队超过 8 组共 200 多人(动荡曲折的职业生涯啊),受过的委屈流过的泪就不在这里赘述了,打算留着以后写小说。今天我只想浅谈一些自己总结的 PM 与 RD 相处之道,所谓人艰不拆,希望大家看完后能更理解彼此“都不容易”的立场。

PM 眼里的 RD 分成两种:能沟通的,和不能沟通的。后者占 90%。(呵呵)

如果你跟我一样,是个没有技术背景的 PM,估计你会觉得世界上 “不能沟通的 RD” 占九成以上。难道不是吗!

每当你斗志昂扬讲完一个伟大的产品计划,期待看到 RD 激动的眼神,却发现他们真的一点儿不兴奋。给面子的 RD 会干巴巴的问:“什么时候要?什么时候开始?设计稿确定了没?产品文档写完整了没。” 不给面子的 RD 则会当场质疑你,“这个新功能你到底想清楚了吗?!老板又风花雪月拍脑子了吧?!这么做有数据依据吗?!做过市场调研吗?!老用户会因此流失吗?!能保证上线后不再改了吗!?@$%^^%%[email protected]% #$%^^% ” 真的是没法儿做朋友啊!

曾经有一个自以为很牛掰但其实能力已经跟不上时代的 RD 总监,在 kickoff 会议上把我所有的需求都推翻了,让我差点在十几个老男人面前哭鼻子。话说人在经历苦难后,要么变乖,要么变坏。这种迫切想要搞定 RD,让他们听命于我的心情,实在太强烈,于是我学会了通过非正规途径收买 RD 的心--比如请他们吃 KFC 啦,陪他们聊黄色笑话啦,穿低胸装秀黑丝大腿啦。在这些努力之下,我和 RD 的关系改善很多,他们开始敞开心扉,解释他们对于新需求的负面情绪到底从何而来:有时是因为实在忙不过来,有时是因为实在无法理解这个功能有什么意义(至少他们自己肯定不会用),有时是因为
PM 不但不调解现有项目的优先级,反而还每天做梦,想些有的没的,让他们极为恼火。而负面情绪最大的根源,则是他们对这个项目失去了信心,觉得反复改版却一直没有大的突破,老板和 PM 都应该去吃 shi。

正当我沾沾自喜,认为自己靠美胸美腿赢得了这场战役时,一个 Ruby 程序员幽幽的跟我说 “我好喜欢你的门牙。” (鸦。。。你们果然是无法沟通的生物。。。)

RD 眼里的 PM 也分成两种:有脑子的,和没脑子的。后者占 90%。(呵呵呵)

没脑子的 PM,RD 们是打心底深深嫌弃你的。嫌弃你的理由可能有以下三点,欢迎对号入座,我们一起舔伤口:

嫌弃理由1:你没有自己的想法。听清楚哦,我说的是 RD 们“认为”你没有自己的想法。这个话题实在很辛酸,哪个 PM 会没有自己的想法呢,就是想法多的溢出了脑门儿才跑来当 PM 的啊魂淡!!但是 PM 的生存环境无比艰辛,很多决定都身不由己(尤其当你有一个心思活络的老板时)。于是,有些 PM 选择推卸责任,两手一摊 “老板说必须做” ,急着撇清关系强调只有老板是傻逼哦我不是哦。此言一出,你在 RD 心里的形象全毁。

PM 必须是产品的灵魂,无论老板决定闹哪样,你都要把这个决定翻译成大家能接受的理由,建立你自己的口碑和信任。在跟 RD 沟通的时候,不要说“我和老板争论了很久他就是不听我的”,这样更凸显你的无能;也不要撒谎说“其实我觉得老板的想法挺好的”然后硬掰些白痴的理由,这样显得你特别虚伪。比较好的应对方式是开诚布公,说你自己真实的想法,如果你觉得老板真是玩过火,也要解释下老板为何会有这样的执念(是被投资人逼的,还是被老婆逼的,还是看到竞争对手做的什么事情眼红了想抄袭),然后安慰体恤下 RD 们的辛苦,并表现出和他们同甘共苦的决心。

嫌弃理由2:你风花雪月没有逻辑。都说能做出牛逼产品的 PM 要感性和理性兼备,因为牛逼的产品能直戳人性,满足用户多层次的生理和情感需求,这就要求 PM 对生活细节敏感,情感丰富。可是情感丰富的 PM 通常思维比较跳跃(艺术家嘛都这样),情绪波动幅度巨大,郁闷时会在阳台发呆抽一下午的烟,兴奋时连坐在马桶上都拿着手机写文档,这样的节奏 RD 们真心吃不消。他们觉得你丫的赶紧吃点儿脑残片吧!论起 PM 的自我修养,你必须有收放自如的情感,还得有理性的逻辑思维去支撑起每一次的灵感乍现。

你可以问自己三个问题:一、这个功能是否服务于产品的主线业务,比如一个听歌的软件是否要有日间/夜间模式切换?如果只是锦上添花,使用场景不足整体的 10%,那劝你还是等自己学会写代码以后在家做着玩吧;二、这个功能的技术实现成本有多大,如果用工时或天数来预计工作量不够直观,请去 HR 部门问一下 RD 全员每天的工资总额,再乘以所需要的开发时间,哈,这个金额应该足以让你好好思考“需求性价比”这件事了!(这招在创业公司尤为实用)三、这个功能的效果是否能被评估,这样至少你能检验自己的判断是否正确,无论如何都能积累宝贵的经验。

嫌弃理由3:不信任 RD 的能力。呵呵呵呵呵呵,说起这个真是百感交集。每一个有血有泪的日子里都在重复上演这样的剧集:PM 问 RD 这个功能要做多久,RD 说至少 3 周,PM 于是去问自己做技术的好基友 “真的需要 3 周吗?”,基友拍桌子说 “这有什么难的,换了我 3 天就搞定!” 然后两人忿忿不平的拍案皱眉,开始讨论公司里的 RD 们到底是能力差还是在偷懒。我曾经也这样,因为不懂技术害怕被骗,于是勾搭各种民间技术大牛让他们给我做狗头军师。军师们为了维护自己伟岸的形象,通常会拍胸脯各种夸大各种装逼。更糟糕的是,军师们也变相破坏了我和
RD 之间原本就已经很稀薄的信任。(哦多么痛的领悟~~~)

最后,RD 眼里的 RD,只有一种:比自己牛的人。

剩下那些能力不如自己的,他们的存在早已消失散尽在雾霾里了。

............................................ 我是口沫横飞的分割线...........................................

让 RD 觉得你很优秀的方法...

1. 眼观四路耳听八方,知识渊博,掌握行业内的各种动态,分析市场趋势,没事就盯着友盟的数据看,各种国外新推出的牛逼产品统统用起来。RD 们会觉得你什么都知道,那你的判断八成是靠谱的。

2. 混对圈子,积攒几个牛逼人脉,难得和大人物有饭局的时候一定拍照发朋友圈,时不时去知乎回答些问题,去各种活动刷脸,撮合各种合作,尽一切可能把公司推到聚光灯下,这样也更容易招聘到优秀的程序员,产生良性循环。RD 们大多不喜欢抛头露面,所以他们会觉得你的付出无可取代(不然他们老觉得 PM 每天看看文章聊聊天,简直是悠闲的废物)。

3. 无论是口述的需求还是撰写的文档,文字和原型图的呈现都要有逻辑,有条理,最好用写代码的思路来写产品文档,功能细节上的逻辑处理无一遗漏,实乃 RD 们的心头好。

4. 在老板责问为什么还没上线的时候,冲上前去说,“都是我的错,前几天又改了个需求”。

5. 在 RD 们被各种部门的需求同时袭击的时候,为他们安排最合理的优先级,并承诺担起一切后果(包括被某部门主管批斗责骂等)。

6. 招到漂亮的实习生妹子给 RD 们养眼。

7. 给他们加薪,给他们加薪,给他们加薪。

文章的最后,我想对所有还在拼搏的产品经理们说,就算你的行业环境不断限制你的创新和畅想,就算你身边的程序员总是打压你的积极性,攻击你的决策和判断,就算你觉得全世界都没有人肯定你的努力,没有人理解你的无奈,你都不可以放弃。勿忘理想,勿忘初心。你们是美好未来的希望。

如何不被程序员嫌弃——写给那些血气方刚的产品经理,布布扣,bubuko.com

时间: 2024-10-07 10:15:45

如何不被程序员嫌弃——写给那些血气方刚的产品经理的相关文章

如何不被程序员(RD)们嫌弃--写给那些血气方刚的产品经理(PM)

编者按:本文是来自X小姐的第四篇投稿,第一篇文章<一个至今没做出靠谱好产品的产品经理是这样活着的>,第二篇文章<一个初次创业的互联网P民是 这样被投资人拒绝的--写于没有拿到任何投资意向书的某清冷夜晚>,第三篇文章为<针对女性开发的互联网产品还敢再男性思维一点么--来自白富美女票们的 哭与泪>. 最近有位刚做PM(产品经理)的小伙跑来跟我控诉,说公司技术部的RD们(程序员)个个不给力.需求过了千百遍还是理解错,或者就是简单回一句"做不了",表情如死灰

程序员如何写出一份好的文档?(转)

程序员如何写出一份好的文档? 分类: 杂谈2015-06-10 16:37 1249人阅读 评论(6) 收藏 举报 在实际的软件开发工作中,除了编写代码之外,程序员还会花大量的时间来编写相关的研发文档,这些文档包括:详细设计文档.单元/集成测试文档.软件版本开发报告.软件安装说明.软件升级指导书等. 在<程序员既要写好代码,又要写好文档>(http://www.zhouzhaoxiong.com/142.html)一文中,我提到过:“代码”和“文档”就像是一个人的左膀右臂,一定要让两者均衡发展

[转]为什么程序员总是写糟糕的代码?这3个原因

原文请看:为什么程序员总是写糟糕的代码?这3个原因 我最近一直在想我们作为一个行业为什么总是产出糟糕代码的原因. 1.明显原因…… 我一下子想到的最明显的原因是,有好的程序员,也有不那么好的程序员,有的人技术水平高,有的人水平却低,有人对这门技艺感兴趣,但也有的人却不愿意在工作之外学习其他. 好了,我就不深入探讨了. 那么是不是在这表层之下还有更多的问题呢?有没有导致糟糕代码的根本性原因?我觉得有必要深入探究一下. 2.低预期…… 对于这一点,众所承认的是,我们在大学中,通过自学或书籍学到的东西

程序员老鸟写sql语句的经验之谈

做管理系统的,无论是bs结构的还是cs结构的,都不可避免的涉及到数据库表结构的设计,sql语句的编写等.因此在开发系统的时候,表结构设计是否合理,sql语句是否标准,写出的sql性能是否优化往往会成为公司衡量程序员技术水平的标准. 我们程序员不是dba,不需要时刻关注sql运行时间,想方设法优化表结构,存储空间,优化表读取速度等等,但是在开发系统时,时刻保持优良的写sql语句的作风是很有必要的,这关乎到个人在公司的声誉,嘿嘿,你懂的... 新来的程序员老鸟,在一个开发团队中,需要表现一下自己的水

程序员如何写出一份好的文档?

写文档的重要性 对于软件相关行业,在学校或单位大家也许都已经注意到了,除了要编写的程序.绘制设计图之外,还有一个重要的工作便是写文档.为什么要写文档呢?因为我们要把自己做的东西展示出来,不光展示给同行看,可能还要展示给其他岗位上的工作人员看,甚至展示给用户看.如果我们只是会写程序,不会在文档中恰当且优雅地描述自己的想法,那么就真正的成为“码农”了. 我注意了一下,周围的同事会写高质量文档的确实很少.李开复老师在<浪潮之巅>的序言中说到:“我认识很多顶尖的工程师,但具备强大叙事能力的优秀工程师,

从 Word 到 Docbook, 最后用 Pandoc, 让程序员爱上写文档

写文档一直是程序员非常讨厌的工作, 甚至和改需求一样令人厌烦. 在程序员眼里比写程序还难, 即便强制执行下来文档质量也很难让人满意. 相信大多数公司写文档都是用 Word, 笔者也是用了 Word 写了好几个项目的文档. 架构, 设计, 运维等好几份, 呵呵, 即便是写的再好, 交给客户也基本是不看的. 一个文档是项目组内好几个成员编写的, 大家各写各的模块, 各自的实现, 然后一起合并, 合并时修改字体, 字号, 目录等, 第一次合并还好, 再升级几个版本后, 大家改了哪里, 没改哪里, 根本

给程序员新手写简历的一些建议【转】

最近帮很多朋友review他们的简历,总结起来存在以下问题: 1简历太多页 请尽量不超过两页.一般地,每个hr阅读简历的时间大概在20s,甚至更少.写那么多页不仅毫无必要,而且有害.而且我怀疑一般的应届毕业生不大可能说写三页的履历.有些人说,你写不了三页是你水平不行,经历不丰富.按我说,写三四页不是履历丰富,而是根本不会写作. 2大量无用信息 这些无用信息具体包括: 民族,身高,是否团员,具体家庭住址.星座 自己的兴趣爱好.喜欢打篮球和写代码有联系吗? 自我评价最多一句话,不要一坨一坨.建议不要

程序员自己写测试,还要测试人员做什么?

在向开发人员介绍单元测试或TDD等工程实践时,往往可以听到这样的疑问.比如: 自己写的程序,自己无法从另一个角度测出问题.写bug的时间都不够了,哪有时间来写测试?开发来写测试了,测试干什么?除了核心代码,没有什么值得测试的.-- 一个例子首先我们看一个例子. 全项目唯一的测试 不止一次,我在各种项目中看到这样的测试,往往这也是整个工程中唯一一个测试.可以看出,开发者认为编写是有必要的.所以按照"标准"的做法建立了测试目录,引入JUnit依赖.并且利用它在开发的初期来验证某些技术疑问,

5年的程序员职业生涯写上我的一些想法

 在程序之外,是程序员的生活. 作为一个已经工作5年的程序员,对生活认识,有一点个人想法想表达一下,当我们刚刚告别校园成为一个程序员时,大都拥有成功的梦想.万分的激情,那时的我们也拥有精力充沛的健康身体. 随时间流逝,5年过去了.10年过去了,也许,梦想可能渐渐暗淡,激情慢慢消退.但,有一点是肯定的,我们的身体大不如前了,像视力下降.慢性胃炎.颈椎病.失眠.神经衰弱等等接踵而来,这些病症几乎成了我们这个行业的职业病. 从健康的角度来说,程序员这个职业,有几个非常不利的因素: 第一,程序员需要