没有什么高大上的理论，都是一些教训。

编者按：本文来自微信公众号“InfoQ”（ID：nfoqchina），作者：廖雪梅，编辑：小智；36氪经授权转载

互联网 + 时代，技术管理者身边充斥这样的声音：后端研发跟你抱怨技术挑战小，没有成长空间；前端小伙伴跟你吐槽做了太多管理系统，想玩各类新技术 RN、酷炫的动画都找不到试验田；业务还会不断告诉你，xx 系统的设计方案完全不符合线下场景……作为技术管理者，怎么样趟过这些坑？本文整理自 QCon 2018 北京站上的演讲，原标题《强业务驱动的互联网+时代，技术管理的坑与路》。

1、写在前面

作为一名工作 10 年的码农，见证过像百度搜索、地图等流量分发时代，也正在经历以互联网驱动传统行业改造的互联网 + 时代，比如外卖就是被互联网改造的送餐行业。这两个不同的时代会有哪些差异，给技术管理会带来哪些挑战？想给大家分享自己这几年的一些心得体会。

2、流量分发与互联网 + 的差异性

对于大多数码农来说，互联网 + 都是一个新事物，我们很多人也都是从做传统互联网（比如流量分发、基础架构等）走过来，我自己总结流量分发产品与互联网 + 从产品、技术、管理的主要差异如下：

总体来说，流量分发时代产品精细化，比较容易用技术建立壁垒，技术的话语权也更大，从而技术管理更纯粹一些，围绕技术去做。

而在互联网 + 时代，突然发现世界似乎变了：产品逐渐做闭环，越来越重；不再只是精细关注每个环节的转化率，而是去关注整体。比如一个仓储管理系统，页面加载耗时不再是什么指标，而是宏观去看整个仓库货物周转效率。

你会感觉技术的纯度在下降，曾经引以为豪的高并发、性能优化似乎没有了用武之地，而业务又是全新和未知的。作为一个技术 leader，你从流量分发时代走过来，身上带着深深的技术烙印，在互联网 + 时代你和你的团队可能会经历哪些坑？又可能有哪些突破之路呢？

3、互联网 + 时代，技术管理的坑与路

接下来分享自己的一些体会，没有什么高大上的理论，都是一些教训。

3.1 需求越来越难以理解，还 PK 不动

互联网 + 由于你做的是自己之前不熟悉的行业，一方面专业术语明显增多，比如你的结算产品会跟你说我们做的是个“代收代付”业务，新零售产品会给你讲“挂单”、“废弃”……一堆完全摸不着头脑的名词。

除了这些专有名词，每个行业的运转模式对于一个新人来说，有很大的理解难度，需求 PK 也会变得很艰难。

比如我曾经就面临一个很艰难的需求 PK。大家都知道，对于外卖来说，营销是非常重要，特别是在 2015 年左右时期的外卖来说。当时在 PC 上已经有一个非常复杂的营销系统，业务不断提出希望将营销系统搬到销售移动端。这个工作量巨大，预估需要做 2 个月。

最开始我一直不同意做，坚持投入产出比不划算之类。后来通过跟随 BD（线下销售人员）走访商圈才知道，BD 都没有工位，他们天然就是移动办公，每天在商圈里来回穿梭。每天拜访不同的商户，而商户的环境很嘈杂，有的是在地下室信号极差，在 PC 上配营销基本是不可能。BD 没办法只能先用小本本记下来，晚上回家统一处理，效率很低。而在竞争极其激烈的时候，活动晚上线半天对商户单量影响就会非常大。通过这次商圈的实地考察，我才意识到移动端配置营销对于 BD 如此重要，这是行业的运转方式决定。于是我们马上调配人力快速支持上线。

这样的需求 PK 经历很多，慢慢我总结出来互联网 + 模式下理解需求的一些心得：

3.2 项目越来越没节奏了

在互联网 + 不只你是新人，可能你的业务也是新人，或者即使你的业务是老司机，在线下激烈的竞争之下，也经常会出现一边打仗一边调整的情况。那么作为下游的研发同学，感受到的就是需求节奏感很差，插入性需求很多，琐碎的需求也在增加。那伴随而来的就是总是事多人少，晕头转向。

