互联网的发展有两种非常典型的产品形态：一种是流量分发，另一种是互联网 +。在流量分发时代，一切以技术为核心；但是现在是互联网 +，技术纯度在下降。而很多技术人都是从流量分发时代走过来，带着深深的技术烙印。饿了么技术总监廖雪梅分享了他做互联网 + 产品时，有哪些不适、遇到哪些挑战。

互联网 + 与技术逆流

我算是互联网行业里较早的一批码农，做过五年技术和五年管理。想和大家分享的是互联网 + 的技术管理。

假设你是技术人员，在你的面前有两个项目让你选择去做，一个是 passport 登录系统，规模十万级；另一个是仓库管理系统。你会怎么去选？

为什么问大家这个问题？因为我一直觉得在码农中是存在一条鄙视链：

• 第一梯队是做 AI 和高并发的；
• 第二梯队是做技术架构和基础服务的；
• 第三梯队是做业务系统的，比如积分兑换系统；最后的梯队是做内部管理系统。

在十年前的互联网，技术人员会削尖脑袋往第一、第二阵营去挤，而现在越来越多的人开始进入第三、第四阵营的开发，各种业务系统慢慢地都在逆袭的过程中，这是为什么？

我回顾了自己十年的工作经历，从技术角度来看，互联网的发展有两种非常典型的产品形态：其中一个是流量分发。

拿百度来说，百度是一个巨无霸的流量中心，很多产品都想从上面去分一杯羹，于是产品设计都是精细化从流量中心攫取更多的流量。这种产品形态下，产品本身很轻，但每一步流量的转化就极其重要，所以需要技术精细化去优化，那是技术为王的时代。

另一个典型的产品形态就是互联网 +，用技术去改造一个个传统行业，产品越做越重，越来越闭环，技术的价值反而不是最重要的了。

在流量分发时代，技术管理相对简单，一切以技术为核心。但是现在的互联网 +，技术纯度是在下降的。而我们很多人都是从流量分发时代走过来，带着深深的技术烙印，当我们再去做互联网 + 产品时会有哪些不适？会遇到哪些挑战？这些就是我想要分享的内容。

互联网 + 的需求变化

做技术管理，所面临的第一个挑战一定是需求上的。

互联网 + 的需求理解会比流量分发时代更难，因为这个行业时先于互联网 + 存在，每个行业都有它比较固定的模式，你会觉得隔行如隔山。比如做新零售的，产品会讲商品废弃、挂单等名词，结算产品会说我们做的是“代收代付”业务，你会一头雾水。

每个行业有每个行业的运行规则，也会给你的项目带来很多不一样的地方。比如，做结算时，研发最痛苦的事就是每个月的对账。有一次，那个月的账怎么对都不明白，从下午查到晚上，每次算出来都差了几块钱。到半夜 12 点时，做对账的小伙伴特别悲催地看着 PM 说，姐，这个钱我自己掏了行吗……结果当然是不行，做财务的每一分钱都需要对得非常清楚。

除了需求理解成本高之外，需求 PK 难度也会增加。由于互联网 + 的强业务导向，在研发尝试与产品 PK 需求的时候，有时候产品也解释不清楚就直接说，线下业务就是这么玩的，那我们就必须这样去做。

再次，需求变化迭代速度比流量分发时代快很多了。对于这个行业，业务同事也可能是新入门，所以经常会是一边打仗一边调整。而且整个市场竞争非常惨烈，巨大的压力之下，业务也会根据竞争形势不断去做调整。

在做外卖产品时，我们每个季度都会做需求规划。每次总结下来后发现，面向商家的需求规划，可能有 40% 或者 50% 会按照计划执行。而面对内部的需求比如管理系统，规划最多只能执行 20%—30%。

总体来说，互联网 + 的需求迭代更快、理解成本更高，研发尝试要做需求 PK 也会更难。

技术团队要对传统行业保持敬畏心

管理无非就是事和人。技术 leader 对事的管理，第一要务一定是需求管理。研发 leader，第一项硬本领也就是能理解需求，能 PK 需求。在流量分发时代，需求理解和 PK 成本相对会低很多。

