• 注册
    • 总打赏排行
    • 今日收益排行
  • admin
    I'm a Slash!
    打赏了977人参果
    关注
  • 977725219
    太拽了什么都没留下。
    打赏了43人参果
    关注
  • 蔚蓝的海
    太拽了什么都没留下。
    打赏了35人参果
    关注
  • 25℃ 咖啡
    太拽了什么都没留下。
    打赏了13人参果
    关注
  • swallow2009
    太拽了什么都没留下。
    打赏了10人参果
    关注
  • lili1985
    太拽了什么都没留下。
    打赏了10人参果
    关注
  • 斜杠青年
    青岛海尔文化产业发展有限公司
    打赏了8人参果
    关注
  • GOOGOGOGOOG
    太拽了什么都没留下。
    打赏了5人参果
    关注
  • 易赚360
    腾讯计算机系统有限公司
    打赏了3人参果
    关注
  • admin
    I'm a Slash!
    今日获得295人参果
    关注
  • 小虫
    太拽了什么都没留下。
    今日获得210人参果
    关注
  • workdog959
    太拽了什么都没留下。
    今日获得200人参果
    关注
  • 小区区
    太拽了什么都没留下。
    今日获得150人参果
    关注
  • 态度嘛
    太拽了什么都没留下。
    今日获得150人参果
    关注
  • 武汉毅行团建拓展
    毅行拓展(Tel:13100636712)www.yixingok.com
    今日获得121人参果
    关注
  • 搜楼网
    搜楼网的运营者:http://www.soolou.com
    今日获得120人参果
    关注
  • 唯爱之美
    太拽了什么都没留下。
    今日获得110人参果
    关注
  • 餐饮新点子
    赞奇外卖代运营联系微信17333050112
    今日获得110人参果
    关注
  • 跨境电商之家
    Http://adoncn.com/ 跨境电商之家
    今日获得105人参果
    关注
  • 查看作者
  • 在程序员眼中,优秀的产品经理是什么样的?

    作者: 虞大胆,微信公众号:虞大胆的叽叽喳喳(ID:yudadanwx)

    全文共 5609 字 15 图,阅读需要 15 分钟

    题图来自正版图库:图虫创意

    ———— / BEGIN / ————

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

    我看完后,就在想:什么时候,一个产品经理把程序员激怒了?

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

    今天谈一谈什么样的产品经理是优秀的(至少是我认为的),这篇文章也是心血来潮,带有很多的个人情绪,说的也不全面,很多都是泛泛而谈。

    从四方面简单谈一谈,如果将来有机会,再做进一步细化阐述。

    一、专业性

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

    那专业性体现在哪儿呢?

    一个需求不管多小,也应该有完整的产品需求文档(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)有自己的人格魅力

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

    向那些专业的产品同事致敬!!

    ———— / END / ————

    点击“阅读原文”下载APP

  • 0
  • 0
  • 0
  • 68
  • #人人都是产品经理
  • 单栏布局 侧栏位置: