JAVA技术总监：技术团队管理的6大坑 _团队管理

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

文章插图
互联网 + 与技术逆流我算是互联网行业里较早的一批码农，做过五年技术和五年管理。想和大家分享的是互联网 + 的技术管理。
假设你是技术人员，在你的面前有两个项目让你选择去做，一个是 passport 登录系统，规模十万级；另一个是仓库管理系统。你会怎么去选？
为什么问大家这个问题？因为我一直觉得在码农中是存在一条鄙视链：

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

在十年前的互联网，技术人员会削尖脑袋往第一、第二阵营去挤，而现在越来越多的人开始进入第三、第四阵营的开发，各种业务系统慢慢地都在逆袭的过程中，这是为什么？
我回顾了自己十年的工作经历，从技术角度来看，互联网的发展有两种非常典型的产品形态：其中一个是流量分发。
拿百度来说，百度是一个巨无霸的流量中心，很多产品都想从上面去分一杯羹，于是产品设计都是精细化从流量中心攫取更多的流量。这种产品形态下，产品本身很轻，但每一步流量的转化就极其重要，所以需要技术精细化去优化，那是技术为王的时代。
另一个典型的产品形态就是互联网 +，用技术去改造一个个传统行业，产品越做越重，越来越闭环，技术的价值反而不是最重要的了。
在流量分发时代，技术管理相对简单，一切以技术为核心。但是现在的互联网 +，技术纯度是在下降的。而我们很多人都是从流量分发时代走过来，带着深深的技术烙印，当我们再去做互联网 + 产品时会有哪些不适？会遇到哪些挑战？这些就是我想要分享的内容。
互联网 + 的需求变化做技术管理，所面临的第一个挑战一定是需求上的。
互联网 + 的需求理解会比流量分发时代更难，因为这个行业时先于互联网 + 存在，每个行业都有它比较固定的模式，你会觉得隔行如隔山。比如做新零售的，产品会讲商品废弃、挂单等名词，结算产品会说我们做的是“代收代付”业务，你会一头雾水。
每个行业有每个行业的运行规则，也会给你的项目带来很多不一样的地方。比如，做结算时，研发最痛苦的事就是每个月的对账。有一次，那个月的账怎么对都不明白，从下午查到晚上，每次算出来都差了几块钱。到半夜 12 点时，做对账的小伙伴特别悲催地看着 PM 说，姐，这个钱我自己掏了行吗……结果当然是不行，做财务的每一分钱都需要对得非常清楚。
除了需求理解成本高之外，需求 PK 难度也会增加。由于互联网 + 的强业务导向，在研发尝试与产品 PK 需求的时候，有时候产品也解释不清楚就直接说，线下业务就是这么玩的，那我们就必须这样去做。
再次，需求变化迭代速度比流量分发时代快很多了。对于这个行业，业务同事也可能是新入门，所以经常会是一边打仗一边调整。而且整个市场竞争非常惨烈，巨大的压力之下，业务也会根据竞争形势不断去做调整。
在做外卖产品时，我们每个季度都会做需求规划。每次总结下来后发现，面向商家的需求规划，可能有 40% 或者 50% 会按照计划执行。而面对内部的需求比如管理系统，规划最多只能执行 20%—30% 。
总体来说，互联网 + 的需求迭代更快、理解成本更高，研发尝试要做需求 PK 也会更难。
技术团队要对传统行业保持敬畏心管理无非就是事和人。技术 leader 对事的管理，第一要务一定是需求管理。研发 leader，第一项硬本领也就是能理解需求，能 PK 需求。在流量分发时代，需求理解和 PK 成本相对会低很多。
拿百度地图上做酒店来说，PM 提需求说有些地方要做改版，但是我觉得这么做不靠谱，就会其他竞品的样式给他看，甚至聊聊自己作为用户的一些“感知”（虽然不一定专业，但你至少是用户）。另外，很多需求都可以从数据来分析这么做是否靠谱。如果 PM 一定要上线需求，这时候就可以去预估一个转化率，最后拿数据说话，告诉 PM 这个需求不可行，再下一次，PM 就不会固执己见了。