发布在即!企业 AIGC 应用程度测评,3 步定制专属评估报告。抢首批测评权益>>> 了解详情
写点什么

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

  • 2019-12-30
  • 本文字数:5129 字

    阅读完需:约 17 分钟

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

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

饿了么技术总监廖雪梅在 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 鲲鹏会荣誉导师。


2019-12-30 20:551354

评论

发布
暂无评论
发现更多内容

区块链扩张路径变局:从技术比拼转向生态落地

CECBC

没错,用三方 Github 做授权登录就是这么简单!(OAuth2.0实战)

程序员小富

Java GitHub oauth2.0

CAP原理

chenzt

第六周作业

秦宝齐

学习 极客大学架构师训练营

2020-07-11-第六周作业

路易斯李李李

第6周总结

andy

架构师训练营第六周作业

一剑

面向对象编程学习

一叶知秋

第六周总结

秦宝齐

作业

React与前端开发发展史

pingan8787

数据结构学习心得

程李文华

架构师训练营第 6 周作业二

不谈

架构师训练营第六周作业

R20114

极客大学架构师训练营

用Roslyn做个JIT的AOP

八苦-瞿昙

技术 随笔杂谈 aop 代理 框架

Spring循环依赖及解决方式

张sir

Java spring 循环依赖

详解区块链应用市场与落地应用现状

CECBC

博睿宏远获颁“2020开发与技术企业服务奖”

博睿数据

运维自动化 开发工具 博睿宏远

第6周课后练习-请简述CAP原理

Dawn

极客大学架构师训练营

架构师训练营第六周总结

一剑

对CAP的理解

朱月俊

你要的《Spring系列源码解读》PDF它来了

z小赵

Java spring

分布式系统架构作业

qihuajun

1. react起始 | 2020年前端再入门系列连载

chaozh

大前端 React

路过,凌晨2点的南京

小天同学

总结 思考 个人感悟 夜归人

指数 | 2020年6月北京BGP机房网络质量评测报告

博睿数据

评测 博睿宏远 指数

第6周作业

andy

CAP Theorem

dongge

MySQL 连接查询超全详解

X先生

MySQL 数据库

HashMap学习总结

大刘

hashmap hash

java 后端博客系统文章系统——No5

猿灯塔

Java

Rust所有权,可转可借

袁承兴

rust 指针 函数调用 引用 内存管理

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