拿百度地图上做酒店来说，PM 提需求说有些地方要做改版，但是我觉得这么做不靠谱，就会其他竞品的样式给他看，甚至聊聊自己作为用户的一些“感知”（虽然不一定专业，但你至少是用户）。另外，很多需求都可以从数据来分析这么做是否靠谱。如果 PM 一定要上线需求，这时候就可以去预估一个转化率，最后拿数据说话，告诉 PM 这个需求不可行，再下一次，PM 就不会固执己见了。

但在互联网 + 这两个法宝都不行。比如曾经产品同学要求我们把营销工具从 PC 搬到 App 上，这个工作量巨大，当时预估将近 2 个月。你想去 PK 需求，发现曾经的法宝都行不通了——竞对的内部系统拿不到，在这种场景下产品都没上线，更没法用数据说明转化率了。僵持了几天，PK 不下来，PM 说，咱们下去看一看吧。然后我就跟着 PM 去商圈去走了走，结果是我决定去做了，因为跑商圈的时候才知道 PM 提出这种需求的原因。

在外卖行业，BD 是没有工位的，每个月只回公司一次。当 BD 和商户洽谈，达成协议后想让商户配置营销活动。但是那边可能没有 WiFi，4G 信号也不好，BD 没办法只能先记下来晚上回公司再录入。在市场竞争很激烈时，半天的时间对他们来说都很珍贵，半天就可能导致商户流水减少，从而转向竞对。这时候我才知道，将营销工具搬到移动端，是一件多么重要的事情。

不去线下真正看你的用户，不知道他们到底是如何使用你的产品。

再和大家分享另一个事，做外卖有一个最基础的功能是给商户打印小票。那么问题来了，App 适配多少种打印机才合适？我们之前做类似产品都会先去市场调研，哪些机型覆盖到 90% 以上的，把这些机型覆盖全就 OK。我当时也让 PM 去做市场调研，商户打印机的 Top 机型是哪些？他给我找了四五种，我们就适配这主流机型。而后来发现，每天仍然有各种商户打电话投诉，为什么小票打不出来？为什么竞对可以，你们不行？很多商户因为小票打印不出来，直接把 APP 给卸载了。

这时候我才意识到，打印小票对外卖商户来说是核心链上的关键环节，关键链路一定是 100% 甚至 200% 的投入，因为是生命线的东西。从那以后，我们把能做的机型都兼容了，甚至还会定期去收集新的机型，看看还有哪些我们觉得可以兼容的。

这两次经历带来的教训是什么？隔行如隔山，做任何一个行业都需要保持敬畏心。在互联网 + 时代，技术要跟产品平等对话不容易，不了解业务就不可能去平等对话。

互联网 + 的本质究竟是什么？我觉得就是要谦卑地去看清行业，看清技术和经验在这个行业能发挥什么样的价值。

互联网 + 项目如何应对“烂尾楼”

有不少码农都应该做过烂尾楼产品，在互联网 + 这种事情更多。比如做一个代理商绩效管理系统，做了半个月，结果上线两周，业务不用了，因为业务要进行调整。

对于这种烂尾楼产品，我们有一个 MVP 原则，假设你要做一辆车，你应该从滑板车开始做，接着做个自行车，再做个摩托车，最后才去做一辆汽车。

依旧拿代理商绩效系统来说，实现代理商机制目的是什么？为了想要更快速更省钱地扩张。那为什么要给代理商制定那么多规范动作呢？他们不是员工，没必要听你指挥。

在互联网 +，避免烂尾楼最重要的事情是去跟业务达成一个共识：比如想做流程优化，可以先和业务去商圈跑一圈，看这个模式是否 OK，哪些痛点是产品和技术可以解决的，再往下去推行。

烂尾楼产品要避免一定是建立在产品、业务、研发都对这个行业有更深入的理解基础上，在业务发展初期，烂尾楼产品可能就是试验田。

新环境下的项目管理

前面说过，互联网 + 的需求变化多、理解成本高、迭代速度也很快，对于研发 leader 来说，你可能永远面临事多人少的困境。除了深入了解行业，理解需求之外，很重要的一块就是项目管理了。

项目管理分对外和对内。对外最重要是建立信任，信任首先一定是来自不断的沟通。互联网 + 的项目设计的角色很多，除了产品研发之外，还有运营，甚至财务、线下的 BD，要包装各角色对于项目理解不偏差，立体的沟通机制非常重要。立体的沟通机制，包括例会、邮件、当面沟通，将项目的中间过程通过立体沟通机制传递出去。

