项目经理如何避免被程序员殴打

首先上一张图，证明这不是一个伪需求。

好吧，虽然上图是P的，但至少可以说明一件事——产品经理们早被程序员在心中揍了百遍。

本指南采用案例演绎法，还原产品经理最容易被揍的Top 5 场景，并予以点评和建议，力保从业人员的人身安全。

产品经理，以下简称为（产品）狗。程序员，以下简称为(程序）猿。

5

功能上线之后就不管了

场景：

（上线前十天）

狗:”猿兄，这个功能惊天地泣鬼神，目测可以提高kpi约15.3倍。我好期待好急 — 能不能再多加一天班，赶出来，让我们早一日登上人生巅峰？”

猿：（心想md我都加了十天班了，不过看你这么急）“行吧狗哥，那我再赶一赶。”

狗：（流泪，比爱心，各种卖萌，眼神充满人间大爱）

（上线后十天）

猿：“狗哥，那个功能上线了有一周了吧，有什么初步数据吗？”

狗：（盯着屏幕，做应付状）“啊小猿啊，我还没来得及跟进呢。没事，再等等，我争取下下周再看一眼。哎，说到这里，我又拍脑袋想到了个功能，可能提高kpi约153倍，你听听哈。。。”

猿：（握紧了双拳）

“

点评：

朝三暮四，有始无终，在哪个领域都不会有什么好下场。且不说这刚上线的功能的命运，会沦落至缺乏优化和维护，最终慢慢烂在土里；但产品经理的credibility和形象，也基本和这个项目一起随风而逝了。

”

正确打开方式：

猿：“狗哥，咱们那个功能昨天上线了，你能…”

狗：（温柔而坚定的打断）“猿，憋说话，我懂。我准备两个daily dashboard，一个看实时流量，一个看kpi。同时，我准备每周五发一个周报，给团队概况高光点。从昨天的数据看来，我们付款的转化率提升了62%，但是尚未统计显著。。。”

猿：（握紧的双拳放松了下来，感觉这班还算没白加）

4

对他人专业领域指手画脚

场景1：

猿：“狗哥，你要的推荐单曲功能我做出来了，你看看符不符合需求。”

狗：（不看猿精心准备的demo，而是找到了github对应的branch）“哎呀，你这里的SVM怎么用的是fisher kernal了？我觉得用polynomial kernal可能会提升0.00000001%的accuracy吧，毕竟后者会考虑feature combination。哈哈你不要惊讶，我在Coursera上了机器学习（的第一节课），还算是比较懂吧。。。”

猿：（握紧了双拳）

(更加糟糕的) 场景2：

猿：“狗哥，你要的推荐单曲功能我做出来了，但是私人FM的需求很难实现。”

狗：“怎么就很难实现了呢？”

猿：“因为on-demand的learning需要有比较好的data pipeline，我们的架构尚不能支持。”

狗：（用蔡依林《骑士精神》般的口吻）：“我不听，我不听。为什么网易能做出来呢？为什么虾米能做出来呢？为什么豆瓣能做出来呢？”

猿：“因为他们是网易，虾米，豆瓣啊。他们的计算力和训练数据集的质量都比我们高太多，具体的例子有。。。”

狗：“不听不听，王八念经。我三舅家表姑的二闺女她邻居家的小儿子找了五个蓝翔毕业生就做出了个唱吧的山寨版，就可以实时推送推荐歌曲，你为啥就不行呢？？？”

猿：（握紧了双拳）

“

点评：

如果你看完了上面的两个例子还不能体会到那揪心的蛋疼，请想象以下画面。

你司客服小王对你说：“狗哥，你这个需求的市场分析太粗糙。当年我旁听过我们镇卫生学院的管理学课程，怎么也要用上swot，波特五力，PEST，波士顿矩阵，统统来一遍，才算是入门啊。”

你司销售老陈对你说：“狗，你这个设计，没有采用到实现最流行的tieba style啊，而且颜色上不够本土化，不够红，不够艳，我和我老婆肯定不喜欢，所以谁会喜欢呢？”

如果你也感到了蛋疼，请记住，闻道有先后，术业有专攻。请站在你的专业角度上陈述你的观点和诉求，而不是提出半吊子的解决方案 — 即使你在他人的领域中还算有点水平。这是交流与信任的根基。

另外，如果你p都不懂，请你先虚心学习，而不是问一些令对话无法进行的蠢问题。

”

正确打开方式：

猿：“狗哥，你要的推荐单曲功能我做出来了，你看看符不符合需求。”

狗：（仔细过一遍demo）“恩，很不错，这个上线没问题了。当然我也有一点担心，比方说，我们训练数据集比较小，而且未来半年都会如此，这种情况下我们如何能让模型变得更加robust？此外，我注意到我们没有私人fm的功能。这是一个非常重要的功能，比方说，网易这个功能的日活基本占到了总日活的70%以上。我们的困难是什么？能不能先hack出一个简易版本来，试试效果？”

猿：（开始了建设性的思考）

3

不说人话

场景：

（在一个表现不佳的产品审核会议上，整个团队与高管坐在一起。）

狗：“我们这个鉴黄引擎，采用了世界领先的数据可视化技术，辅以高性能网站开发框架，给我们的客户提供了企业级saas般的鉴黄体验。。。我们的产品获得了数百个五星评价，好评率高达95%！ ”

猿：（会后跟别的组的外猿说）：“其实tmd就是个d3.js + django草草搭建起来的webapp，后端做了点简单的图像识别的东西，基本还是基于相似度的。那一百个好评，九十五个是我留的，好气。。。”（同时握紧了双拳）

“

点评：

请记住，如果你在一家还不错的公司，那么你周围的人很可能都不是傻子。特别是程序员们，IQ比你高的大有人在。这意味以下几件事：

你的装X，他们懂。

你的傻X，他们也懂。

不说人话，不是装X，便是傻X。

说人话，是一种对前线奋战的人最大的尊重。

产品经理是一个对沟通能力要求很高的职位。沟通能力说到底，就是说人话，说别人能听懂的话，说别人听了心中有回响的话。

”

正确打开方式：

（仍然是同一个会议）

狗：“针对我们平台上日趋严重的违规图片问题，我们团队临时立项，力图用简单的机器学习来帮助客户降低abuse。我们的时间有限，尽管团队加班加点，但目前这个产品还没有被主流客户所接受。但是少数愿意试用客户给出了正面的评价。我们希望管理层能支持这个项目，这会是用户体验的一个巨大提升。

猿：（会后跟别的组的外猿说）“唉。狗也不容易。”

2

需求留白，细节死扣

场景：

猿：“狗哥，你上次说的这个邀请注册项目，我还是不太明白几个需求。比方说，邀请成功后，奖励细则是什么；比方说，如果邀请已经存在的用户，会发生什么。。。”

狗：“猿兄，没事的，你看着做就可以，我相信你哟！”

猿：（妈的这不是你的工作吗。。。）

（数周后产品交付）

狗：“猿啊，你做的有问题啊。你看，这个按钮怎么能是蓝的，我听说绿的转化率最好，改一下吧；还有这个图，左边在缩进五个像素吧；对了，你这个标语里的“地”要改成“得”吧。。。”

猿：（握紧了双拳）

“

点评：

需求留白，证明了专业能力或职业素养的底下。该想的东西想不清楚、不去想，而把责任推给他人。

细节死扣，证明了对优先级毫无敏感度，搞不清什么是核心问题。同时，也给了程序员一种micro-manage、缺乏信任的感觉。久而久之，程序员懒得再当产品的主人翁（owner） — 反正产品经理喜欢死扣，他们说啥就是啥吧。

”

正确打开方式：

猿：“狗哥，你上次说的这个邀请注册项目，我还是不太明白几个需求。”

狗：“猿兄，我昨天写了个需求文档。对于比较常见的逻辑，我只把框架和page flow定义了下，一些实现上的细节你可以做决定，有什么问题我们讨论。对了一些比较复杂的情况，我写的比较细，你看下合不合理。”

猿：（艾玛，这可省了我老鼻子劲了，终于可以全心研究设计和构架了：D）

1

改需求

场景：

狗：“猿兄，能不能改个需求？”

猿：（警觉地）“改什么？为什么？”

狗：“哦哦，我们就不做短视频网站了，改做直播平台吧。原因吗。。。原来我看猫嗅网说短视频网站是未来趋势，最近看到72氪写直播平台将是未来增长点。哎呀，反正都是stream吗，应该不难改的。”

猿：（拳头握的咔咔作响。之后请参照文章开头图片）

“

点评：

改需求是一个已经烂掉的梗。

有时候，那是一种不得已：技术障碍，队员离职，公司变动，市场变天，政治斗争，其他部门不支持，被dependency莫名block，老板催工，投资人要讲故事，等等近百个合理原因。

以上所有原因加起来大约占到改需求原因的10%。

剩下来90%，基本就是产品经理拍脑袋没拍好。在立项之前：

敢不敢好好调研下市场？敢不敢看看历史数据？敢不敢问问老员工的反馈？敢不敢做一个impact sizing？敢不敢做一下engineering scoping？敢不敢来个risk & contigency？敢不敢……

当产品经理想改需求的时候，只要能自圆其说，以理服人，那就不算是一个错误，而是一个intelligent risk。这样的要求，算不算太高。

佛说：产品经理一生可以改的需求是有限的。每改一个需求，职业生涯变向尽头迈去一步。

马云说：不要流泪，坏人会笑；别改需求，小命会掉。

”

正确打开方式：

狗：“猿兄，能不能改个需求？我们还是转做直播吧。尽管我去年看过，短视频站点日活远超普通视频网站，近来随着智能手机的普及和内容制作的草根化，直播行业异军突起，并拥有数倍于行业标准的LTV和广告收入。这是我的失误，没有料到硬件和网络市场的变化如此之快，也忽视了95后的很多用户特征。我思考了很久，咱们还是要向着未来做产品啊。为了避免这种失误再发生，并最大程度的运用我们现有的stack，这是我的方案。。。”

猿：（算天算地，算不到命。互联网这一行，少有先知，有的只是幸运者吧。咬咬牙，再来吧）