开发人员眼中的优秀产品经理是什么样的？

Question

以下是某次活动的产出，可以参考
1.有一定的技术背景
2.在产品功能和技术成本间，可以客观地权衡双方利益
3.善于沟通，会打感情牌（女孩子会撒娇也管用）
4.有较强的产品设计逻辑和长期的产品规划，不是干一票就撒手不管的那种
5.善于抽象产品指标，善于利用指标和数据客观评估产品质量的
6.有较强的产品把控能力，比如项目大小，功能边界，需求细节等
7.尊重工程师的工作，愿意听他们的想法，潜意识中不要只把他们当做编程工具

直接补充一个问题，开发人员眼中的优秀产品文档是什么样的？

Answer 1

个人认为产品经理首先还是要有强大的专业能力，我经历了这么多产品经理开始懂得，你不能要求每个产品经理都能懂得开发，但是我们开发者实际上也要具备一定的产品能力，只有这样双方才能更好的沟通。毕竟开发与产品和谐相处也不是一个太好的局面。最近很流行的这张图展现他们之间的看法

Answer 2

把产品经理当女朋友看就一切都可以接受了 ><

Answer 3

优秀产品的文档，应具备以下要求：

1. 语意明确，陈述清晰，句式简洁，规范统一
2. 需求粒度合理，可追踪来源
3. 对开发来说可实现，可验证
4. 标明优先级

大家看看还有什么遗漏的？

Answer 4

产品经理要知道产品的一切细节.甚至比项目经理还要清楚
不过个人感觉 这个词语已经被糟蹋了

Answer 5

1. 相关产品的重度用户
2. 能够明确定义产品的核心功能
3. 与项目经理和开发工程师沟通合作协作完成产品的能力
4. 组建团队的能力
5. 产品营销能力

Answer 6

亲爱的项目经理，我恨你

项目经理，我恨你，而且我知道你也恨我。我真的不理解，你究竟是做什么的。

你是一个多么独特的角色呀，几乎每个公司都要雇用你这样的人。可在不管大大小小的项目中，你与其说是帮忙，不如说是添乱。我坚信，大部分的项目经理都可以用一个技术首领来替代，我是严肃的，难道一群聪明的人真的需要另外一个人来替他们“管理”项目吗？

下面是7种项目经理让我恼火的事情。

1. 你拿不出任何有用的东西
   我知道这话很刺耳，但这是事实。我打过交道的所有项目经理都没有贡献过任何价值。如果项目上出现了问题和麻烦，你只会催促我们搞定它，给我们压力，可这是我们需要的来自你的支持吗？

2. 你是一个信息黑洞
   你更善于积极跟你的上级管理者交流沟通，而不是跟你管理的团队。结果，重要的项目信息根本存不到你脑子里，只有在一些特殊时期，通常是上线最后期限的前几天，你才会关注。上级管理者和开发人员之间出现了一堵墙，你就是阻挡信息流通的那堵墙。

3. 你把所有人都当成工具对待。
   你把所有程序员都当成可以随意消耗的资源。你告诉他们如何和何时要完成一个功能。你从来不理会我们对项目的想法。你几乎没让我们参加过有上级领导参与的讨论项目计划和实施的会议。如果在这些会议中有程序员参与，大老板们一定会投入更多的资金来让项目成功。

4. 装腔作势，哗众取宠
   你 实施的就是一个SB项目开发方法，靠喷出一些最新的项目管理词汇来让大家认为你很聪明。可我不是一个“瀑布法 vs Scrum vs 敏捷法”的粉丝，它们各有长处，但大部分时候它们都是浪费时间。我真的需要把工作分成小块，放到一个sprint里吗？(顺便说一句，请不要再把 sprint当成时间单元。)为什么我需要每日站会，我早就清楚每个人都在干什么，如果我不知道，那是因为我不需要知道或不想知道。

5. 你召开了太多无用的会议
   这点我都不屑于说。

6. 你独揽所有荣誉，责备全都推给我们
   因为有你人为的一堵墙(第二点中所说)，当项目成功时，你把荣誉和光环全都揽到自己身上。上级领导只能这样做，因为他们不知道实情，他们不知道还有程序员。而当事情不顺利时，你却撇的一干二净，受谴责的总是程序员。

7. 毫无用处的进度监控方法
   你热衷于用Excel创造出SB的进度监控图表，拿到会议上向人们展示你取得的进展——尽管你对此没有做出任何贡献。为什么你要纠缠不休的让程序员填写每日工作报告。我们给你那些SB的进度数字，是因为我们知道你要拿这些数字敷衍他们，让自己脸面好看。

