大师网-带你快速走向大师之路 解决你在学习过程中的疑惑,带你快速进入大师之门。节省时间,提升效率

程序员:我心目中的优秀产品经理

文作者作为一个老程序员,从四个方面来谈一谈什么样的产品经理是优秀的。

上上周朋友圈被一个程序员和产品经理互喷、互殴,然后被解雇的事情刷屏了,至于发生了什么,其实并不重要,大家哈哈一笑,第二天可能就全忘记了。我看完后,就在想,什么一个产品经理把程序员激怒了?

作为一个老程序员,我是经常怂产品经理的,有的时候都成习惯了,但我也见过很多牛逼的产品经理。

今天谈一谈什么样的产品经理是优秀的(至少是我认为的),这篇文章也是心血来潮,带有很多的个人情绪,说的也不全面,很多都是泛泛而谈。从四方面简单谈一谈,如果将来有机会,再做进一步细化阐述。

一、专业性

任何一个岗位都有其专业性,一个产品经理即使沟通能力不佳,协调能力不强,但只要专业能力足够擅长,也会受到程序员的尊重。那专业性体现在哪儿呢?

一个需求不管多小,也应该有完整的产品需求文档(PRD),代表产品经理的严谨性,以及对这个需求的深刻理解(即使需求错误也是可理解的)。产品需求文档形式不一定需要标准的形式(毕竟不是论文),如果需求文档格式很完整,但空空无物又有什么用呢?

需求文档可以有自己的个人风格,只要足够严谨,能让程序员看懂即可。

具备原型图设计能力,对于程序员来说,很难有耐心仔细看需求文档,他们更喜欢“动态”的原型图;对于产品经理来说,为了理顺自己的思路,思考需求的合理性,最好的校验工具就是画原型图。

所以不管从哪个角度来看,产品经理应该学会一种原型图设计软件,比如:Axure。原型图是对产品需求文档的一个有效补充,从不同维度完善项目需求,极具立体性。

逻辑性,这是非常关键的一个能力,产品经理将用户的需求转变为产品需求,文档最重要的就是逻辑正确,经常和一些产品经理开会,发现他们自己都无法将需求理顺、也无法说服自己、无法应对质疑,即逻辑性存在很大的问题。

如果一个产品经理存在逻辑性较差的问题,那就要好好修炼内功了,如果无法洞悉用户的真正需求,会给公司产品带来万劫不复的灾难,但也从另外一方面体现了产品经理的重要性。

UI 审美能力,我发现很多优秀的产品经理都会画画,他们也会 UI 设计,即具备很强的审美能力,知道页面风格的重要性,或者说这些产品经理的联想、发散能力是极强的,这也是他们专业能力的体现。而对于程序员来说,这方面可能就是白痴,他们只关心逻辑思考能力,反向说明产品经理是要求非常高的一个岗位。

产品经理在大家看来是一个万花筒,沟通能力、协调能力非常重要,为什么没有提及?

其实任何一个行业,任何一个岗位这些能力是必须的,没有必要强调。这篇文章完全以我的视角解读优秀产品经理的判断标准,极具个人色彩,可能存在极大的偏向性。

二、熟知开发流程

产品经理的专业性不可能一步到位,需要慢慢积累才能成长,但对于一个刚入门的产品经理来说,理解项目流程非常重要,否则就像苍蝇一样,不知道要干啥好,到处碰壁,四处吃亏,变成程序员眼中的一个傻子。

了解各个岗位的职责,在互联网公司,分工是非常细化的(尤其是开发人员),一个具有一定规模的公司,有系统开发人员、应用开发人员、前端开发人员、客户端开发人员、数据分析人员、系统运维人员、应用运维人员。

而且这些岗位人员之间的职责还可能交叉,如果产品经理不了解这些岗位的区别,出现问题或者提需求找不到正确的人,那就非常麻烦了,会极大减少积极性,也会让人疲惫不堪。所以产品经理平时要多留心,找到解决问题的合适人员。

