作者： 虞大胆，微信公众号：虞大胆的叽叽喳喳（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 / ————