看andy 的《PM如何突破工程师心防?》和《工程师如何不被PM欺负》感触了一下,欢迎拍砖,讨论。
从团队角度说产品经理和开发工程师应该是一条战线上的兄弟,因为大家的目标是一致的。无论是产品经理和开发工程师大家都想把产品和项目做好,这里我们可以说:"志同"。
但是产品经理和开发工程师因为在产品开发过程中所扮演的角色和工作内容不同,而且可能相互不了解工作内容,期间会有很多沟通的成本,沟通不是说话,而是改变行动。真正的沟通者关注沟通的效果。在沟通时,重要的不是你说了什么,而是对方理解了什么,所以对方的反馈非常重要。往往很多产品经理和开发工程师的沟通会出现"驴头不对马嘴"大家相互听不懂的情况,甚至会导致小摩擦,这时我们说:"道不合"。
"道不同不相为谋",必定导致意见不一,甚至带来工作上心情不愉快的影响。不管是产品经理和开发工程师哪一方强势,或者在"交战"过程中哪一方"得胜",势必会给另一方造成消极影响,甚至颓废。导致的结果总会是这个产品或者性能,或者其他方面总是会有不尽人意的地方。项目结束,考核绩效或者项目总结的时候又会把责任推到对方身上,接下来就是大家相互抱怨,指责。然后产品改进时又是下一轮的"战争";长此以往,造成的影响不是产品做不好,不是主要的后果,这个产品做不好,我们可以改进,可以做下一个产品。最严重的后果是,团队分崩离析,一盘散沙,没有凝聚力。没有凝聚力的团队是绝对没有战斗力的,是绝对做不出好的产品的。这对团队和公司来说是致命的。
虽然很多人都明白这些,然而,这样的"战斗"或者产品经理和开发工程师的矛盾却时时刻刻在发生!大家可以看看知乎上两个问答: yixieshi
1.《产品经理最讨厌开发人员的哪些臭毛病?》 http://www.zhihu.com/question/19629183 yixieshi
2.《开发人员最讨厌产品经理的哪些臭毛病?》 http://www.zhihu.com/question/19628273 yixieshi
如何解决这些问题,请看andy 的《PM如何突破工程师心防?》和《工程师如何不被PM欺负》,虽然在实际的过程中你未必能做到,但是至少我们可以从中得到一些启示。
=================================================
PM如何突破工程师心防? 互联网的一些事
转自:http://www.kuobrothers.com/article-125.htm
PM常常遇到一个难题,就是有好多东西想要做,到无奈什么事都得透过工程师,没办法自己动手,于是因为和工程师不太美好的关系,最后实际的产品都没有设计时看起来好。我这边讲的是「网路公司」的状态,PM泛指那些规划出产品的人。其他产业也许也有类似情形,以下这些「教战手则」,提供给正在摸索自己生存之道的PM一些参考。
先弄清什么做得出来、什么做不出来:
常常有PM会提出一些天马行空的idea,以致有时候让工程师觉得合作起来相当吃力。这是由于并不知道什么可以做什么不能做。以网站来说,这其实很容易知道,不需要太多的学习和知识。如果有一个功能,你在两、三个网站都看得到,99%它是做得出来的。例如你想要有一个页面,填地址时选完「县市」,下一个选单就会载入你选的这个县市的行政区。如果你做些功课,就可以发现这样的表单在很多网站都出现过。那99%就是做得出来。如果你想出一种呈现的方式,从来没在任何地看过,那就比较有可能是做不出来的。在对工程师沟通时,假如你想做一个像这种选「县市」的下拉选单,你最好请工程师去看别人的那个网页,而不是用你自己的方式描述。工程师通常有不想输的性格,如果别的网站做得出来,他不会想要自己做不出来。 一些事
永远不要和工师辩论任何和技术有关的东西:
当PM能学一点点网页的概念是好的,但跟工程师合作,你可能常常会听到「这很难做」的feedback。它可能代表几种不同的意思。可能代表真的很难做,也可能代表他不想帮你做。如果是第二种,有很多种方法可以让他妥协。但戳破他和找他辩论绝对是最差劲的方法。当他说这个技术上有困难时,绝对不要跟他说「这个只要… 就可以了呀!」这样也许让自己看起来比较聪明,但你们的关系已经完蛋了。而且工程师的性格容易有非常强的自尊心,所以千万别这么做。而且,technical的领域,你可能永远也辩不赢他。很多「这个不能做」的问题,不是来自于理性,而是来自于不想、不愿意、觉得这个没意义、或真的很花时间。真的要做的话,99%的东西大概都可以做。因此当这种看起来由technical角度来拒绝你的状况发生,如果你真的很想坚持你的想法做下去,请试着脱离technical的讨论,你该了解他所提出technical的障碍,但绝对不要和他在这个领域上辩论。因为你辩赢或输都没有任何好处。
工程师喜欢你去求他:
工程师很容易有某一种性格,是坐在那边希望大家都去拜托他。所以你不难想像要让这种人帮你做事的方法就是你要放低你的姿态。你要让他觉得是你需要他,不是他一定要帮你。即使你心里一直想「公司付你钱来上班本来就是要做这些的…」放低姿态。也许身为PM的你,在每个project有进展的时候和卡住没进展的时刻,拿饮料点的menu去问工程师要喝什么是个好方法。
把所有credit归给工程师: yixieshi
在公司里,因为很多产品是由PM规划的。因此project的成功,大家很容易觉得是PM的功劳。请努力在任何公开的场合、email,把这些credit归给和你一起合作的工程师。同样一个spec,一个心情好的工程师,可以把它做成100分。一个心情不好的工程师,可以把它做成60分。两个都可以100%符合你的spec,但是一个可以烂到有无数问题。因为软体不是事前可以想清楚的。所以一个不开心的工程师,可以看到许多问题但「视而不见」,也不主动来跟你说,那你就完了。所以一定要让全公司的人都觉得这些成就属于工程师的。你把credit拿走一次,下一次你就完了,因为没有人想为你卖命了。
不要轻视「工程师的project」 yixieshi
你合作的工程师可能说他现很忙,因为他正在「重写一些function」或是「让资料库的速度快一点点」。很多PM在听到这些的时候,并没有很知道他们在做什么,于是表现出来的会是对这些project没那么在乎或什至不觉得他们重要。通常工程师最喜欢做这种隐性的project。因为他们可以不用听PM的指挥。对于一个健康的公司来说,一定会有一定比例的资源投在这些project。要不要做通常是由老板,或更懂得这些东西的人来决定。但你一定要在工程师的面前让大家觉得你看起来对这些非常认同。
姿态放软,但不能失去主导权
虽然前面说你姿态要软,但你绝对不能把你的project交给工程师后,你就失去了主导权。因为这样会让你在老板面前,看起来变得没有太多价值。你最少要继续掌握你project的「时程」和「内容」。也就是你一定要维持你的「主导权」,对该坚持的东西继续坚持,对一些东西妥协,但不能全交给工程师决定。
不要finalize所有设计后,再交给工程师
绝大多数的工程师对这样的流程很反感,所以请想办法在设计阶段,就去请教一下工程师的意见。他也许说他很忙,你想就好。即使只是得到这句话,都有很大的价值。这表示他放弃了他未来因为你在project早期没找他先过过,以致他责怪你的权利。
总之,因为工程师的心情很难捉摸。所以「情绪」的处理问题,可能比「技术」、「功能」上的讨论都更为重要。如果你喜欢这篇文章,也许你可以再读一读这篇的「相反版」:工程师如何不被PM欺负?
================================================= yixieshi
工程师如何不被PM欺负
转自:http://www.kuobrothers.com/article-127.htm
老师教我们怎么写程式,但从来没告诉我们在公司里,会有个叫做PM的人每天分派作业给我们,还逼着我们赶快做完。这是许多软体工程师进入职场的第一个惊喜。隔了不久,还会发现,这些可能把你压得死死的PM,多半一行程式都不会写。于是我们会面临一种很矛盾的心情,有时候会是一种有点被欺负的心理。这篇文章是前一篇文章PM如何突破工程师的心防 的延伸,我们讨论的是工程师在这样状况下的生存之道。
(1)提高自己的能见度
在非常多的公司,上层的老板或公司的大老板只看得到一个project的PM,而看不到背后辛苦的工程师。也就是说,你的努力和成果,被遮敝了。我一直相信在职场上,让自己在老板或其他同事前有「能见度」是重要的。能见度除了在很多状况下(会议发言、讨论…)可以显现出来外。提供一个我有个朋友很厉害的一招给各位参考。身为一个工程师的他,在每个大的project进行完后,都会「不经意」的寄出一封「谢谢信」给参与这个project的每个人,顺便cc给本来根本不知道他在做什么的大老板。信里面一一点名感谢每个人给他的指导和这个project的协助。这种信每个人看了都很高兴,最重要的是最后大老板也对他有了深刻的印象。
(2)不要每天只埋头写程式:
工程师大部份很喜欢埋头写程式,因为这是自己最擅长,也是最不花力气的事情。但如果你每天100%时间写程式,我保证你会自我感觉良好,但是所有人都不知道你在做什么。所以也许该换换策略,让自己的时间有多一点的部份是用来「表现自己」。「表现自己」不代表做一些表面功夫浪费时间。而是以你的角色,来参与讨论,给出有意义的建议。工程师很喜欢只用电脑和其他人沟通,想要进度都用一个系统来追踪,想法都用email来讨论。在职场上,很重要的是你要学习少用email,多走过去和那个人说话。也许走过去多花了1分钟,但是你和其他人互动良好,会让你在职场上过得比较顺利。
(3)站在老板的角度想事情:
工程师由于角色的关系,非常容易会站在「技术」的角度想事情,但往往常被主管否决而觉得灰心。公司的想法通常和PM的想法比较接近,都是站在公司的利益想事情,极少用「技术」的角度想事情。你要试着跟他们想的一样,你的日子才会过得快乐。举例来说: 假如我们公司现在要输入10000笔资料。有两个方案,方案A是「手动输入」,方案B是「用程式自动汇入」。方案A要请10个工读生,一笔一笔输入几乎都没有差太多的资料。方案B是支无敌厉害的程式,你开发一天,程式跑3秒钟就全部完成。但评估起来方案A的总体成本比方案B还要低。我相信极大多数的公司经营者,都会愿意找来10个人,做着重复的事情,一笔一笔key in资料。如果你以工程师的角度来想,你可能会觉得「这个这么简单,一支程式就好了」,然后开始觉得老板选择方案B真迂腐。你要试着让你的大脑跟公司的利益sync,这样会让你好过很多。因为绝大多数的PM都知道他们的大脑要怎么跟老板sync。在老板面前让自己显得比PM聪明的方法只有一个,那就是大脑和公司利益的sync做得比PM还彻底。
(4)用PM害怕的弱点有效去争取更多开发时间
PM很喜欢每个东西都如期上线,如果提早上线就更好。很多人会因为deadline而跟PM翻脸,这是不智的。回到我那位工程师朋友的例子,他会和颜悦色的对PM说「我可以每天熬夜来把它做完,有可能可以如期上线,但我知道它会出现很多『我们』现在都没想到的问题,那可能会让老板(或客户)觉得我们很不仔细。但如果你可以帮我争取多一点时间,我可以让它品质好很多。」对PM来说,除了要「快」以外,东西如果出来很烂,也打到了他的痛点。我的工程师朋友用这个方法帮自己争取到了比较长的开发时间,和更好的睡眠。
(5)用PM的语言和他沟通 互联网的一些事
很多工程师会习惯用自己的语言和PM沟通,于是造成沟通不良。我们得试着让自己对他们的谈话,是世界上任何一个人都听得懂的语言。尽量少提技术的术语,尽量少让PM觉得你用你的技术优势在打压他。因为PM不可能学会工程师的语言,所以你们唯一能沟通的可能,就是你学会用PM的语言。
(6)变成工程师团队里面最受PM们欢迎的人
你会发现,如果叫PM们投票,从最喜欢合作的工程师,排到最不喜欢合作的工程师。大家的清单常常非常一致。而且你会发现,在清单名列前矛的人,通常在职场上容易步步高升。所以,想办法变成那个人吧! 因为PM们对你的评价,往往在公司里,和你的工程师主管对你的评价同样重要。
(7)上班前三个月,不要试着改变公司任何东西
公司的系统、公司的project、流程,所有的东西。会是现在这个样子,都必定有它的原因。有理性的原因,也有不理性的原因,也可能它的原因就是没有原因。但绝大多数的公司找你进去,是想要你把一个东西,在他「现在的架构」下开发出来。在前三个月,如果你觉得大家用的开发环境很烂、测试的流程很烂、任何平台很烂。请先忍耐一下,因为除了非常非常open minded的主管和同事,绝大多数的人不会对你刚进来就想改变一切的想法太欢迎。 互联网的一些事
(8)归功给PM:
EQ好的PM会把project归功给工程师。但做为工程师的你,如果EQ够好,应该再把它归功给PM。不要因为这是你写的code,就认为这是你自己做出来的。因为这样除了自己感觉良好外,对职场生存没有帮助。想办法「言必谈PM」。把自己和PM当成一个team,这个project是我们一起做出来的。虽然很多PM会戏称自己是在旁边帮忙打杂的,但是他会很感谢你很体贴的把一些功劳归于他。
(9)不要为了enjoy自己的成就感,浪费公司的资源
很多工程师喜欢把公司当lab,去试验一些新的技术。如果这对公司「真的有帮助」的话,那当然很好。在做这些事或提议前,请试着用老板的角度想,在公司利益最大化的前提下(而非个人学习或成就感),他会不会打从心里支持你做这样的试验。如果不会,那就千万不要做。因为在你做的很开心的同时,别人可能觉得这只是在浪费公司资源。 互联网的一些事
(10)变成一个更像PM的人 yixieshi
在技术上你应该向你其他工程师同事看齐,但在「性格」或「行为」上,通常你应该去模仿PM team的人。请相信我,在绝大多数公司,「性格」和「行为」近似于PM的工程师,在公司里是最吃香的。
写这篇文章,也许还会再得到一些批评。但我只是单纯善意的,想告诉工程师们。我们应该提高自己的能见度,适度的让其他人看到我们的表现。以及让自己变成一个外表看起来像PM的工程师,通常在公司里会过得蛮好的。很多工程师会觉得自己被PM欺负,但PM通常不会欺负长得和他们一样的人。如果你喜欢这篇文章,也许你可以再看看这篇: PM如何突破工程师心防?
转自:http://www.yixieshi.com/zhichang/11449.html
分享到:
相关推荐
产品经理是企业中至关重要的角色,他们负责引领产品的市场策略,确保产品符合市场需求并带来商业成功...这些基本功是产品经理成功的关键,通过系统的学习和实践,产品经理可以为企业创造竞争优势,推动产品的市场成功。
4. **协作与沟通**:产品经理需与设计师、工程师、营销团队、销售团队等多个部门紧密合作,确保每个团队对产品的理解和执行方向一致。有效沟通是产品经理的关键技能。 5. **项目管理**:产品经理需要跟踪产品的开发...
5. **团队协作与沟通**:这部分可能强调了产品经理与工程师、设计师、销售、市场等部门的沟通技巧,以及如何通过有效的会议、文档共享和协作工具来推动项目进展。 6. **数据分析**:数据驱动决策是现代产品经理的...
综上所述,"从点子到产品_产品经理的价值观与方法论"涵盖了一系列关键概念,包括用户中心设计、敏捷开发、产品策略、跨部门协作、产品生命周期管理和创新思维。这些知识点是产品经理成功推动产品从概念到上市的关键...
在产品开发过程中,产品经理需要撰写一系列文档来清晰地表达产品需求、目标和策略。"产品经理文档模板.zip"是一个集合了各种常用产品经理文档的压缩包,旨在帮助产品经理更高效、规范地完成工作。 压缩包中的文件...
产品经理是互联网行业和科技巨头如华为中的核心角色,他们负责产品的规划、设计、开发到上线的全过程。产品经理的职级体系通常反映了他们在公司中的地位、职责范围以及所需的专业技能。以下将详细介绍产品经理的职级...
B端产品经理是负责开发和维护企业内部系统的产品经理,目的是为了提高企业的运营效率和客户满意度。 B端产品经理的工作流包括规划阶段、设计阶段、研发阶段、发布阶段和监控阶段。在每个阶段中,产品经理都需要具备...
本资源手册旨在指导硬件产品经理从构思到销售的整个过程,涵盖硬件产品经理的角色与职责、技能要求、硬件产品开发流程、产品概念与市场分析、目标市场与用户群体、硬件产品规划与设计等内容。 第一章:硬件产品经理...
8. **团队协作与领导力**:介绍产品经理如何与设计师、工程师、销售团队等协作,以及如何培养和展现领导力,推动整个团队共同达成目标。 9. **案例研究**:书中包含多个实际产品案例,分析成功与失败的原因,提供...
产品需求文档(PRD)是产品经理与开发团队沟通的桥梁。PRD详细描述了产品的功能、性能、用户体验等方面的要求,通常包括问题背景、目标用户、功能规格、业务规则等部分。一份清晰、详尽的PRD能确保开发团队准确理解...
产品经理是互联网行业中至关重要的角色,他们负责连接技术与市场,理解和定义用户需求,制定产品策略,并协调团队将想法变为现实。这份"互联网产品经理文档模板"集合了产品开发过程中的核心文档,帮助产品经理们系统...
他们负责编写产品需求文档(PRD),明确产品的功能、用户体验、性能指标等,同时协调设计师和工程师,确保产品按照预期进行开发。产品经理还需要具备一定的技术理解力,以便与技术团队进行有效沟通。 此外,产品...
9. **技术基础知识**:虽然不一定要精通编程,但了解基本的技术概念和技术实现方式,可以帮助产品经理更好地与工程师协作。 10. **法律与合规**:产品经理需要关注产品可能涉及的法律法规,确保产品的合规性。 ...
本文主要介绍了成功产品经理所需的十个基本功,涵盖了从市场研究到产品设计的全过程。以下是这些基本功的详细解读: 1. 市场研究:产品经理需要深入理解市场环境,包括微观和宏观环境,运用各种分析工具如竞争格局...
在国内外知名企业担任过多个重要职位,包括开发工程师、项目经理、产品经理等。他还成功组织建立了适合当时情况的研发流程管理、项目管理、技术管理体系。通过与IBM顶尖咨询顾问的合作,全面负责了集成产品开发管理...
本书《互联网金融产品经理:从金融业务解析到互联网产品设计实战》主要介绍了互联网金融产品经理的核心职责与技能要求,以及从金融业务解析到互联网产品设计的全过程。以下是本书的知识点总结: 一、互联网金融产品...
本课程《产品经理核心技能提升训练营.pdf》旨在为产品经理提供从理念、流程、方法、工具到案例分析和实践方面的全方位训练,帮助其提升专业素养与技能。 首先,产品经理需要具备正确的理念。产品思维、互联网思维、...
至于"用例",它用于描绘用户如何与产品互动,帮助团队明确产品的功能设计和用户体验。用例通常包括预设条件、操作步骤和预期结果,确保产品设计满足实际场景需求。 此外,"市场分析"和"竞品分析"也是产品经理的必备...