原载于我的个人公众号。因为是面向大众的,所以用了“产品经理”这个大众更认可的名词。在我厂,可以直接将其对应为“策划”。
以下为正文。
公号“余晟以为”曾写过一篇《IT 的巨流河》,讲传统行业很难理解 IT 的意义和复杂。巨流河暗喻一条难以跨越的鸿沟。
其实在 IT 业内,不同岗位之间的巨流河也一样存在。尤其团队越大、分工越细,河就越宽,就越容易出现“撕逼”。
大家都站定己方立场的“撕”,未必不好。但如果对对方立场背后的原因不理解,就容易造成人身攻击性判断,质疑动机、能力、态度。弄不好,“撕”就会变成“斗”。
我经历过不少“撕”。被诛心过,也诛过别人的心。当自己岗位变换,穿上别人的鞋子,就理解了为什么会被诛,也后悔不该诛别人。
在互联网企业,最大的河就是产品经理、程序员和运营之间的巨流河。这篇文章想试着讲讲这三个岗位都有什么不为另两者理解的苦衷。
我要描述的是处于中流水准的人,也是最大的从业人群。他们的专业能力和态度是可信任的,但也肯定会犯错误。对于顶尖的,很多问题都已不存在。对于垫底的,没必要费口舌。
产品经理最大的恐惧是“不被认可”。
TA 们的想法必须借别人的手才能实现,才能触达用户。这个链条很长,正向反馈很慢,很难迅速获得成就感,更何况,过程中不断遭受质疑。
没有比产品经理更容易被质疑的岗位了。每个人都认为自己是懂产品的,是可以代表用户的,是愿意“热心”贡献想法的,并努力让自己的想法被采纳。但只有产品经理是能看到全貌的,面对最多纠结的,且花最多时间研究、思考的。别人贡献的,往往只是直觉。
直觉不等于不靠谱,甚至有可能超靠谱。但相对于中等水平以上的专业判断而言,不靠谱的直觉居多。
带着光环的产品经理,可以轻易地让直觉党闭嘴。但除了乔布斯、张小龙,我也就听说网易云音乐(现在网易美学)的王诗沐已修炼出神级光环。绝大多数产品经理,都还在痛苦地以说服为生。
如果所有人都是“提出建议,尊重专业”的态度,产品经理能好过得多。TA 可以更大胆地排优先级,更大胆地创意,更大胆地推翻自己(哪怕在上线前夜),更大胆抛弃,甚至更大胆地抄袭。
程序员最大的恐惧是“机械重复”。
很多人以为程序员最怕的是改需求。其实不是。做新需求是工作量,做新项目也是工作量,都不见程序员抵触,怎会唯独抵触改需求的工作量?
改,意味着要在现有的代码上,做各种拆拆解解、修修补补,技术上通常并没有新要求。也就是说,做完后,只涨工作量,不涨经验值。所以,不爱改。
技术经验值不涨,在日新月异的技术行,相当于断送职业未来啊。所以,让程序员由衷开心愿意加班做的事,是对当下的他有技术挑战的事。
技术挑战多种多样,非技术人员很难判断。但有一样是不需要懂技术就能掌握,而很多人又不知道的:描绘未来需求演化的各种可能。并不要求这些可能一定会发生,只要发生的概率较大即可。甚至可以是 n 选 1 的 n 个可能,只要其中之一必然发生。
这就对系统架构、代码架构和数据结构设计都提出了未来扩展的需求。设计得好,未来可以迅速应对可能发生的变化,只需要很少的工作量。而怎么才能“设计得好”,是个很高深的技术,挑战足够大。
题外话:著名产品人纯银(我怀疑他也修炼出神级光环了)最近在公号“产品犬舍”里有篇《程序员怎样鉴定强悍的小团队》,写了产品经理提升研发效率的三件事:控制过度设计、划分清楚优先级和预见性。被称作“老司机专用”的“预见性”,和我说的是一个意思。
运营最大的恐惧是“被工具化”。
被当做执行工具,按照既定的规则重复执行,就是被工具化。当真正的工具开发完成,被工具化的运营就会被替代,所以谁都不愿意做被工具化的事情。
不需要谈“AI 代替客服”这种黑科技,很多非常简单的工具,也会因为各种原因(主要是优先级更多地给予了外部用户)而没有开发,或做得不够好用,令运营只能人肉填坑。这里云课堂运营也经历过很多血泪史,就不写出来自打脸了。
当发现运营的效率低、出错多、效果不好、脾气差时,不妨去体验一下 TA 们使用的工具是怎样的。差的工具,不仅影响效率和效果,而且影响心情,这个才是最致命的。
我们有个程序员 gg,当年运营每当做好一个专题,都要找他传网页和图片到服务器。他终于不堪其“辱”,一怒之下,没用任何产品经理介入,徒手写了个 CMS,从此再也没有运营妹子找他卖萌了,于是单身至今……运营妹子都认为他最有技术范儿了。
实实在在做好后台工具,提升运营效率,是和运营最佳的合作。
本文来自网易实践者社区,由作者孙志岗授权网易云社区发布 。