比如我曾经就碰到需求池里躺了 80 个需求，却只有 3 个研发这样悲催的情况。第一反应肯定是人不够，赶紧拼命招人，于是就白天面试，晚上写代码，最多的时候看自己的日历里有 8 个面试（当然我是三面）。结果一个月之后，人是没招到几个，项目 delay 问题反而更严重了。

这时候自己意识到全力以赴招人短期是解决不了问题的，还是得老老实实做项目管理，主要通过 2 个方面来做，对外建立信任，对内梳理项目流程，如下：

通过对内对外的一系列管理，最后不但项目节奏慢慢起来了，跟业务的信任感也更强了，逐渐进入一个良性运转。这个事件给自己的思考是：

3.3 越来越没成就感了

在互联网 + 时代，大家会抱怨做的事情越来越没有技术挑战了。后端会天天叹息，用户量也就几千个，哪有什么高并发，哪有什么性能瓶颈？做的工作大多都是数据库表的增删改查，if-else 的业务逻辑；前端也吐槽，大多是内部系统，大同小异。想玩酷炫的新技术，但是产品只关注实用性。甚至想用 nodejs 找个试验田都难，后端逻辑太重；测试更加是哀怨不断，每天在功能测试的漩涡里无法自拔，心心念的自动化测试还没搭好框架，业务逻辑又变了……

更有小伙伴跟你吐槽，我花了那么多时间做业务逻辑值得吗？做结算的花了很多时间理解出账、入账、分账，等哪一天不做结算了，这些同学还有价值吗？还不如我去做一个 MQ 服务，换一个业务还是可以用得到？我们的行业经验有多少是可以迁移的呢？

这几年这些吐槽和迷茫一直围绕着我，对于成就感问题的解决我是这么思考的：

我认为首先要解决到底有没有技术挑战的问题，然后才是团队氛围建设问题。

互联网 + 的出现除了资本推动之外，很重要的一个因素恰恰是技术本身。比如移动支付、定位、导航等基础应用的服务已经非常成熟，连码农用的各类组件，比如 MQ、redis 等都已经经历过很多历练，你可能再也不需要从头去搭建一个缓存系统了。我理解就是现在做技术开发的基本组件越来越丰富，越来越强大了。就像盖房子一样，你的砖头比几年前已经强大很多，沙子的性能也强大了，原材料升级了，那盖房子就没有挑战了吗？

4、互联网 + 技术的挑战与价值

肯定不是的，我认为互联网 + 互的技术挑战主要来自这几个方面：

4.1 互联网 + 技术的挑战来自技术的复用应用。

拿一个可能每天只有几千 PV 的仓储系统来说，真的没有技术挑战吗？子系统就有商户、订单、库存等，子系统如何合理解耦，如何做到高可用；业务逻辑还有权限、日志、异步导出等，每一个要做精细，有非常多的讲究；另外互联网 + 的业务是在不断摸索迭代中，那高度的扩展性就是一个很大的挑战。你可以看到一个系统到底有没有技术挑战，跟纯 PV 大小关系不大，主要看业务是不是复杂。只要业务足够复杂，一定会带来很多技术挑战。

再比如解决一个外卖商户超时不接单就容易吗？首先你得分析商户为啥不接单，可能消息丢失没达到，你需要提升消息达到率，比如使用长连接等技术；也可能端上没有收到推送，那需要思考端上什么时候会丢消息？Android 处于后台时候推送可能就收不到，那端上如何保活，在被杀死的时候如何唤起？甚至商户不接单可能因为播放声音没有听到，那播放策略怎么定，如果被其他进程打断了，播放怎么继续等等……你会发现一个场景的问题，会牵扯出一堆需要技术上不断打磨的地方。所以我理解互联网 + 的技术挑战来自技术的复合应用。

4.2 互联网 + 技术的挑战来自用技术解放生产力。

前面说过互联网 + 产品更关注闭环，因此这时候整体的效率是极其重要的。如何通过技术去提升开发效率，去解决日常工作中的重复劳动就日趋重要了。比如前端如果真的是页面相似度很高，那是否可以开发日常通用组件库，甚至做一些基础的模板，能快速搭建一个页面出来；每天都有商户上报来单不响，跟商户沟通问题复现极其繁琐。如果能通过全链路日志上报，搭建一个完善的分析平台，问题定位就能快速很多。这些都是很多技术去改变效率的事情，大家在平时的工作中多去发现，一定可以找到很多点去做。