测试的重要性,在大公司有专门的测试岗位,但不代表产品经理能够忽视它(很多产品觉得自己怎么成为测试人员了,这也是他们的吐槽点之一,觉得没有时间干自己的专业了),此处我要强调冒烟测试的重要性,很多开发人员由于多方面的原因,匆匆忙忙完成某个项目,然后将其部署。符合预期吗?

冒烟测试是校验预期最好的手段,对于产品经理来说,自己进行冒烟测试,也能以用户的角度体验产品功能,进一步思考合理性。所以说产品经理一定要明白测试的重要性,也要熟知测试的流程。

邮件确认机制,很多产品经理和开发人员平时好的就像亲兄弟、 亲姐妹一样,项目进度不出问题的时候还好,出现问题的时候就非常尴尬了,产品经理是第一责任人了,也就是说一个项目从构思到上线,甚至到跟踪。

产品经理必须全程关注,尽力确保项目上线,其中邮件确认机制就是非常重要的一个点,在关键节点一定要发邮件周知相关人员,一方面是汇报进度,另外一方面也给程序员提一个醒。

对于非功能需求的把握,非功能需求包括性能、扩展性、可用性等技术指标,虽然这些更应该由程序员关心,但产品经理一定要明白此中的道道,它也是产品开发过程中非常重要的一环,产品经理有必要有义务提醒程序员。

JIRA跟踪机制,产品或功能上线后,产品经理要及时获取用户的反馈,包括用户遇到的问题、建议,可以通过 JIRA 长期跟踪,要协助程序员一起分析问题,这样才是一个善始善终的优秀产品经理。

三、不要让程序员讨厌你

对于产品经理来说,让程序员尊敬你非常重要,那么如何做到呢?

一方面是提升自己的专业能力,另外一方面就是少做龟毛的事情。尤其程序员的性格非常直接,惹恼他们后果很严重,所以某些细节一定要留意,至少对我来说,下面的十个情况要尽量避免。

(1)不要用嘴代替需求

有些产品经理脑子里冒出个想法,一拍脑门觉得自己就是个天才啊,赶紧让程序员去开发吧,就吧啦吧啦跑到程序员面前,说你开发这个功能吧,接着又语无伦次的描述了所谓的需求。

可这些需求你论证过吗?用户需要吗?流程能跑通吗?自己都不一定明白,还期待程序员能够听懂?

这是一种非常不负责任的行为,久而久之会让程序员非常反感,所以一定要切记。

(2)程序员的监工

有些产品经理好像保姆一样,就怕程序员不主动,怕工期来不及,每天趴在程序员后面,盯着他们开发代码,好像监工一样。这种行为让程序员特别不自在,他们有自己的工作方式,不写代码不代表不在工作,他们大脑在后台飞快的思考着,当然要是一个美女产品经理跟在后面就另当别论了。

另外有些产品经理喜欢陪程序员加班,我觉得这种形式也非常不好,只要把需求提清楚了,没有必要好像亏欠什么的,不一定要用陪同这种形式来支持程序员。

(3)2/8 法则不可违

有些产品经理要求特别严谨,但程序员也有难处,比如:某个功能暂时确实不好实现,问产品经理能不能变通一下,将需求弄简单一点。傻逼的产品经理可能就较真了,说不行,一定要按需求做,此时矛盾就无形中产生了,实际上正确的做法就是问自己:我核心的功能完成了吗?舍弃的功能影响全局吗?

如果不大,确实可以尊重程序员的意见,将 20% 的核心时间花在重要的事情上,等后续有时间了再完善,这种做法是毫无问题的。产品经理要有极强的辨识能力,明白一个项目的核心功能是什么,不要太拘泥小节。

(4)讨论变成需求