总结得知，大多数是项目经理都是在争取自身的最大利益，并以牺牲周围的所有人为代价。这能怪谁，这个社会的坏风气在鼓励这种行为。也许最好的办法就是完全删掉这个职务角色。

[英文原文：Dear Project Manager, I Hate You ]

转自： http://ourjs.com/detail/525601a20a44ef3c0300000f

Answer 7

江湖上不是流传这样一种说法吗：产品经理像爸爸，程序员呢则比较像妈妈
爸爸只动嘴皮子，被指使干活的却始终是妈妈，妈妈能乐意吗？
所以妈妈有时候忍受不了、偶尔修理下爸爸，这应该很顺其自然、理所应当、可以理解的吧！
刚才玩笑归玩笑，却也揭示了产品经理和程序员由于职位属性不同，常向程序员提需求的产品经理，难免因为某些需求引发一场血雨腥风！

参自网络 侵权必删
产品经理只说不干成为了“双方战争”的直接原因，很多时候很多公司开需求会议，我们会看到这样的场景，产品同事自诩站在用户的角度上，自信分享着自己提出的未经过任何调研的一连串需求，然后开了一下午需求会议，然后却只有产品经理滔滔不绝，需求并没有太征求技术同事的建议。如果再加上后期需求的频繁变动，技术同事辛辛苦苦加班加点刚完成，结果被产品经理以不符合预期标准否了，然后重新做。做好了，产品的功劳，不如预期，运营、技术、测试的锅！

参自网络 侵权必删
给产品经理的几点建议：

（1）产品经理要避免发生上面类似的惨剧，面对程序员用语雷区需要提前了解下（冰山一角）

这么简单的功能，还没完成？
这次感觉很简单啊！
上次那个很难的需求不是都搞定了吗，这次怎么就不行了！
这个需求麻烦改一下，对啦，还有这一个，这一个，都改下吧。
我突然想到一个需求，一定会惊为天人，吸引大量用户，我先提出来，你那边做一下吧。
发现效果还不如原来的，你快点改回去吧。
这都是技术同事的问题！
（2）技术都会欢迎一个更懂技术的产品经理

虽然不会技术也可以做产品经理，但是对于程序员而言，更欢迎能够做有效沟通的、懂得一定技术的产品经理，而不是拍拍脑袋、提需求完全不考虑是否可以实现以及实现难度等问题。如果不太懂技术，那产品经理至少还是需要去了解相关的基础知识，如果懂一点，那就再抽空强化一点。如果连和技术人员正常沟通都有问题的话，基本就离挨揍不远了！

（3）产品经理自身综合素质和能力的提升

现在不乏一些把会会画产品原型图、开个需求会议定义为产品经理，其实对于产品经理而言万里长城第一步。

在产品业务层面，产品经理需要接触整个产品的全流程环节，了解整个业务和行业；在用户层面，产品需求具有心理学、增长黑客、商业策略等相关的知识体系；在技术沟通层面，也许不要求产品经理懂得实现某个功能或者需求的每一行代码，但是相关的技术模型、术语还是要有所了解。优秀到让技术同事都崇拜你，你估计就远离了被挨打的命运了！

（4）提出更加有效、有价值的新需求

很多时候产品和程序员的矛盾，源于需求！所以归根结底，还是要从需求出发！

产品经理提出的新需求，不只是拍拍脑袋想出来的结果，要主动走近用户、和运营、技术、市场等部分做需求联动，共同评估需求的价值，以及评判无效的需求。

产品经理要主动了解用户、怀有同理心，好的需求一定是来自于用户的诉求，但于此同时，产品经理也不只是简单把用户需求转述给技术人员，也需要自己用产品思维和工程师角度去转化为具体、可行、明晰的落地需求。

（5）如果你是女神、萌妹子、高情商的产品经理，条件可酌情放宽处理

如果把项目开发比做赛艇运动，在最前面擂鼓喊号的是产品经理，他不但要每个参与者都使足力气，而且要协调所有的参与者，将他们的力气都往一处使，他还要保证所有人的方向都是一致的，都知道朝哪个方向走，不能出现有人用力不对的地方。虽然这个鸡汤证明了产品经理的确只说话、不怎么干活，但不可忽略产品经理对于一个团队的重要性，不过，这里说的是好的产品经理！
如果以上所述都失效的话，终极必杀技：努力锻炼好身体、提升抗击打能力！

Answer 8

为什么不可以