运维比研发更适合转产品岗「随笔」

更适合转产品岗「随笔」"/>

运维比研发更适合转产品岗「随笔」

  0

前言

这是篇半天随笔凑成的散记，是给运维兄弟们自嗨用的，研发兄弟们也就看着玩，我的研发水平也就比运维好点，不值得研发大佬们喷。

• 你们要是真火气大了，我再写个《做研发的比搞金融的更适合当“渣男”》对冲一下气氛。

我在《甲方如何跳槽到云厂商》中，我明确反对工程师冒险转岗做产品。本文和该观点并不冲突，更多是从转岗做产品这件事来玩味对比，研发和运维不同的人群画像和工作方法论。

通篇的调侃轻聊后也有硬核干货，就在第6章节，从产品侧看研发和运维技能复用的可行性。

01

优才转岗产品经理

本文所谈的toB产品经理岗位，指的是“有决策权、有KPI、待遇比技术员更高”的产品经理；并不是“主要技能画原型，工资奇低舔研发”的产品文档助理，也不是雷军周鸿祎张小龙这类产品老板。

我在《如何识别toB产品经理》中对产品经理的主要技能和转岗来源都做过描述。

• 技术高手转岗，可以根据支撑性技术和环境变动去推演产品发展的可行性。

• 售前销售高手转岗，可以冷静的分析归纳客户环境续期和友商的差异竞争力。

• 项目管理和资源运营高手转岗，知道后端团队的真实效率，了解资源的真实成本和周期。

技术高手转产品经理岗都容易理解，而且我认识很多运维高手都做好了售前、销售、资源运营和项目管理的工作。

• 运维不光是装系统和换硬盘，我说的运维高手包括交付工程师、网络工程师、DBA、存储工程师等广义运维工作。

• 产品经理不光是给研发提需求，也包括产品包装、实施推进、成本利润等工作，所以一些“单一产品专用售前”“产品线运营”等岗位其实也是产品经理工作；对一些成熟到功能雷同的产品，这些工作才是最重要的产品工作。

02

能力上限的区别

运维和研发群体以后，我们会发现这两类工种的能力分布完全不同，研发的上限高但下限极低，而运维的上限不高下限不低。

顶尖研发高手能推动大IT行业发展，他们能写出售价过亿的代码。但顶级运维高手的技术上限就低很多了，做优秀的DevOPS平台和运维管理体系很重要，但肯定没做核心软硬件挣钱多。

运维的能力下限比研发高得多，萌新运维闹两次故障就要滚蛋，而且会牵连整个运维团队；而且运维没能力抵抗硬件迭代周期，随着越来越严重的安全问题，运维也不敢在软件升级上保守和敷衍了。

研发的智商下限极低，有一批老脸研发技术落伍陈腐，两年的工作经验被快乐复用了十几年，我们至今能找到基于SunJDK而且还在迭代的软件；而萌新研发可以依赖框架、依赖codereview和甩锅给测试。

03

转岗收益的区别

前文聊了能力的上限，我们就可以看到转岗的收益差距。

研发高手从个人收益上，没必要转岗做产品经理：

• 高手研发很容易年薪百万，后续跳槽也很容翻倍翻倍再翻倍。

•  因为技能艰难和标准孤僻，大家都挺尊重研发高手的。

• 研发高手有能力写出价值上亿的代码，自己创业开公司一样能过产品经理的瘾。

• 雷军周鸿祎张小龙三位产品大佬都是顶级研发高手，那时候运维岗还没从研发体系中分离出来。

运维高手的技术天花板偏低，从技术线转产品岗是有利可图的。

• 运维技术难点甚至不在技术，而在取舍和责任；所有月薪过3万的运维，都是靠管理和背锅的KPI挣钱的，纯靠运维技术想年薪百万是做梦。

• 大家都不尊重总出故障的运维高手，哪怕这个高手是在鸡蛋上跳舞勉力维持；大家也总遗忘平台稳定的运维高手，被遗忘之后就是被冷落。

• 精英研发总监升CTO算个水到渠成的日常规划；而运维总监想升技术VP，需要兼管几个冷门研发团队攒两年信心。

普通研发和普通运维，就别盘算转岗收益了；你们在技术团队都混不好，改行做产品挣钱更少挨骂更多……。

04

工作思路的不同

研发工程师是直面产品经理要求，只为代码质量负责，不为业务效果负责。

• 研发收到的是碎片化行为需求，高级研发的需求还是个软件目标，比如“要求幂等接口”“要求误判率降低5%”；普通研发的需求琐碎到一个测试用例甚至一次调整数据。研发多数时候连业务结果是什么都不知道，时间久了就更不关心了。