经常遇到这样的场景,产品经理出了一个需求文档,然后大家开会讨论,开会过程中产品经理的想法被无情的批判,自己也毫无主见了,然后大家互相出主意,程序员也很开心,产品经理也很满意,因为开会讨论出了需求,程序员不会龟毛到反驳自己提出的意见吧,在某种程度上这是一种好现象,实际上我不提倡这种方式。

无情的被人反驳,只能证明产品经理思考不成熟,是自己专业能力不强的一种体现,作为需求方,需要捍卫你的想法,如果轻易被撼动,只能证明自己还要加强学习,说的难听一点,只要能说服自己,有的时候要坚持自己的想法和需求(和固执是两码事)。

(5)你不是开发人员

有些产品经理比程序员还程序员,动不动就帮技术人员想解决方案,说这个应该这么弄,设计方案会不会有性能问题啊,时时刻刻显示自己的逻辑能力。

俗话说术业有专攻,我希望产品经理不要从程序员的角度去思考问题,而是以用户的角度去思考问题,提出需求,实现是程序员的事情。如果程序员觉得实现有问题和麻烦,必然会找你,如果你能听懂、且赞同,那么程序员会觉得你是在帮助他,这才是正确的做法。

在我漫长的职业生涯中,我遇到很多懂行的产品经理,他们逻辑能力比我强多了,但从不喧宾夺主,只在我为难的时候提出一些建议,让我受益匪浅。反而是一些毛都不懂的产品经理,天天给我秀智商。

(6)需求是否合理

本文开头说的那个故事,就是需求不合理导致的,产品经理一定要注意这一点,不要站在自己角度出发的,而是站在用户角度,需求不能想当然,多想想功能是用户需要的吗?千万不要做无用功,不要乱提需求。

有的时候我总有这种感觉,啥也不做比瞎做至少还能节省人力,不浪费公司资源。产品经理也不要动不动就说这是领导要的功能,和我无关。其实应该这么想问题:领导可能有一个想法,其中也许 80% 不可取的,而产品经理要做的就是将 20% 可取的部分强化,以此提出一个合理的需求。

(7)什么时候完成

有的时候产品经理刚把需求发给程序员,或者开会刚讨论结束,就迫不及待问啥时候能开发完成,领导急着呢。

有的时候还会抱怨这么小的一个改动就要2天?或者说这个开发很简单吧?

这是一些非常不职业的做法,软件开发有其自身的规律,需要设计、架构、编码、测试、部署等多个过程,是要求非常高的一个过程,所以千万不要一上来就要开发时间,很容易让人反感。

更好的做法就是问他们什么时候能评估出开发工作量(包括分析、设计),然后在邮件中周知,为避免程序员遗忘,可以提前询问一下。如果和某个程序员熟悉了,了解他的风格,可以采取一些策略来推动项目,切记不要动不动就问什么时候完成开发。

(8)我只管提需求

这一句话的下半句其实就是“其他我不负责”,在互联网企业,产品经理其实包含项目经理的角色,对于一个高速发展的企业来说,不可能按部就班的工作。而推进器其实就是产品经理,他们需要把握整个项目进度,不要认为仅仅提需求就行了。

代码是开发人员开发,推广也是运营的事情,产品经理本质上就是指哪儿打哪儿,和设计人员沟通、接受运营人员的需求、给销售人员数据、给程序员提需求、给测试人员写测试用例、给用户解答。

(9)找领导

有些产品经理是急性子,一看程序员不配合,或者进度赶不上,就说找技术总监,好像找了就能解决问题,有的时候也有点欺负人的感觉。可实际上最终配合你的还是这些程序员,这和接下去要讲的人治非常类似。

我建议产品经理少拿这个杀手锏,有的时候它还不一定管用,和程序员应该永远报以合作的态度,合作不顺的时候,可以和程序员交交心,互相交流下想法,这样才有可能解决问题。

(10)缺乏反馈机制

