项目经理就是：

——被团队成员讨厌的人：既不给团队成员发钱也不能决定团队成员的升迁，还让大家干活的人！

——被职能经理讨厌的人：给各部门经理（职能经理）添麻烦的人！！

——被老板们讨厌的人：见面就是进度滞后了、成本超支了、质量出问题了、客户不满了——从未带来好消息！！！

——郭致星

不被待见的人—项目经理—拒绝被喷！屌丝项目经理的逆袭

今天又被研发同学说（pen）了！

什么？你被交互设计师说（pen）了？！

这都什么世道啊？！天天被说（pen）！—某产品经理内心OS。

几家欢喜几家愁，做项目经理不被喷真的是太不正常了！真的是这样吗？以前大家都说，人人都是产品经理，又真的是这样吗？

拒绝被喷！屌丝项目经理的逆袭

一、被研发同学抱怨

 抱怨之来源：

①需求文档缺少细节；

需求文档写的不清楚，缺少流程图，缺少临界条件，缺少一切可能缺少的东西，你说研发同学怎能不抱怨呢？如果中枪了，回去先补全吧。

②大量的需求变更；

这个应该是研发同学最痛恨的了，写过的代码需要大量的调整，自己需要投入更多精力去补充，还有可能对项目周期有很大的影响，真是无奈至极。前期尽可能的想清楚，不要赶鸭子上架。

③不明确的需求；

有的项目经理在拿着“需求”去和研发同学交流的时候，自己都似乎讲不清楚，这其中的为什么，怎么做，什么时候做，都是大大的问号。所以在每次交流之前，对自己没有把握的方面自己前期先做一些功课，让研发同学听明白你的意图和初衷，很多问题都迎刃而解。

④努力实现的功能被很快推翻；

研发同学使了好大的劲才实现出来的功能，结果一下子就下线了，这真是情何以堪啊？别的不说了，找找源头，看看问题出在了哪里吧。

⑤沟通方式欠妥；

“这个功能很简单，做一下吧！”某项目经理的一句经典的台词有可能让研发同学陷入几天的加班。这怎么能不郁闷呢。注意沟通方式，给足研发同学尊重和信任，他们会给你一个不一样的答案。

二、被交互同学抱怨

 抱怨之来源：

①随意更改交互原型；

因为项目经理角色特殊的关系，在信息承接的过程中，难免会出现信息不同步的情况，也就是说有可能由于实现的问题而导致修改了产品交互原型而没有与交互设计师一起商榷，而是单方面的修改交互原型后通知交互设计师，导致的结果就是交互设计师内心觉得受到了不重视，甚至是觉得自己是输出工具。

这种情况是由于前期沟通不畅导致，没有一个“事前”的概念，交互设计师在易用性方面是非常专业的，所以在有任何修改和调整的情况下，与交互设计师进行商榷，这样保证了最后实现的产品与原型的一致性，也保证做出的产品是最专业的，几全齐美。

②专业的事交给专人来做；

其实在创业型团队中，是没有专门的交互设计师岗位的，产品原型都是由产品经理自己完成。所以这个原因也导致了工作的重叠区域，大公司，例如BAT，是一定有交互设计师岗位的，而这个时候产品经理自己也仍然会画产品原型，往往这个度没有把握好，就会产生一些问题。其实项目经理画线框图用来沟通，表达项目经理的想法，再深入的就交给交互设计师吧，他们更专业，所以该放手的就放手，互相配合才能出好产品。

被视觉同学抱怨

抱怨之来源：

①指点江山；

这是最著名的一个案例了，项目经理站在视觉设计师身后，拖着眼镜说：“这个button往右移动一个像素，边框加大一个像素，颜色加深一点，加上高光效果，输出一个JPG给我放手机上看一下。”这画面简直是真的不能再简直了。沟通注意方式，表达意见注意深度，不要试图挑战某个领域专业的人才，给足视觉设计师足够的信任和发挥的空间，这是小P一贯的风格。很多时候“指点江山”会给对方造成一定的心里压力，往往会导致对方很难产生主人翁的态度，这点其实是一个很难根除的后遗症，所以用最好的方式表达自己的建议或者意见，时刻抱着信任对方的态度，借助视觉设计师的力量去把产品描绘的更加美丽，这才是项目经理应该的所作所为。

