饿了么技术总监廖雪梅: 做互联网 + 技术管理,你应该避开这些大坑

阅读数:4 2019 年 12 月 30 日 20:55

饿了么技术总监廖雪梅: 做互联网 + 技术管理,你应该避开这些大坑

互联网的发展有两种非常典型的产品形态:一种是流量分发,另一种是互联网 +。在流量分发时代,一切以技术为核心;但是现在是互联网 +,技术纯度在下降。而很多技术人都是从流量分发时代走过来,带着深深的技术烙印,再去做互联网 + 产品时,会有哪些不适?会遇到哪些挑战?

饿了么技术总监廖雪梅在 2018 年 Qcon 大会上分享了她的经验和思考。以下内容根据大会现场演讲整理,有部分删减:

饿了么技术总监廖雪梅: 做互联网 + 技术管理,你应该避开这些大坑

互联网 + 与技术逆流

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

假设你是技术人员,在你的面前有两个项目让你选择去做,一个是 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 一定要不断通过项目、事,甚至线下的走访让你的小伙伴感受做这个事情的价值。

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

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

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

总结

技术管理到底哪些是不变的?做互联网、做技术最本质的东西一定是交付质量,保证每次交付质量很高,线上不出问题。如何做到高质量的交付?更多时候是大家的质量意识和责任心意识。

第二个不变的是做服务,对外是要服务产品和业务;对内要服务团队。作为一个技术 Leader,要想办法让大家在这里做事情是真的有成就感。

整个互联网 + 的技术管理就三个词:第一个是内功,技术加管理;第二个是行业敬畏心;第三个是服务心态。这就是我曾经踩过许多坑后,总结出的一些经验。


TGO 鲲鹏会,是极客邦科技旗下高端技术人聚集和交流的组织,旨在组建全球最具影响力的科技领导者社交网络,线上线下相结合,为会员提供专享服务。目前,TGO 鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名,60% 为 CTO、技术 VP、技术合伙人。

会员覆盖了 BATJ 等互联网巨头公司技术领导者,同时,阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀,成为 TGO 鲲鹏会荣誉导师。

评论

发布