分析：如何做一个让程序猿讨厌的产品经理_第1页
分析：如何做一个让程序猿讨厌的产品经理_第2页
分析：如何做一个让程序猿讨厌的产品经理_第3页
全文预览已结束

下载本文档

版权说明：本文档由用户提供并上传，收益归属内容提供方，若内容存在侵权，请进行举报或认领

文档简介

【计算机论文】分析：如何做一个让程序猿讨厌的产品经理

开始实施之前【不说清需求价值】，技术问“为什么要做”的时候，支支吾吾，或者说“老板要的、运营要的”，假装是个传话筒，因为接二手需求，并不知道、也没有去追溯这个需求的初衷。相反，切忌不要有理有据的顶老板，那会让大家喜欢上你；【不去想功能细节】，技术问细节(当然，是涉及业务的细节，不是技术实现细节)的时候，自己装作还没想过，现场想——这样做吧，那样做也可以，或者你定吧……要巧妙的被发现，这时候你已经能听到技术的心里话啦——傻逼；【帮技术评估工作量】，特别是技术出身的产品经理，最容易做到，潜台词就是“希望加活”，我评估过了，这些都能做掉的，不要给我偷懒，哈哈哈哈哈哈；切记，不要把他们当人，而要当“资源”；【逼着技术团队承诺】，哼哼，公事公办，如果技术承诺了，但却做不到，这样自己就没责任了，可能对方会说——很多事情，在开始的时候是谁也不知道的，应该大家在一条船上同舟共济，这就是“接力跑”和“踢足球”在交棒/传球之后的区别。你可以回：我不管我不管我不管；实施过程中【做了一半改需求】，scrum里的表现就是sprint内的“非受迫需求变更”，太狠了，技术同学肯定很难忍受，特别是产品经理自己没想清楚，而导致的劳动浪费，俗话说“没有变更就没有伤害”，碰到性子烈的就直接要干架了，汪们，这时候要注意保护自己；【开发过程中消失】，你可以多安排点出差、多开开会，注意尽量手机关机，不要响应技术的问题，要不然，责任就回来了。让他们为了进度照着自己的想法做下去，关键是，验收的时候跳出来说“这不是我要的”，再次，注意人身安全；【过度关注实现细节】，帮技术决定技术方案，也是技术出身的产品经理应该很容易做到这点，变着法儿的越俎代庖，把他们全部从积极主动小伙子，打击成一个纯打工形态的“资源”，哎，又用这个厉害的词了；产品发布之后【发布后没有反馈】，技术人员也需要从市场、用户那里获得反馈，从而知道自己做的事情产生了价值，提升成就感，我们要做的就是，做完发布，马上石沉大海，不告诉大家任何结果，甚至庆功会都忘了他们，紧接着赶紧继续安排他们干活；【无节奏感】，让技术人员忙一阵闲一阵，发布之后再忙着研究接下来做什么，一会儿让技术人员有着干死干活的高强度，我就是要结果，deadline，死命令，之后突然不知道做什么——你们也一起来讨论下业务吧，或者培训培训做做团建什么的；全过程都可以做的【优柔寡断无决断】，能表现出这个品质就最棒了，就是在已经讨论完毕后，大家都等着你拍板的时候“你说吧，往哪儿走我们就跟着办”，这时候你说“啊，那个，各种方案各有利弊啊，我也不知道怎么办啊，你们有什么好想法……”；【报喜不报忧】，藏着掖着一些信息，比如“老板在考虑干掉这个项目”这类信息，表面打死不承认，但让大家通过其他途径知道，很容易就把互信完全打破，这时候他们可讨厌你了；【不要把他们当人】，这点，最狠了，不关注成长，只关注结果，不能再说了，我们只是要做一个程序猿讨

人人文库> 全部分类> 专业文献 > IT计算机

温馨提示

  • 1. 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论