而运维的工作思路和toB产品设计非常相似。

• 运维收到的是强业务关联业务目标需求，比如“春晚红包不出故障”“压缩成本20%”，这和产品经理的工作逻辑是类似的。

• 成功的研发能直面KO问题，但运维没有操刀软硬件的能力，所以成功的运维要绕过和避开问题；产品经理的很多“障眼法”“引导法”“拖延法”也是在绕过和避开问题。

• 资深运维依赖但不信任研发工程师，研发只对稳定性故障承担次要责任。资深产品也是一样的工作思路，资深产品经理也经常要给技术线做功能到工期的各种容错。

最后再补一刀，一个研发如果学习运维和产品的工作方式，他很快会被研发团队排斥成边缘角色。

05

沟通渠道的多寡

运维打交道的部门很多，能帮干活能骂运维的部门都很多，这些部门大都同样和toB产品经理打交道。

• toB产品设计时，资源成本是个重要参考因素，而运维同样要和采购打交道。

• 大部分运维要负责自家公司的实施工作，为保障工期要和一大堆内外部角色打交道；toB产品设计和实施，都要重度考虑交付周期。

• 为平台故障能砍死运维的公司同事，为产品竞争力能掐死产品经理的公司同事，其实是同一类人：被耽误挣钱的是流量和销售部门，被客户痛骂的是售前售后部门，被耽误伟大理想的是总裁办。

研发的工作界面，70%归了产品，25%被运维承包，几乎不和其他部门打交道，也很难出现漏过测试也无法回滚的Bug。

研发工程师转产品岗位，会突然发现公司居然有这么多部门；而运维转产品，嘿嘿，都是老熟人，约会议室都不用挪地儿。

06

专业技能在产品设计时的复用

前几段都是聊研发运维的工作习惯不同，但这一段是从产品经理的角度看的技能复用心得。

在toB产品设计工作中，运维技能是能频繁复用的，但研发技能很难复用。

• 前文说过“技术高手根据支撑性技术的变动去逐级推演产品发展的可行性”，理论上研发高手比运维高手更早嗅到风向变化。但是由核心软件技能推进的产品演化频度极低，一个细分领域要几年几十年才碰到一次技术爆炸，而且看透看破一次技术爆炸就够一堆人吃好几年产品设计的老本。

  • 比如中本聪发明的分布式账本技术，比如CRUSH算法成就了Ceph存储，这个领域的大部分产品经理是研发还是运维出身，技能上的区别就不大。

  • 大量新硬件、新网络、新操作系统、新服务软件、新架构模式出现以后，无论前运维还是前研发，只要是融会贯通的真高手，其拥抱接收信息和整理推导进化的区别不大。

• 在IaaS和PaaS云产品做设计时，产品依赖的算力、存储、IO资源的属性，以及这些资源的交付周期和可靠性，都是高阶运维的必修技能。

• 在岗资深研发不会听外脑——特别是产品经理的技术工作建议；但是在岗运维和转岗运维的方法论差距不大，彼此还能聊得来。

• 产品经理和后端团队打交道都会遇到推脱和疑虑，前运维高手因为思路灵活更容易绕过问题，但前研发高手容易陷入共情之中而自闭宕机。

• 前运维转产品经理的时候，因为缺乏编程基础都有点害怕API和SDK，但这是个14天就能戳破的纸老虎。

  • API和SDK只是个属于用户友好界面设计而已，“产品友好性”并不是云产品的核心竞争力。

  • API和SDK友好的标准是要兼容初阶开发者，高智商产品经理脱产学习两周Python或Golang，恰好就是初阶开发者的理解能力。 

上述描述猛看也有些例外，但这些例外经过二次深层解析后，就是从另一个角度验证我前文的逻辑闭环准确辑。

• 大数据研发可以很顺畅的转大数据产品经理，因为我们经常分不清大数据“是产品还是项目”。

• 几无借鉴前提的创新软件研发，也可以很顺畅的转产品经理，此时的产品就是主程序员的个人意志延伸。

07

结束语：运维工作的魅力

我有时候挺烦运维工作的，觉得这是个上限低烂事多的工作。

但是运维的工作方法和岗位职责，给我们这些“缺乏成为顶尖高手资质”的IT男，保住了一个不算低的下限，还保留了很多灵活的出路。

从宏观角度看世界，到处都是公平到微妙的规则。

运维兄弟们，这个岗位的每一份繁杂和坚辛背后，除了汗水更有宝藏，各位兄弟好好挖掘，好好把握。