三、被测试同学抱怨

 抱怨之来源：

①需求文档缺少细节；

为什么这里也有这点呢？因为测试同学要根据项目经理的需求文档写测试用例呀！“这里点击后跳转到哪里？”、“当前若网络异常/弱网络给用户返回什么提示语？”、“查看这里需要登录吗？”、“用户名允许用户输入多少个字符？”、“这里是否需要默认的背景图？”、“需求文档更新了吗？/需求文档更新到SVN上了吗？”

说白了就是依据，测试同学是为产品的质量把关，那么衡量质量需要一个标准和阀值，所以需求文档就是制定标准的依据。这里不需要我多说了，事无巨细的写清楚需求文档吧。

四、被运营同学抱怨

 抱怨之来源：

①关注表面；

由于某些原因，产品经理给运营同学传递的信息就只剩下：这个按钮的颜色对不对、这个Banner和整体的协调性如何，整体布局如何等，这个轮播图不好看，这些展示层面的问题。至于用户使用时长、留存率、UV等等指标与我无关的态势。

其实这里是一个美丽的误会，项目经理关注展示层的问题这是天经地义的，因为展示层的问题多少与产品的易用性有着千丝万缕的关系。可是项目经理也绝对是关注数据指标的，因为这些数据反映了产品健康与否，还有哪些不足和需要改进的方面。问题还是出在信息不对称，项目经理应该本着运营的思路去处理运营方面的问题，孩子的爹和娘都同样重要。

五、被用户抱怨

 抱怨之来源：

这里只能呵呵了，原因千种万种，也千奇百怪，但是，注意这里我又要说但是了，项目经理是产品的第一责任人，不管用户如何抱怨，这都是我们的问题，我们都应该好好的分析其中的原因，找到问题所在并将它解决。

这里的方法有很多，如果可能，你可以和用户直接沟通，面对面/QQ/电话，可以用上的方法都可以尝试。分类也是一个不错的方法，将提出类似问题的用户进行汇总，找到问题定量与定性的转换关系，发现问题，汇总问题。还有经常去论坛/App store的评论中去看看端倪，或许有不一样的收获。

六、被老板抱怨

 抱怨之来源：

这里其实我要恭喜你，因为你所处的位置要么是产品线的负责人，要么是产品团队的负责人，位置关键，可以与老板面对面交流。

①进度太慢

本来不想说，说多了都是泪。项目经理当项目经理用，臣妾做不到啊！我还是给您端茶倒水吧！

进度也是考量项目经理协调能力的一个指标，该推动的推动，该制定里程碑的制定里程碑，节点定好，按时监控。

②体验太差

我真的尽力了！用户体验是仁者见仁智者见智的一种感官感受，很难用标准去衡量，这里的赶潮流走时尚很多都是不得已而为之，说拟物化就拟物化，说扁平化就扁平化。这可如何是好？

给出的产品方案，不管是功能、交互、视觉，都是经过竞品分析的缜密思考的，采用了某个方案必然有其中的原因，与老板深入沟通，同步信息。

③与目标偏离

迭代计划与产品实现出的样子存在差异，往往不是老板心目中所想。这里其实存在一个度的关系，在实际操作产品的时候一定存在一些取舍，而这些取舍往往就造成了偏差。

这里其实没有特别好的办法，需要和老板不定期的review项目计划，报备产品进度和产品问题，看看是否会有一些效果。

④战略调整

这点就有点难控制了，因为战略的调整可能触发了产品方向的变化，进而导致了一些转变，项目经理需要有快速适应和转的能力，不要等老板说出来才去做，很多事你都是可以预见的，提前一点转变，效果事半功倍。还有尽可能的参与到某些你可以参与进去的环节，收集更多的情报，做足功课吧。

我不完全的列出了可能被抱怨（pen）的原因和处理办法，其实不难发现这其中也是有着某种关系的。之前提过项目经理最重要的几项能力的其中之一，影响力：沟通、协调、执行、决策（你可以试着回复能力二字查看这篇文章），占着很大的比例，所以，修炼好内功，才可蜕变逆袭，一起加油吧。