一个产品功能上线后,如果反响比较好,产品经理当然觉得都是他们的功劳,这也无可厚非,可如果不好呢?

产品经理应该分析问题,思考是否需要优化它,也可以和程序员一些讨论,共同想办法。但大部分产品经理却毫不关心,好像根本就没有这功能一样,这种做法非常让程序员寒心,程序员就会觉得你们也既不不开发代码,也不关心项目的结果,长此以往,这样的产品经理会失去程序员的信任。

四、人治而非法治

任何一个行业,人与人之间的关系是必不可少的,对于程序员和产品经理来说,他们之间的沟通是最多的,也是关系最密切的人,相处融洽才能将工作做好。

关于如何相处是一门艺术,可以看专门的一些数据,我从自己的角度出发,简单列几点。

(1)理解程序员

程序员是非常独特的一类人群,性格可能和常人不一样,但都非常感性,有的时候也会口无遮拦,甚至熟悉后还和你发脾气。但大部分情况下,他们都非常纯真,没有太多的心机。

对于产品经理来说,面对程序员的各种莫名其妙的表现,一笑而过,大度一点,多想想他们的优点,尽力成为朋友,这是将工作做好的先决条件。

当一个产品经理进入新公司后,一定要仔细观察各个程序员的性格、特点,针对性下药,有策略的和他们融入在一起,但需要注意的是,不是让产品经理忍让他们,这也不是好策略,只是要尽量避免针锋相对。

(2)认同程序员

程序员不仅仅是开发代码,他们逻辑性强,思考问题全面,作为产品经理,要善于合作,尊重他们的观点,多听听他们的意见,千万不能说“这是需求,赶紧实现吧,其他的不用问”这样的话。

而是让程序员发表意见,比如说:“你觉得怎么样设计比较好一点”、“帮我看看逻辑是不是正确”,让程序员间接成为一个产品经理,让程序员意识到他们的重要性,意识到他们是设计者,而非仅仅是构建者。

当一个项目结束后,要多向他们反馈,反馈包括用户的反馈,也包括产品经理的自我批评。当项目结果不是很好的时候,也要及时和程序员反馈,反思失败的原因,这样才能让程序员意识到“这个项目的背景原来这么复杂啊”。他们也会从内心接收这一切,如果总是没有反馈,程序员会说“产品经理又做了一堆垃圾”。

(3)目标一致性

面对一个项目,真正推动项目的动力不是产品经理的催促,而是让程序员和产品经理目标达成一致,对于核心项目来说,他们一致目标就是“这项工程关系到公司的生死存亡,所以必须加油”。

那一般性的项目呢?

即使不重要,产品经理也要有极大的感染力,让程序员意识到“我在做一件有价值的事情”,只有双方目标是一致的,项目才能飞快往前走。

目标一致性来源于程序员对产品经理的感受,如果你足够职业,足够专业,是很容易感染程序员的。

(4)有自己的人格魅力

通俗的说,就是让程序员信服你,人格魅力不仅仅体现在工作上,也包括你平时的言行、你的做事方式、你的性格、你的价值观,只要其中有一件事情让程序员从内心深处佩服你,那么他会极力的配合好你。

欢迎加入Java高级架构学习交流群:375989619 我们提供免费的架构资料 以及免费的解答,不懂得问题都可以来问我们老师,之后还会有职业生涯规划,以及面试指导,我们每天晚上八点也有公开课免费学习:10年架构师分享经验,Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术

加群条件:

1、具有1-5工作经验的,面对目前流行的技术不知从何下手,需要突破技术瓶颈的。

2、在公司待久了,过得很安逸,但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的。

3、如果没有工作经验,但基础非常扎实,对java工作机制,常用设计思想,常用java开发框架掌握熟练的。

4、觉得自己很牛B,一般需求都能搞定。但是所学的知识点没有系统化,很难在技术领域继续突破的。

5. 群号:375989619高级架构群备注好信息!