4.3 互联网 + 技术的价值一定很大程度来自业务。

前文一直在说互联网 + 业务很重，那么技术的价值感一定是逃不开业务的。做一个几千 DAU 的销售 APP 在办公室里可能感受不到成就感，但是你跟随 BD 去走访商圈，看到你做的产品对线下有多大的影响，一定会有很大的冲击感。这种价值感是在无法办公室里 YY 出来的。所以一定要真实地去观察和体验你做的产品。

另外业务的特殊性也会给你带来很多附加的价值，比如很多人就说 DBA 圈内支付宝的 DBA 特别贵，不是说支付宝 DBA 技术能力一定比别人强多少，更多是他们围绕支付宝之类银行金融标准做了很多细致的工作，这个本事就是非常有价值的事情。

说了这么多技术的价值感问题，再简单说说团队氛围建设方面。氛围和文化一定是围绕你当前的工作服务的，不得不说互联网 + 绝不是一个只要你掌控流量中心，就能躺着挣钱的时代了，它是一个非常辛苦的活。那么对于互联网 + 技术团队的文化和氛围建设应该以务实为主，比如你要夸一个人技术牛，不是因为他用了什么新技术，而是因为他用技术解决一个业务痛点，这两种导向差异性是很大的；你的团队技术分享也不能是天马行空地天天讨论最新的技术，而是讨论谁解决一个问题的实际经验，这个经验可以怎么抽象复制解决一类问题。即使是新技术的讨论，也要向前一步，讨论这些新技术在当前的情况下能用到什么地方……一句话总结，整体的团队文化和氛围一定要打破盲目的技术崇拜，而是实打实地解决实际问题，看起来很不性感是不是，但是在互联网 + 时代是非常必要的。

OK，啰嗦了这么多，对于互联网 + 时代技术管理的坑与路，我认为就是简单总结为下面这个图：

5、哪些是技术管理永恒不变的？

讲了很多流量互联网 + 时代技术管理与流量分发时期的差异性，讲了如何破局，最后想简单讨论下无论时代怎么变迁，技术管理有哪些是永恒不变的？

交付质量，也就是你团队的项目质量，线上服务的稳定性，我认为是生命线的东西。从需求、设计开发、测试、上线以及运维，需要花足够的功夫去保证每个环节的质量，保证服务可靠性。你不需要吹你团队用了多少新技术，有多少技术大牛，如果你的产品 bug 很多，线上服务经常故障，那技术 leader 就是不合格的。这是你作为技术管理安身立命的手艺，永远都不能放弃，不能降低要求。

做管理就是做服务。对外服务产品和业务，对内服务团队。是时候放下技术改变一切的妄念了，技术本质是一种工具，就是为产品和业务服务的，让自己和团队价值最大化的方式就是让产品和业务成功。同时码农都有一种傲娇在，作为技术 leader 一方面需要给团队小伙伴与足够的尊重，另一方面用心服务每个人的成长，一定不要让小伙伴成了“需求翻译机”，成了真正的“码农”。

写在最后，如果真的需要总结一下互联网 + 的技术管理，我认为就是 3 个方面：

• 内功：技术、管理

• 行业敬畏心，尊重你做的行业，做任何行业之前先保持一颗谦卑的学习心态。

• 服务心态，对外服务产品和业务，对内服务你的团队。

最后感谢 QCon 给自己这么好的平台，也认识了很多行业大牛，能将自己的一些心得体会跟大家分享交流，希望能给大家带来一些思考。

作者介绍

廖雪梅，百度外卖技术总监。2008 年浙江大学硕士毕业加入百度，将近 10 年的工作经历中，先后在百度 Hi，百度移动搜索、百度凤巢、百度地图等产品从事技术开发工作，2015 年加入百度外卖。对于高效项目管理、团队梯队建设、团队文化与技术氛围建设有自己的思考和较丰富的实践经验。作为一位女性管理者，平时喜欢哲学、心理学，喜欢自己琢磨，相信每个人的潜能，最好的管理就是成就他人的过程。