写在前面
作为一名工作 10 年的码农,见证过像百度搜索、地图等流量分发时代,也正在经历以互联网驱动传统行业改造的互联网 + 时代,比如外卖就是被互联网改造的送餐行业。这两个不同的时代会有哪些差异,给技术管理会带来哪些挑战?想给大家分享自己这几年的一些心得体会。
流量分发与互联网 + 的差异性
对于大多数码农来说,互联网 + 都是一个新事物,我们很多人也都是从做传统互联网(比如流量分发、基础架构等)走过来,我自己总结流量分发产品与互联网 + 从产品、技术、管理的主要差异如下:
总体来说,流量分发时代产品精细化,比较容易用技术建立壁垒,技术的话语权也更大,从而技术管理更纯粹一些,围绕技术去做。
而在互联网 + 时代,突然发现世界似乎变了:产品逐渐做闭环,越来越重;不再只是精细关注每个环节的转化率,而是去关注整体。比如一个仓储管理系统,页面加载耗时不再是什么指标,而是宏观去看整个仓库货物周转效率。
你会感觉技术的纯度在下降,曾经引以为豪的高并发、性能优化似乎没有了用武之地,而业务又是全新和未知的。作为一个技术 leader,你从流量分发时代走过来,身上带着深深的技术烙印,在互联网 + 时代你和你的团队可能会经历哪些坑?又可能有哪些突破之路呢?
互联网 + 时代,技术管理的坑与路
接下来分享自己的一些体会,没有什么高大上的理论,都是一些教训。
需求越来越难以理解,还 PK 不动
互联网 + 由于你做的是自己之前不熟悉的行业,一方面专业术语明显增多,比如你的结算产品会跟你说我们做的是个“代收代付”业务,新零售产品会给你讲“挂单”、“废弃”……一堆完全摸不着头脑的名词。
除了这些专有名词,每个行业的运转模式对于一个新人来说,有很大的理解难度,需求 PK 也会变得很艰难。
比如我曾经就面临一个很艰难的需求 PK。大家都知道,对于外卖来说,营销是非常重要,特别是在 2015 年左右时期的外卖来说。当时在 PC 上已经有一个非常复杂的营销系统,业务不断提出希望将营销系统搬到销售移动端。这个工作量巨大,预估需要做 2 个月。
最开始我一直不同意做,坚持投入产出比不划算之类。后来通过跟随 BD(线下销售人员)走访商圈才知道,BD 都没有工位,他们天然就是移动办公,每天在商圈里来回穿梭。每天拜访不同的商户,而商户的环境很嘈杂,有的是在地下室信号极差,在 PC 上配营销基本是不可能。BD 没办法只能先用小本本记下来,晚上回家统一处理,效率很低。而在竞争极其激烈的时候,活动晚上线半天对商户单量影响就会非常大。通过这次商圈的实地考察,我才意识到移动端配置营销对于 BD 如此重要,这是行业的运转方式决定。于是我们马上调配人力快速支持上线。
这样的需求 PK 经历很多,慢慢我总结出来互联网 + 模式下理解需求的一些心得:
项目越来越没节奏了
在互联网 + 不只你是新人,可能你的业务也是新人,或者即使你的业务是老司机,在线下激烈的竞争之下,也经常会出现一边打仗一边调整的情况。那么作为下游的研发同学,感受到的就是需求节奏感很差,插入性需求很多,琐碎的需求也在增加。那伴随而来的就是总是事多人少,晕头转向。
比如我曾经就碰到需求池里躺了 80 个需求,却只有 3 个研发这样悲催的情况。第一反应肯定是人不够,赶紧拼命招人,于是就白天面试,晚上写代码,最多的时候看自己的日历里有 8 个面试(当然我是三面)。结果一个月之后,人是没招到几个,项目 delay 问题反而更严重了。
这时候自己意识到全力以赴招人短期是解决不了问题的,还是得老老实实做项目管理,主要通过 2 个方面来做,对外建立信任,对内梳理项目流程,如下:
通过对内对外的一系列管理,最后不但项目节奏慢慢起来了,跟业务的信任感也更强了,逐渐进入一个良性运转。这个事件给自己的思考是:
越来越没成就感了
在互联网 + 时代,大家会抱怨做的事情越来越没有技术挑战了。后端会天天叹息,用户量也就几千个,哪有什么高并发,哪有什么性能瓶颈?做的工作大多都是数据库表的增删改查,if-else 的业务逻辑;前端也吐槽,大多是内部系统,大同小异。想玩酷炫的新技术,但是产品只关注实用性。甚至想用 nodejs 找个试验田都难,后端逻辑太重;测试更加是哀怨不断,每天在功能测试的漩涡里无法自拔,心心念的自动化测试还没搭好框架,业务逻辑又变了……
更有小伙伴跟你吐槽,我花了那么多时间做业务逻辑值得吗?做结算的花了很多时间理解出账、入账、分账,等哪一天不做结算了,这些同学还有价值吗?还不如我去做一个 MQ 服务,换一个业务还是可以用得到?我们的行业经验有多少是可以迁移的呢?
这几年这些吐槽和迷茫一直围绕着我,对于成就感问题的解决我是这么思考的:
我认为首先要解决到底有没有技术挑战的问题,然后才是团队氛围建设问题。
互联网 + 的出现除了资本推动之外,很重要的一个因素恰恰是技术本身。比如移动支付、定位、导航等基础应用的服务已经非常成熟,连码农用的各类组件,比如 MQ、redis 等都已经经历过很多历练,你可能再也不需要从头去搭建一个缓存系统了。我理解就是现在做技术开发的基本组件越来越丰富,越来越强大了。就像盖房子一样,你的砖头比几年前已经强大很多,沙子的性能也强大了,原材料升级了,那盖房子就没有挑战了吗?
肯定不是的,我认为互联网 + 互的技术挑战主要来自这几个方面:
互联网 + 技术的挑战来自技术的复用应用。
拿一个可能每天只有几千 PV 的仓储系统来说,真的没有技术挑战吗?子系统就有商户、订单、库存等,子系统如何合理解耦,如何做到高可用;业务逻辑还有权限、日志、异步导出等,每一个要做精细,有非常多的讲究;另外互联网 + 的业务是在不断摸索迭代中,那高度的扩展性就是一个很大的挑战。你可以看到一个系统到底有没有技术挑战,跟纯 PV 大小关系不大,主要看业务是不是复杂。只要业务足够复杂,一定会带来很多技术挑战。
再比如解决一个外卖商户超时不接单就容易吗?首先你得分析商户为啥不接单,可能消息丢失没达到,你需要提升消息达到率,比如使用长连接等技术;也可能端上没有收到推送,那需要思考端上什么时候会丢消息?Android 处于后台时候推送可能就收不到,那端上如何保活,在被杀死的时候如何唤起?甚至商户不接单可能因为播放声音没有听到,那播放策略怎么定,如果被其他进程打断了,播放怎么继续等等……你会发现一个场景的问题,会牵扯出一堆需要技术上不断打磨的地方。所以我理解互联网 + 的技术挑战来自技术的复合应用。
互联网 + 技术的挑战来自用技术解放生产力。
前面说过互联网 + 产品更关注闭环,因此这时候整体的效率是极其重要的。如何通过技术去提升开发效率,去解决日常工作中的重复劳动就日趋重要了。比如前端如果真的是页面相似度很高,那是否可以开发日常通用组件库,甚至做一些基础的模板,能快速搭建一个页面出来;每天都有商户上报来单不响,跟商户沟通问题复现极其繁琐。如果能通过全链路日志上报,搭建一个完善的分析平台,问题定位就能快速很多。这些都是很多技术去改变效率的事情,大家在平时的工作中多去发现,一定可以找到很多点去做。
互联网 + 技术的价值一定很大程度来自业务。
前文一直在说互联网 + 业务很重,那么技术的价值感一定是逃不开业务的。做一个几千 DAU 的销售 APP 在办公室里可能感受不到成就感,但是你跟随 BD 去走访商圈,看到你做的产品对线下有多大的影响,一定会有很大的冲击感。这种价值感是在无法办公室里 YY 出来的。所以一定要真实地去观察和体验你做的产品。
另外业务的特殊性也会给你带来很多附加的价值,比如很多人就说 DBA 圈内支付宝的 DBA 特别贵,不是说支付宝 DBA 技术能力一定比别人强多少,更多是他们围绕支付宝之类银行金融标准做了很多细致的工作,这个本事就是非常有价值的事情。
说了这么多技术的价值感问题,再简单说说团队氛围建设方面。氛围和文化一定是围绕你当前的工作服务的,不得不说互联网 + 绝不是一个只要你掌控流量中心,就能躺着挣钱的时代了,它是一个非常辛苦的活。那么对于互联网 + 技术团队的文化和氛围建设应该以务实为主,比如你要夸一个人技术牛,不是因为他用了什么新技术,而是因为他用技术解决一个业务痛点,这两种导向差异性是很大的;你的团队技术分享也不能是天马行空地天天讨论最新的技术,而是讨论谁解决一个问题的实际经验,这个经验可以怎么抽象复制解决一类问题。即使是新技术的讨论,也要向前一步,讨论这些新技术在当前的情况下能用到什么地方……一句话总结,整体的团队文化和氛围一定要打破盲目的技术崇拜,而是实打实地解决实际问题,看起来很不性感是不是,但是在互联网 + 时代是非常必要的。
OK,啰嗦了这么多,对于互联网 + 时代技术管理的坑与路,我认为就是简单总结为下面这个图:
哪些是技术管理永恒不变的?
讲了很多流量互联网 + 时代技术管理与流量分发时期的差异性,讲了如何破局,最后想简单讨论下无论时代怎么变迁,技术管理有哪些是永恒不变的?
交付质量,也就是你团队的项目质量,线上服务的稳定性,我认为是生命线的东西。从需求、设计开发、测试、上线以及运维,需要花足够的功夫去保证每个环节的质量,保证服务可靠性。你不需要吹你团队用了多少新技术,有多少技术大牛,如果你的产品 bug 很多,线上服务经常故障,那技术 leader 就是不合格的。这是你作为技术管理安身立命的手艺,永远都不能放弃,不能降低要求。
做管理就是做服务。对外服务产品和业务,对内服务团队。是时候放下技术改变一切的妄念了,技术本质是一种工具,就是为产品和业务服务的,让自己和团队价值最大化的方式就是让产品和业务成功。同时码农都有一种傲娇在,作为技术 leader 一方面需要给团队小伙伴与足够的尊重,另一方面用心服务每个人的成长,一定不要让小伙伴成了“需求翻译机”,成了真正的“码农”。
写在最后,如果真的需要总结一下互联网 + 的技术管理,我认为就是 3 个方面:
-
内功:技术、管理
-
行业敬畏心,尊重你做的行业,做任何行业之前先保持一颗谦卑的学习心态。
-
服务心态,对外服务产品和业务,对内服务你的团队。
http://36kr.com/p/5132243.html
相关推荐
没事要找事做,先手最缺的是经验和技术,在闲时的时候,可以没事找事做,好处我就不多说了,但是最关键对你的好处,可以不断的练手,熟悉,接触更广的测试领域,会有很多意想不到的收获的,虽然中间可能会遇到很多的...
### 从工程师到团队Leader之路——建设优秀的技术团队 #### 关键知识点概述: 1. **从工程师转型为领导者的意义** 2. **工程师成为领导者的原因分析** 3. **建设卓越研发团队的关键步骤** 4. **领导者的角色转变...
- 领导者需要设身处地思考团队成员的需求,例如,当团队成员是营销员时,他们可能需要上司在提供职业规划、辅导技巧、沟通支持以及激励等方面给予帮助。 - 对于团队成员来说,他们希望得到明确的业绩提升方法,...
"my leader code"这个标题可能指的是一个项目或代码库的负责人所编写的核心代码,它体现了这位领导在编程技术、设计模式以及团队协作上的思想与实践。这个描述简单直接,表示这段代码是开放的,任何人都可以阅读,并...
Kafka Leader 倾斜
有些团队在实行Scrum之后,不仅没有达到预期效果,反而会出现很多问题,如:大家对开晨会的积极性不高,每次都要ScrumMaster或者团队Leader来召集;晨会成了工作汇报和安排会议;员工不主动认领任务;看板上的状态与...
领导者角色不一定适合所有人,但有时自然会出现,如首位发言者或在团队陷入困境时提出解决方案的人。即使不主动担任leader,也要积极参与讨论,展现出你的思考和贡献。 6. **角色适应**:在群面中,你需要根据公司...
如何成为技术领导,这不仅是一本书的标题,更是一系列涉及项目管理、技术问题解决、领导力发展等多方面知识的综合体现。从标题来看,本书旨在指导读者成为在技术领域内具备领导力的个体,帮助他们获得在技术项目中...
PM-leader需要制定明确的KPI(关键绩效指标),指导团队成员的工作方向,并定期进行项目复盘,以便调整策略。 5. 问题追踪与修复:BUG的管理和修复是团队日常工作中重要的一环。建立有效的问题追踪系统,确保BUG的...
【联想服务Future Leader宣讲会现场笔试】是一场针对潜在领导人才的招聘活动,旨在寻找具有技术背景和管理潜力的专业人士,以推动联想服务业务的发展。在这个活动中,参与者将接受一系列测试,以评估他们的专业技能...
12.2.5 zk是如何选举Leader的?
本文将详细介绍“杭州IT服务行业数据中台资深架构师兼团队leader”的岗位职责和任职要求,该职位涉及到的关键技术包括Spark、Java、数据挖掘、Flink、Kafka以及ElasticSearch。 **岗位职责:** 1. **部门管理与...
技术leader学习总结-附件资源
- 从一线工程师到项目Leader,再到一线主管,技能要求从专业技术向技术决策、资源协调、梯队建设等方面转变。 - 识别自我在新岗位上的适应度,对新角色的期望和现实情况作出准确的评估,确保能够快速适应管理岗位...
《LEADER LV5600使用手册》详细解读 LEADER LV5600是一款先进的4K示波器,专为高性能的信号测试与分析设计。这款设备在电子工程、科研以及工业应用中广泛使用,提供了高清晰度的4K分辨率,确保用户能够精确地观测和...
在IT项目中,经常会遇到各种复杂的技术难题和突发状况,团队领导者需要具备快速分析问题、提出解决方案并作出决策的能力。这不仅考验领导者的逻辑思维,也考验其对行业趋势和技术的了解程度。 ### 有效沟通技巧 ...
测试 leader 需要具备国际先进的测试技术,牢牢把握测试团队的测试技术发展方向,研究和应用新的测试技术,提高测试用例的深度和覆盖度。 测试技术管理的原则是四赢原则,即对公司有利、对团队有利、对下属有利、对...