产品经理、程序员、运营的巨流河

原载于我的个人公众号。因为是面向大众的，所以用了“产品经理”这个大众更认可的名词。在我厂，可以直接将其对应为“策划”。

以下为正文。

公号“余晟以为”曾写过一篇《IT 的巨流河》，讲传统行业很难理解 IT 的意义和复杂。巨流河暗喻一条难以跨越的鸿沟。

其实在 IT 业内，不同岗位之间的巨流河也一样存在。尤其团队越大、分工越细，河就越宽，就越容易出现“撕逼”。

大家都站定己方立场的“撕”，未必不好。但如果对对方立场背后的原因不理解，就容易造成人身攻击性判断，质疑动机、能力、态度。弄不好，“撕”就会变成“斗”。

我经历过不少“撕”。被诛心过，也诛过别人的心。当自己岗位变换，穿上别人的鞋子，就理解了为什么会被诛，也后悔不该诛别人。

在互联网企业，最大的河就是产品经理、程序员和运营之间的巨流河。这篇文章想试着讲讲这三个岗位都有什么不为另两者理解的苦衷。

我要描述的是处于中流水准的人，也是最大的从业人群。他们的专业能力和态度是可信任的，但也肯定会犯错误。对于顶尖的，很多问题都已不存在。对于垫底的，没必要费口舌。

产品经理的苦衷

产品经理最大的恐惧是“不被认可”。

TA 们的想法必须借别人的手才能实现，才能触达用户。这个链条很长，正向反馈很慢，很难迅速获得成就感，更何况，过程中不断遭受质疑。

没有比产品经理更容易被质疑的岗位了。每个人都认为自己是懂产品的，是可以代表用户的，是愿意“热心”贡献想法的，并努力让自己的想法被采纳。但只有产品经理是能看到全貌的，面对最多纠结的，且花最多时间研究、思考的。别人贡献的，往往只是直觉。

直觉不等于不靠谱，甚至有可能超靠谱。但相对于中等水平以上的专业判断而言，不靠谱的直觉居多。

带着光环的产品经理，可以轻易地让直觉党闭嘴。但除了乔布斯、张小龙，我也就听说网易云音乐（现在网易美学）的王诗沐已修炼出神级光环。绝大多数产品经理，都还在痛苦地以说服为生。

如果所有人都是“提出建议，尊重专业”的态度，产品经理能好过得多。TA 可以更大胆地排优先级，更大胆地创意，更大胆地推翻自己（哪怕在上线前夜），更大胆抛弃，甚至更大胆地抄袭。

程序员的苦衷

程序员最大的恐惧是“机械重复”。

很多人以为程序员最怕的是改需求。其实不是。做新需求是工作量，做新项目也是工作量，都不见程序员抵触，怎会唯独抵触改需求的工作量？

改，意味着要在现有的代码上，做各种拆拆解解、修修补补，技术上通常并没有新要求。也就是说，做完后，只涨工作量，不涨经验值。所以，不爱改。

技术经验值不涨，在日新月异的技术行，相当于断送职业未来啊。所以，让程序员由衷开心愿意加班做的事，是对当下的他有技术挑战的事。

技术挑战多种多样，非技术人员很难判断。但有一样是不需要懂技术就能掌握，而很多人又不知道的：描绘未来需求演化的各种可能。并不要求这些可能一定会发生，只要发生的概率较大即可。甚至可以是 n 选 1 的 n 个可能，只要其中之一必然发生。

这就对系统架构、代码架构和数据结构设计都提出了未来扩展的需求。设计得好，未来可以迅速应对可能发生的变化，只需要很少的工作量。而怎么才能“设计得好”，是个很高深的技术，挑战足够大。

题外话：著名产品人纯银（我怀疑他也修炼出神级光环了）最近在公号“产品犬舍”里有篇《程序员怎样鉴定强悍的小团队》，写了产品经理提升研发效率的三件事：控制过度设计、划分清楚优先级和预见性。被称作“老司机专用”的“预见性”，和我说的是一个意思。

运营的苦衷

运营最大的恐惧是“被工具化”。

被当做执行工具，按照既定的规则重复执行，就是被工具化。当真正的工具开发完成，被工具化的运营就会被替代，所以谁都不愿意做被工具化的事情。

不需要谈“AI 代替客服”这种黑科技，很多非常简单的工具，也会因为各种原因（主要是优先级更多地给予了外部用户）而没有开发，或做得不够好用，令运营只能人肉填坑。这里云课堂运营也经历过很多血泪史，就不写出来自打脸了。

当发现运营的效率低、出错多、效果不好、脾气差时，不妨去体验一下 TA 们使用的工具是怎样的。差的工具，不仅影响效率和效果，而且影响心情，这个才是最致命的。

我们有个程序员 gg，当年运营每当做好一个专题，都要找他传网页和图片到服务器。他终于不堪其“辱”，一怒之下，没用任何产品经理介入，徒手写了个 CMS，从此再也没有运营妹子找他卖萌了，于是单身至今……运营妹子都认为他最有技术范儿了。

实实在在做好后台工具，提升运营效率，是和运营最佳的合作。

本文来自网易实践者社区，由作者孙志岗授权网易云社区发布 。