其次针对项目碎的情况，按照固定周期来迭代。这样如果有人提需求，即使你当前没有人力，你也可以告诉他大概能排到什么时候，哪个迭代中，给他稳定的心理预期。

再次就是需求优先级 PK。你可以借助你对公司当前重点的理解，你的 leader，甚至拉上各个需求方共同的老大来 PK 优先级。在人少事多的时候，做需求也需要有一定的策略，就是避免撒胡椒面，要不不做，要做就一次把一个方的需求解决透彻。比如当时公司有一个很紧急的项目，需要建独立的客服体系。老板拍板说两周之内要把体系建设起来。了解到项目的价值，带着小伙伴认真分析项目，加班赶进度，最后顺利 2 周完成交付。在业务最困难问题解决之后，大家的信任感也就慢慢建立起来了。

对内，更多就是项目流程的管理了，包括前面提到的按照固定周期发版，以及从需求、设计、开发、测试、上线整个流程中有哪些问题，这些都是经典项目管理的东西，跟传统互联网差异不大，不展开了。

互联网 + 的项目管理，就是对外建立信任；对内优化流程，提升效率。

古老的话题：提升团队战斗力

要提升团队的战斗力，首先一定要解决个体的成就感问题。码农都天然地用技术追求梦想，希望能用技术去改变世界。

技术的发展催生了互联网 +，也降低了技术门槛。正是定位、移动支付、云服务等技术的飞速发展，传统行业才一个接一个地在互联网化。而对于码农来说，互联网 + 的技术纯度在下降，有时候你做很多技术优化，还不如业务的一个决策。

技术门槛在降低，业务比重又在增加，作为技术人员你的成就感来自哪里？我认为首先互联网 + 技术的挑战来自技术的复合应用。现在你不需要亲自做一个缓存服务，因为 redis 已经非常通用了。但你需要了解什么时候适合使用 redis，怎么才能更好发挥价值。就拿开篇说的仓库管理系统真的没有技术挑战吗？子系统就有商品、订单、库存等，子系统如何解耦，如何做到高可用。业务逻辑还有权限、日志、文件异步导出等，每个要做到精细化，都有非常多的讲究。一个系统到底有没有技术挑战，跟纯 PV 关系不大，主要看业务是不是足够复杂，只要业务足够复杂，一定会有很多技术挑战。

其次，互联网 + 技术的挑战也来自用技术解放生产力。

前面提过互联网 + 人少事多的情况经常出现，那么哪些是可以通过技术手段去提升开发效率。比如前端经常觉得业务很相似，没有成就感，那是否可以开发日常通用组件，能看快速搭建一个页面出来。

再次，互联网 + 技术的成就感一定是来自业务。

前面提过，互联网 + 的业务很重，那么技术的价值感一定是离不开业务的，做一个几千 DAU 的销售 APP 在办公室可能感受不到成就感，而你跟随 BD 走访商圈，看到你做的产品对线下有多大帮助，一定会有很大的冲击。这种价值感是在办公室里 YY 不出来的。

作为技术 leader 一定要不断通过项目、事，甚至线下的走访让你的小伙伴感受做这个事情的价值。

除了个体成就感之外，团队的战斗力一定是来自于大家一起过事。所谓过事，就是大家围绕一个目标往前奔，经历很多困难，面临很多挑战，但大家齐心协力达成目标。就像码农，都觉得小黑屋的友谊很珍贵，从小黑屋封闭开发出来的同学，再见面都跟大学同学一样亲切，这就是过事。

再次相比流量分发时代，互联网 + 做的是辛苦活。你的团队文化、氛围建设也一定是要跟务实一些。比如你可能不去夸某人学习了一个最新技术，而是夸他用技术解决了一个业务难题。你不是鼓励大家不断造新轮子，而是倡导从错误中总结，从失败中学习。健康的团队氛围是大家做事情虽然很苦，但是还能苦中作乐，还能很欢快阳光地自嘲。

最后还想和大家分享一下我对事、对人的想法。对事方面要想办法去做正确的事情，去理解这个行业，去保持一个行业敬畏心，避免一些烂尾楼产品。对人方面要把大家的价值感建设起来，让大家更愿意做事，并且做到更快乐的做事。