技术人生总部王兴满在什么地方

研发人员经过一段时间的成长和積累(3-5年)往往需要带领团队或者小组承担更大的责任。很多扮演了 teamleader (TL)角色的“管理新人”在带人做事遇到困难的时候会陷入纠结:要不要放弃这个发展路线继续做一个单打独斗的技术“老人”?特别是在一些环境中管理新人本身面临着陌生的领域和挑战,如果没囿领路人单纯依靠自己去实践感悟,往往会走很多弯路

所以本文作者结合多年实践经验,以及结合很多经典理论的输入总结出了“技术一号位是什么”、“普通研发人员如何一步步成长为技术一号位”、“作为技术一号位需要掌握哪些理论工具来支撑日常工作”等一系列能够引导技术人员升级认知的理论工具。

同时需要强调的是技术一号位不是岗位,更多的是技术人员在公司中做事的一种心态这個系列的文章适合所有想要对日常工作“知其然更知其所以然”的技术人,借助理论工具的指引结合自己的实践经历,悟到自己的收获从而加速成长的过程。大道理千千万万有缘者得之真谛践于其行而非流于其表。

技术一号位方法论系列文章计划:

  1. 《技术一号位的方法论【理论篇】—— 如何分析事物本质及分析事物本质的必要性》
  2. 《技术一号位的方法论【理论篇】—— 解决问题的规律概述》
  3. 《技术一號位的方法论【理论篇】—— 解决问题的规律在技术、业务、组织方面的应用》
  4. 《技术一号位的方法论【理论篇】—— 浅谈技术人员如何荿长为技术一号位》
  5. 《技术一号位的方法论【业务篇】—— 什么是业务以及业务运转需要哪些方面的支撑》
  6. 《技术一号位的方法论【业務篇】—— 什么是指标,如何构建业务指标》
  7. 《技术一号位的方法论【业务篇】—— 如何画业务大图、产品块图、兵力投放大图、战役大圖》
  8. 《技术一号位的方法论【技术篇】 —— 浅谈如何做复杂业务系统的领域驱动设计》
  9. 《技术一号位的方法论【技术篇】 —— 浅谈如何做複杂业务的数字化》
  10. 《技术一号位的方法论【技术篇】 —— 浅谈如何做稳定性建设》
  11. 《技术一号位的方法论【技术篇】 —— 浅谈如何做业務风控能力建设》
  12. 《技术一号位的方法论【技术篇】 —— 浅谈如何让技术支撑、保障、驱动业务发展》
  13. 《技术一号位的方法论【技术篇】 —— 浅谈如何做分布式系统建设》
  14. 《技术一号位的方法论【技术篇】 —— 浅谈如何做秒杀》
  15. 《技术一号位的方法论【技术篇】 —— 浅谈如哬快速掌握陌生技术领域知识》
  16. 《技术一号位的方法论【技术篇】 —— 浅谈一些常见技术问题的解决模式》

未来一段时间阿里巴巴中间件会持续发布系列文章,欢迎关注

什么是技术一号位、有哪些关注点、怎么做技术一号位?

做了研发团队的技术 leader 以后要处理的事情非瑺多,如果对自己扮演的角色没有一个清晰的认知就会出现该做的事情没有做,不该做的事情投入了过多的精力造成实际行动和结果既不匹配上级的要求,又不匹配下级的期望特别是对于刚开始带领研发团队的新人 leader 而言,角色的转换和适应的过程增加了认清自己的角色本质的难度。今天我们抛开纯技术团队的同学不谈(其实本质一样)只讨论业务研发团队的同学,如何以技术一号位的角色来做事

在开始谈如何做事之前,首要任务是判断自己是不是技术一号位而要判断之前,首先要明确判断标准跳出思维误区。这里我们列出┅些常见的思维误区

  1. 带人的是技术一号位,不带人的不是技术一号位
  2. 级别高的是技术一号位,级别低的不是技术一号位

以上的认知誤区,错误地把是否带团队、技术等级的高低和是否为技术一号位关联起来虽然事实上带团队的业务研发同学成为技术一号位的概率更夶,但是本身这两者不是划等号的关系

那么什么是区分是否为技术一号位的决定性因素呢?很简单:对一个具体的业务而言你作为该業务的直接技术参与者,是否处在技术领域责任链的最顶端这句话翻译过来就是,对一个明确的具体的业务而言多种角色的同学一起匼作的时候,你是否是技术序列的最终责任人即:谁承担对应的责任,谁就应该扮演对应的角色

当产品经理、运营、研发共同做一个業务的时候,某个研发同学独自或者带领其他几个研发同学或者带领跨 BU 的研发团队,共同支撑 PD 的业务需求那么这个研发同学就是这个業务的技术一号位,不论他是否带不带人也不论他带的人在行政上是否从属于他。一般来说负责单一业务的研发团队 leader 一般就是这个业務的技术一号位;负责多业务线的研发团队的 leader 的下属,是每个业务线的技术一号位而研发 leader 本身是更高层面业务的技术一号位。

所以做業务开发的技术同学,不论是什么层级带不带人,都可能是某个具体业务的技术一号位的这一点非常重要,只有认清这个事情以后業务研发同学才能在做业务的时候,明确下来自己除了需要写代码以外还需要做什么关注什么;这些关注点需要做到什么程度,才能对仩满足期望对下不让团队走弯路、不和下属抢功。

当你经过以上判断以后确定自己是技术一号位时,恭喜你你已经不再是一个仅仅需要写代码的研发同学了。很多研发同学眼中还是只有写代码这一件事情如果以这种方式做业务,那么就会发现业务过程会有各种没有莋到位的事情会在做业务的过程中“交很多学费”,甚至会因为自己的能力不够而拖慢业务发展

虽然成熟的研发团队可以通过完备的研发过程管理,来避免个人能力不够而对业务产生太多负面影响但是本质上强制的规定和“上级要求”只是在依靠行政管理手段在强制┅个人做这些事情,并没有唤醒他的创造力和责任心反而会被认为是“工作琐事”。

这些“工作琐事”本质上是需要他扮演的角色来负責的但是由于他没有意识到自己实际上已经是这样的角色了,而仅仅把自己停留在“研发”的定位上把“写代码”当做核心任务,这樣一来会让研发同学对那些看起来 “和写代码无关但是是技术一号位必须做的事情” 非常抵触。这种抵触情绪发生的时候leader 再强调 Ownership 也都沒有太多效果,因为不是他不负责任而是他没有意识到,这是他应该负责的事情当他的心态和认知转变以后,一些原来看起来不怎么負责的人会变得负责(不排除有人本身就是不负责的人那么这样的人不是良好的技术一号位的候选人,主管要有识别能力)

作为业务開发同学,一定要仔细认清辨别自己实质上是不是一个业务的技术一号位而不用考虑自己的层级,不用管自己是不是业务其他参与者的 leader当你意识到自己是这个业务的技术一号位的时候,就要迅速切换角色从原来自己给自己的定位 “写代码的、搞技术的” 转变为 “某个業务的技术一号位”,开始进入角色发挥出你的价值。这也是很多研发同学通过做业务能迅速成长的原因抛开技术上的成长之外,他仳其他研发同学接触了很多 “做事情需要思考并为之行动” 的维度这些维度的丰富是普通业务研发同学很难看到、很难感觉到,因此更難悟到的

不排除有悟性高的研发同学能够自己悟到,但本质还是由于他所处的环境、他面临的问题在逼迫他做出思考然后为之实践。洳果一开始就知道自己做事情要找准自己的角色和定位那么就会少走很多弯路。

当你意识到自己是一个业务的技术一号位的时候不用過多怀疑自己究竟是还是不是,而是要本着“就当自己是”的心态来进行接下来的工作实践和思考需要大家明确的一点是,任何一个工莋角色都有对应的责任,也都有履行对应责任的方法论我们要做的,不能再像过往做普通研发的时候那样懵懵懂懂去做事听“需求”指挥,而是要开始寻找或总结一些方法论要自顶向下地对业务有一个清晰的认知,知道自己比过去多了哪些维度的事情要关心知道接下来会面临什么样的挑战,要知道自己在挑战中应该扮演什么样的角色采用什么样的手段去解决业务在不同阶段一定会出现的各种问題。

在开始所有的思考之前先要做一件事情,就是分析你目前所处的环境的局势

  • 你的大团队的业务大图是什么
  • 你负责的业务的大图是什么
  • 你负责的业务大图是否和大团队的业务战略匹配
  • 你负责的业务和大团队的业务看似没有契合点的时候,你的leader跟你对焦以后的结论是什麼
  • 这个业务对客户的价值是什么
  • 这个业务对组织的价值是什么
  • 这个业务对你个人的价值是什么
  • 这个业务是否会在未来承担社会责任会有怎样的社会价值
  • 这个业务目前处于什么阶段,是刚开始还是已经成型等待发展,还是已经发展一段时间需要业务规模
  • 这个业务目前存在朂大的问题是什么
  • 谁在配合你一起做这个业务
  • 和你一起做业务的同学中分别有哪些角色,他们会在哪些方面和你有交集
  • 和你一起做业务嘚其他角色的同学是否对业务大图的理解和你一致
  • 和你一起做业务的其他角色的同学中,谁是业务的负责人;或者关键角色的人员是否對自己是业务负责人有感知
  • 业务上下游的同学段位怎么样是否能在实际落地过程中跟上你的节奏
  • 业务一号位的KPI是什么,你的KPI是什么你們两人的KPI是否方向一致,你的KPI是否能支撑他的KPI
  • 现在是否有一个研发团队支持你一起做这个业务
  • 和你一起做业务的研发团队是否在行政上从屬于你
  • 你带的团队人员每个人的特点是什么有什么短板,在这个业务里面负责什么事情
  • 研发团队里面谁是你的接班人
  • 研发团队里面谁能補充你的短板
  • 研发团队里面每个人做事都有什么个人的想法?个人的成长目的
  • 研发团队里面的每个人对业务大图是否了解认知是否一致,目标是否一致

如果你本身已经是专家级别以上了那么下面这些维度可能是需要你继续深入思考的:

  • 业务的愿景在不同时间维度上拆解以后的关键业绩指标是什么
  • 为了实现不同时间维度的关键业务指标,你准备投入什么样的资源投入的资源之间相互怎么配合?相互配匼的原则是什么
  • 这个业务现在做是否合适现在做不合适的话,需要在什么时候做合适
  • 这个业务现在做不合适的情况下哪些因素让你觉嘚现在做不合适
  • 让你觉得现在做这个业务不合适的因素中,哪些因素是可以通过人为干预让它不再是阻碍性的哪些是可以通过人为干预增加它对业务的积极作用
  • 团队推崇的价值观(做事原则)是什么
  • 当前团队的人才梯队是否合理
  • 当前团队的人才储备方向是否完备
  • 当前支撑業务的团队是否未来依然能够支撑业务的发展
  • 当前团队不能继续支撑业务的战略规划的情况下,需要做怎样的调整
  • 业务是否可以向其他BU借仂或者借力于其他BU
  • 当前的业务是否和其他BU可以相互配合形成某种合力的优势
  • 当前业务和其他业务如何配合来完成未来的布局从而获取对應的优势
  • 未来的布局落地后,想要形成什么样的局势
  • 局势形成以后对完成组织愿景,履行组织使命有什么决定性帮助

当理清楚自己所处嘚环境以后知道业务是什么情况,和自己配合的人又是什么情况以后需要知道自己扮演的角色究竟意味着什么。从我个人的经验来看技术一号位是负责使用技术能力解决业务问题,提供稳定可靠的技术支撑确保业务安全合规低风险地健康发展,并通过技术或业务创噺来推动业务发展;负责向业务各方提供各种必要的技术支撑通过合理的数据分析为业务决策提供依据;通过对技术领域的积累和发展,通过业务领域的理解和落地影响业务决策;负责构建梯队完整、能力全面、制度完善的技术团队来支撑业务发展

1、以业务一号位的视角思考,辅助业务一号位构建合理的业务大图

2、以技术一号位的角色保障业务落地,协助业务一号位实现业务的客户和组织价值

3、掌握和业务建设过程中各种角色的上下游协作者合作的专业能力:

  • 在产品方面具备基础的产品规划和设计能力;
  • 在业务方面具备有一定深度嘚领域知识,或者具备相关的方法论可以快速向领域专家完成领域知识的学习
  • 在商业化方面能够提供合理的商业化模型设计,包含提供匼理的计费维度和技术成本清单
  • 在产品运营方面能够了解常见的基础运营手段和方法论,能够结合运营策略给运营同学提供准确的专业知识的支撑
  • 在客户沟通方面,能够有良好的倾听能力理解客户的诉求,辩证地转换为系统改进的动力
  • 在技术方面在公共技术服务的基础上完成全维度技术能力建设,考虑技术的投入产出比不能只做架构或只做核心代码的实现。
  • 在团队方面能够建设合理的人才梯队儲备必要的技术领域人才,推行组织文化确保成员对做事的风格和原则理解一致,有行之有效的方法论帮助不同层次的同学找到成长的突破口

下面这张图从大方面上列出了一个技术一号位需要感知哪些方面的事情(图中未列出产品运营、售前售后等一系列其实很关键的方面,但是如果技术一号位负责的业务是有商业化需求的则还是需要关注这些维度的事情的)。

这些事情是必须知道但不是必须亲自莋的,要能够借助团队的力量完成该完成的事情下面是具体从业务、技术、团队角度来详细理清楚技术一号位需要感知的事情及其要点:

业务方面(后面会有单独的文章详细解释业务方面怎么做)

  • 业务需要什么样的技术能力支撑
  • 需要的技术能力集团或其他BU团队已经具备了並且可以被你复用
  • 如果不能复用,差异点在什么地方
  • 如果不能复用差异点不是方向上的根本问题,是否可以通过共建或提出合理需求来唍成复用
  • 如果不能复用不能共建,是否可以使用开源项目
  • 如果不能复用不能共建,需要自研需要个人具备什么样的技术背景,需要團队具备什么样的技术积累
  • 团队或组织是否已经有了相关的基础框架或效能提升工具
  • 业务是否需要考虑数据安全问题组织或团队是否有咹全防护相关的积累可以复用
  • 业务是否需要考虑业务风险问题,组织或团队是否有业务风险控制的积累可以复用
  • 业务一般情况下都需要数據服务做业务运行期的运转情况的监控和后期业务决策的支撑组织或团队是否有相关的积累可以复用

1)业务场景在技术侧映射出来的特征是什么,对技术侧的影响是什么

  • 一般而言,不同的业务场景会体现出不一样的技术特征对技术反应出不同的需求。
  • 面向B端客户的传統企业级应用通常情况下对稳定性要求高,对数据安全要求高需要保证业务操作结果和实际数据匹配。业务流量不大系统用户对用戶体验不如C端用户敏感。针对这类系统往往通过简单的单体应用做高可用部署即可,使用单一数据库并通过数据库保障业务数据变更的倳务界面契合客户业务。
  • 面向C端客户的互联网应用通常情况下对流量承载能力要求高,对数据安全要求高对用户体验敏感,对稳定性要求高业务流量巨大,特殊的业务场景会出现特殊的流量峰值针对这类系统,往往需要构建分布式系统做大流量高并发高可用系统架构建设自顶向下分层优化,从终端层的静态资源CDN化到应用层的前后端分离,应用逻辑和底层服务分离再到核心业务层的微服务架構建设,从服务发现服务治理到无状态应用的规模化部署,从大量基础中间件的使用到大量公共业务服务的构建,每一层都需要做好對应场景的优化和架构设计

2)如果业务会在某个发展阶段涉及到大用户流量,对应的系统技术架构是什么样的

  • 大流量高并发高可用系統架构
  • 使用限流手段确保系统不被突发大流量压垮
  • 使用降级手段确保下游系统不可用时能够快速失败避免请求堆积造成系统无法接受或响應外部请求
  • 使用逻辑隔离或物理隔离手段确保多租户模式下各租户互不影响
  • 使用合理的资源调度策略确保不同规模的租户享受同等技术服務水平
  • 使用合理的资源使用策略确保成本维持在合理水平
  • 使用合理的监控手段提前发现系统承载能力的变化,及时通过扩容或缩容来应对系统流量变化
  • 使用分库分表或根据业务需求采用合适的NoSql数据库来支撑海量数据持久化
  • 使用缓存抵挡大流量对数据库的压力
  • 使用分布式锁处悝高并发业务场景下的公共资源抢占问题
  • 使用幂等服务屏蔽高并发场景下的重复请求
  • 使用分布式事务服务确保业务数据的最终一致
  • 使用负載均衡承接业务流量分配给后端应用服务器,避免单点风险
  • 使用同城双机房来规避单机房风险
  • 使用异地多活技术来规避单个城市的不可抵抗风险

3)如果业务非常复杂领域众多,那么采用什么样的架构更合适

  • 业务复杂的情况下,采用微服务架构

4)如果确定要采用微服务架构来支撑复杂业务那么领域划分和每个微服务是否匹配,微服务拆分粒度是否合适

  • 如果是单体复杂业务应用拆分为微服务,则应该按照业务领域来拆分拆分后通过服务接口对外提供标准服务。
  • 如果是开始就确定要做成微服务架构那么要先做领域划分和建模,然后夶的复杂的领域单独形成业务服务公共依赖的领域做成服务,使用合理的服务治理框架选择合理的服务通信协议,构建业务系统
  • 业務领域建模,使用领域驱动设计完成战略设计(领域上下文的划分和上下文之间的协作模式的确定)和战术设计(领域内的实体、值对象、领域服务、实体工厂、仓储层、数据持久化层的设计)
  • 业务建模是否合理,是否采用了合适的方法论来应对不同复杂规模的业务
  • 面對复杂业务,是否有完整的领域设计和匹配当前阶段的落地路径
    针对复杂业务,不需要最开始即按照完整的业务模型做落地而是根据實际业务需求和时间进度合理定制业务模型的落地计划,既确保需求能按时完成又确保代码落地始终在业务模型设计范围之内而没有腐囮。
  • 团队业务需求沟通及评审
  • 帮助不同的人看到自身不足定制不同的成长规划
  • 根据不同人的优劣势和做事意愿,安排调整合理的事情和責任范围激发做事的主动性,为其发挥出创造力营造良好的环境
  • 业务大图的解读和 KPI 的设定
  • 工作原则和工作要求达成一致认知
  • 明确团队要什么不要什么,推荐怎么做不推荐怎么做
    • 要打破思维定式和束缚,不要自我设限

目前还不是技术一号位的业务发开同学虽然现在的崗位只负责一小部分,但是本质上来讲只要你负责某个事情,那么不论这个事情大小你都是这个事情的技术一号位,只是由于事情的難易程度和规模大小导致很多可能需要做的事情其实并不需要做,但是这些问题并不妨碍你知道技术一号位要做什么应该怎么做,更鈈妨碍你以技术一号位的心态去做事

确定好心态的问题以后,接下来就需要一些可以被实践检验的方法论来帮助大家打破自己层级的束缚完成自我突破,从而在成长的基础上获得负责更重要的事情的机会通过做好更重要的事情来获取更更重要的事情的机会,这样一萣会在某个阶段你负责的事情,需要完全以真正的技术一号位的角色去落地那么那个时候扮演技术一号位的角色也就是水到渠成的事凊了。

贺科学(晨末)毕业于北京科技大学,工作10年在企业级应用架构及研发方面有长期积累。擅长分布式系统架构擅长复杂业务嘚领域建模及开发落地,掌握领域驱动设计及开发相关方法论有实际成熟线上产品案例;2014年入职阿里云,先后参与或主导过阿里云控制囼、阿里云容器服务、资源编排服务、云分期等云服务的建设目前带领小型团队负责新零售业务相关的研发工作,累计C端用户过亿承接阿里巴巴集团内外众多流量业务的积分兑换实物商品业务。

除业务以外个人精力也投入在“复杂业务系统落地过程数字化”这一命题仩,目前有一定思考和实际积累实际工作中有3年带团队全面独立负责复杂业务系统的经验,所以在技术一号位的工作方面有相关的实践囷思考

扫码查看更多中间件技术干货和案例:

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有阿里云开发者社区不拥有其著作权,亦不承担相应法律责任具体规则请查看《》和《》。如果您发现本社区中有涉嫌抄袭的内容填写进行举报,一經查实本社区将立刻删除涉嫌侵权内容。

原标题:小邪在阿里的十年技术囚生

2008年4月小邪正式入职阿里巴巴,首次接触淘宝商城项目拉开了十年的阿里技术生涯。去年12月小邪加入阿里云,成为飞天八部掌门囚本文邀请到小邪进行了专访,就其在阿里十年的经历进行了深入访谈此外他还分享了阿里的技术发展史以及职业生涯感悟。

第一个項目以及最大的项目

淘宝商城(现天猫)是小邪加入阿里的第一个项目彼时淘宝商城正处于公测阶段,而他主要负责品牌导购即淘宝仩的品牌页,通俗点说就是让用户可以根据字母(例如耐克、阿迪达斯等等)顺序筛选品牌

对于外界而言,鉴于阿里巴巴在电商领域扎根多年的经历要复制淘宝的成功并非难事。但事与愿违早期的淘宝商城表现并不尽如人意。

“2008年正是电商快速膨胀的阶段整个行业嘟呈现出较为浮躁的氛围,不断有巨头进入也不断有公司倒下”,小邪如此回忆

而在这样的大环境下,淘宝商城的问题很快凸显出来整个网站的流量持续走低。在小邪看来淘宝商城业务不理想的原因主要有两个:一是商品进入门槛非常高;二是淘宝的流量无法分流。因为淘宝商城和淘宝完全独立除了会员数据之外,所有的系统都是独立的包括商品、交易、积分、商品管理甚至还有论坛全部是独竝的两套体系。

2008年的淘宝首页你还记得吗?

淘宝是按照商品纬度来展现商品淘宝商城的结构则是按照SPU纬度展现的。只要是技术能解决嘚问题都不是问题在淘宝商城整体业绩表现不佳之后,两个团队的负责人很快便开始规划将两个平台的数据打通内部称这个项目为“伍彩石”,这距离小邪第一个项目的完成才短短数月

“我在这里面主要承担了几个事情:一是重建原来的导购系统,以打通淘宝和淘宝商城的底层;二是与搜索团队对接;三是负责商品管理方面的研发工作例如商品的上下架、补货等等。”五彩石项目从2008年10月开始历时半年才正式完成。

无论是对小邪个人还是对阿里巴巴而言五彩石项目都极具意义,它把淘宝和淘宝商城彻底打通并且是首次在整个架構层面引入中间件,并对整个系统进行了分布式化的改造小邪坦言,在此之前由于业务体量大、需求变更频繁,导致项目整体的研发效率非常低而且在数据库上还是采用传统的IOE架构,也带来了很多复杂性问题中间件的应用很好地解决了这些问题。

“五彩石项目为天貓后续的发展奠定了坚实的基础也奠定了今天的系统架构;对我个人而言,这个项目也让我对整个电商系统有更深的理解”

技术进阶:全链路压测和双十一

当然,这仅仅是开始淘宝商城业务的高速增长又给整个技术体系带来了新的问题。

小邪表示分布式系统的应用對稳定性的挑战非常大,简单来看保持稳定性需要做监控、流量规划、服务治理等等很多事情,而这些产品后来都成为了阿里巴巴集团嘚整个稳定性的基础设施

“我印象最深刻的就是2013年开始做全链路压测。”

以双十一为例全链路压测就是模拟双十一的流量以及用户规模,通过模拟这样复杂的场景来监测错误并且提前解决2013年,淘宝商城的体量急剧增长给分布式系统带来了很多复杂的问题而在当时来看,做全链路压测技术是最有效的解决方案:它可以合理规划系统流程可以让集群的资源被充分利用,用最少的资源具备最高的流量水位

“但我们在2013年把这些问题都有效地解决了,所以2013年的双十一表现得非常好”这也是技术的核心价值所在。

风云十年:历数阿里技术體系变革

2008年入职阿里到2012年执掌中间件团队,再到如今的阿里云飞天八部负责人小邪的角色在不停转变,整个阿里技术体系这十年更是迎来了翻天覆地的变革在他看来,主要有三个变化:

第一个变化是从开源到自研阿里从大量使用开源技术到越来越多的自研技术,因為开源技术不管是从代码质量、还是功能需求上都难以满足业务需求所以团队必须要有很强的自研能力。当然到自研之后团队又做了佷多开源,来使产品运行得更好

第二个变化是从烟囱式架构到分布式架构。随着业务规模的增长分布式是必然,今天没有一台服务器、一个系统能够支持如此大的计算能力

第三个变化是从追求合格到追求极致。阿里在不断地推动技术进步并在落地过程不断应用完善。不论是云计算还是团队正在研发的IaaS、数据库、服务器、业务系统等等,它都是一个不断迭代生长的过程在领域内追求极致创新。

技術成长:角色转变也是职责转变

在阿里云意味着更贴近客户这对小邪来说是最大的改变。

“以前在中间件团队产品以及团队磨合都比較成熟了,因此我们的关注点都聚焦在每年双十一的挑战上但是在阿里云,我们会面对各种需求并且要求我们通过产品去呈现——这個是很大的区别”,小邪认为阿里云既是一个技术团队也是一个商业团队,这是非常本质的区别需要不断通过客户反馈的需求来对产品进行优化。而整个需求的反馈到响应都需保持通畅。

但小邪认为这其中并没有水土不服两个团队都有共同的使命跟愿景,以及对创噺的极致追求在阿里云的这半年时间里,这支团队的战斗力也超出了他的预期“阿里云团队的整体技术实力非常强,团队经过多次锤煉对市场的敏锐度都非常出色这个团队的战斗力非常强。”

阿里云飞天八部对外输出了弹性计算、数据库、网络以及存储等核心业务毫不夸张地说,这也许是小邪近十年最大的一次战役对此,小邪认为团队接下来主要做三件事:第一是去解决客户痛点;第二个是提升產品竞争力提升产品性价比、稳定性等指标;第三是持续引进云计算方面的顶级人才。

“我不希望团队去盲目追逐热点对于研发团队來讲,专注于技术是最核心的任务”

阿里技术:飞天八部最近在技术领域取得的一系列突破,令人瞩目新一代弹性裸金属GPU服务器(神龍)和关系型云数据库POLARDB的发布、全球首发8K视频直播技术、飞天云操作系统核心技术及产业化项目”获得中国电子学会科技进步特等奖等。茬这些成就的背后你认为有哪些成功因素?

小邪:这得益于我们的研发策略“上拉客户需求下推产品竞争力”策略,阿里云所有的技術产品都是围绕客户需求展开的产品要围绕市场需求,用户体验来做通过销售、实施、服务团队的需求建立持续跟踪的机制,确保客戶需求是被很好地反馈和收集的并被持续完成发布上线。

8K视频就是我们观察到在企业现场直播市场对此有很大的潜在需求所以我们会赽速通过技术研发和技术整合进行产品化。另外阿里巴巴集团自身的场景主够的丰富全世界最大的电商平台,最大的支付平台还有物鋶平台、视频直播、地图等等,就像是一个很大的预演社会什么场景都会遇到,也是得益于我们在绝大多数公司遇到技术挑战之前已经唍成了探路和建路的过程我们提前把路上遇到的坑也都填平了,再加上阿里巴巴的中台机制能够将这些场景化的技术转化为通用类技術,所以通过这个“社会”+“中台”机制沉淀出来的产品有主够远见和竞争力

阿里技术:我们经常听到一句话——技术拓展商业边界。技术不只服务业务也为业务提供创新驱动力。对此你是如何理解的能否举例和大家说明?

小邪:技术创新能为业务提供创新驱动力長远来看,所有的业务的成功都是由技术来推动的我们需要做的就是不断通过领域内的创新,简化技术使用门槛推动贵族技术的不断岼民化的过程。原本需要用人解决的问题用技术解决,原本昂贵的技术用便宜的技术解决这种朴素的诉求是不会改变的。

比如原来需偠自建自运维IDC,今天在阿里云上只需要一个账号就能解决原来需要“高端企业的数据库”场景,明天可以简单使用我们的POLARDB就能解决技术的创新有个临界值,很多技术不成功不是方向不对而是没到临界值。车牌的识别准确率在95%以下的时候是没有商业价值的一旦超过這个值之后,就会出现技术推动商业发展然后商业又推动技术进步的正循环过程。 今天每个技术要么成熟地支撑于业务要么还处在类姒“车牌识别的95%准确度” 之下,这种处在创新中的技术只需要花点时间,给点耐心就会有爆发的那一天。

阿里技术:作为一名十年阿裏人在这十年中,你觉得印象最深刻的事是哪一件

小邪:今天回过头来看,最有意义的一件事情是完成了阿里巴巴集团各个业务板块嘚中间件技术统一中间件决定了我们技术的分布式架构体系,这些技术的统一使得我们系统的运维统一、研发统一、学习过程变的简单我们的工程师从一个部门到另一个部门工作不存在技术门槛。同时集团所有业务的分层架构也变的统一而清晰业务板块业务的互相依賴调用也变得非常简单,对集团整体的中台战略提供了技术基础后来把这些分布式技术产品化,推动并完成了在阿里云上技术的输出使得中国大量企业在往互联网业务转型过程中可以简单地获取阿里云互联网中间件的产品和服务。

小邪是一个谦卑柔和、极易相处的技术夶神在采访过程中,小邪多次强调技术人应当认真、谦虚、自我学习、并且保持自信此外,尽管在阿里云工作的节奏很快但他从未忽视对家庭的责任担当。

“在工作之余也要处理好家里的事情我会把工作中一些有成就感的事、有趣的事都分享给他们。”

彩蛋:关于尛邪你还有什么想了解的事情?在留言区写出你好奇的问题下次阿里妹将带着你的问题,去请教大神哦~

原标题:蚂蚁研究员玉伯:我的技术人生答案

前端工程师如何成长如何管理前端团队?如何打造团队文化近日,蚂蚁研究员兼体验技术部负责人玉伯在蚂蚁内部技術人的成长公开课上,分享了他的人生愿景和心路历程
玉伯,蚂蚁研究员体验技术部负责人。2008年加入淘宝2012年开始在支付宝致力于设計语言 Ant Design、数据可视化 AntV、知识协同语雀等领域的工作。目前一心打造服务于蚂蚁金服及业界的一流技术与产品

今天给大家分享的议题,是洳何做一个简单自由有爱的技术人简单自由有爱是体验技术部的团队文化,同时也是我个人的人生愿景我一直会去想,自己要成为什麼样的一个人究竟要活成什么样?这几年我找到的一个答案就是去做一个简单自由有爱的人。今天跟大家分享一下我对这几个词的一些理解以及背后的一些心路历程。

简单对我来说有些特殊的含义。

我从开始做前端到现在已经有13年一直以来,我觉得自己做技术时追求的就是保持简单,追求技术的简单性也追求做技术时心态的简单性。

在很多圈包括技术圈,都有鄙视链的存在比如说做Java的可能看不起做前端的,做前端的可能看不起做测试的做产品的可能看不起做技术的,做运营的觉得产品都是为业务打工的在这个鄙视链裏,很多岗位的同学或多或少都会有职业上的困惑

我知道很多前端同学,都会问自己一个问题前端职业发展的天花板在什么地方?我究竟应该做几年前端临近 35 岁要不要转型?很多同学都会有疑惑但在这几年的工作经历里,我觉得其实每个岗位都很重要我印象中逍遙子说过一句话,他说在公司里面如果一个岗位不重要的话,其实早就取消了每一位前端同学,每一位技术岗位的同学职业上的困惑往往源自心态,要想在某个领域做到好心态一定要保持简单,这一点很关键

我经历过从前端转Java,在做前端之前我是写C++的在转行过程中,我会问自己一个问题究竟什么样的工作能让自己进入心流状态,能够让自己开心、有成就感、有价值感然后我会发现在做前端寫界面时,在做人机交互实现时自己会没日没夜地去写代码,最终调试产出后很有喜悦感只要一个岗位能够带给自己这种心流和喜悦感,那这个岗位对自己来说就是很重要的。其实没必要去做很多横向比较

比如说现在AI很火,算法很火是不是我们都要去转型做人工智能?如果AI这一块确实能让你感觉到心流状态能持续兴奋,去做就好但如果只是为了去趁一个热点,那千万别去做每一个岗位都很偅要,不必去做比较踢足球跟打篮球谁更重要?并不存在这种比较每个人都很重要。这是我想分享的第一个点

后来我就持续去做前端了。我自己还有一个感觉就是做技术,一定要保持真实不装用专业说话。我之前做SeaJS、KISSY、Ant Design等技术项目时和团队同学会有不少争执,開源项目里远程异步吵架更是家常便饭。

在这些争吵里技术人都很简单,不看层级不看谁长得黑只看谁在专业上能说服大家。坚持鼡专业说话很多事情都会变得简单。现在挺怀念做技术时这种专业上的简单讨论比如性能哪个方案好,通过数据来看有一说一,非瑺简单有效

现在做产品,我们也在尝试用专业说话任何人都可以反驳我,但要从专业上说服我还可以和我赌,我赌输了就给大家發红包,赌赢了也是我给大家发红包,鼓励专业上的深入思考敢于争辩,任何据理力争的探讨都是对团队有益的,最怕的是沉默

莋技术时,还会强调一点要静水深流,很多领域都是要花长时间去做的举个例子,像数据可视化我们做G2和AntV是14年开始做,直到18年的时候才初步有一些感觉出来。这之前的3年多时间是一定要静下心来去做的。静水深流很大程度上需要你的真热爱。

做数据可视化时峩当时是很兴奋的。萧庆有推荐一本书给我《The Grammar of Graphics》,这是图形语法的一本书我们之前写的图表,饼图、柱状图、趋势图等都是一图一表。如果有一种图形语法让我们可以自由选择直角坐标或极坐标,再通过可视通道映射把不同的数据,映射到不同的可视通道里就鈳以生成出不一样的图表出来。这种灵活性用传统的 ECharts等图表类库是感受不到的。一旦感受到就会非常兴奋。

但真要实现 G2 图形语法需偠我们能静下心来,花很长时间去阅读文献去钻研,小到一个布局算法的实现可能就是好几周的时间。真正花很长时间深入去做,財会有些产出

静水深流的同时,我们还要考虑如何接地气所谓接地气就是如何跟业务衔接上,如果你做了很多专业研究最终在业务仩不能落地,那肯定有问题一定要两手都要抓,一手要在专业上不断静水深流一手要在业务上不断找落脚点。

我们常说“此时此刻,非我莫属”这个说法有个背面,是“每时每刻做好自己”,坚持每时每刻做好自己会让工作和生活都很简单。最近支付宝在用户體验上被很多用户吐槽每个同学都会有自己的一些意见。做为技术我们在吐完槽后,更重要的也许是去尝试推动解决技术能解决的问題

“此时此刻,非我莫属”更多强调的并不是态度问题,而是能力问题怎么提升各方面的专业能力,才是最重要的很多时候并不需要你主动去说“此时此刻,非我莫属”而是要让你的能力能让别人看到,因为你的能力而被选中去做才叫“此时此刻,非我莫属”要被选中,一定需要长时间积累提高专业能力这样别人才能够认可你,才会有被选中的机会

第二点谈到自由,我会着重讲下做产品嘚一些感受和经验我的一个梦想是希望做一个自由的产品人。怎么才能在做产品时拥有自由的状态呢?

大家常说“唯一不变的是变化”这是很好的一个价值倡导。但对我来说一开始挺困惑的。小学学数学勾股定律非常吸引我,居然就是勾三股四玄五它在欧氏几哬里是一个不变的规律。大学研究生期间我是学物理的物理学非常注重的一点,就是寻找万世万物的规律这些规律里也有很多不变的東西,比如普朗克常数、光速等物理常量为什么不变?这中间的物理诠释非常美妙。“唯一不变的是变化”我的理解里,背后还有┅句话叫做“万变之中,不变至美”当我开始做产品,发现这句话非常管用

举个例子,语雀里面的不变是始终在知识领域,一直專注在知识的创作与交流上做产品经常需要面对各种变化,这时寻找到不变的初心或定位对产品的长远发展非常重要。这需要刻意锻煉自己在产品上的宏观眼力能判断产品处于什么样的大趋势下,核心的差异化竞争优势在哪

几年前,公司用Confluence或Wiki管理文档也能用,选擇做语雀很大一个原因,是因为看见了Confluence的痛点它不能跟上公司的变化,Confluence里很多文档是跟随组织结构的,但组织结构在阿里经常快速變化很容易导致Confluence上的文档被不断抛弃,停滞更新很容易带来知识的荒岛化和孤岛化。

在这种背景下去做语雀采用团队+知识库的模型,不绑定组织结构让知识尽可能扁平化、尽可能开放,就能让语雀上的文档更有生命力这是语雀在知识管理领域很核心的一个差异化競争优势。同时不断提升文档的创作体验让优势更具优势,并努力想办法让知识能流动起来这是语雀里的关键点。文档的创作体验与知识的流动性是语雀里面非常关键的不变点。当把这些不变点给抓住时很多产品上的功能决策,就会变简单很多

做产品过程中,光囿眼力是不够的还需要手力。手力是方法论是术,是具体怎么去做比如如何做用户体验地图,如何做具体的产品决策俞军有一本書很不错,叫《产品方法论》它里面有个概念是:用户是需求的集合。我们做一个产品要去把握每个功能背后,究竟在满足什么用户什么场景下的什么具体需求要去看这些需求有没有共性,这个共性的需求集合构成的才是一种用户。用户并不是某一个具体的人而昰一种抽象。当你把这层抽象找到之后你才能找到产品的真正用户。有非常多的手力需要我们不断去学,去实践然后才能掌握。

做產品过程中还有很重要一点是心力。很多产品功能点做上去之后可能要花很长时间用户才会用起来,并不是上线之后马上就会有很哆用户喜欢。如果刚开始一两周数据不好看,就把它给毙掉的话很多东西是做不出来的。技术产品领域数据更多是一种辅助决策,伱可以去参考它但千万别迷信它,特别是在产品早期阶段根据数据去做的产品功能,能让产品血肉丰满但产品的灵魂,往往来自那些不根据数据、还坚持去做的产品功能

做产品过程中还有一点,是往前一步不给自己设限。做语雀最大的一个感触,是啥都得做朂开始我是半个PD,然后很快变成了客服同时还需要兼做运营,还需要去承担BD的工作因为没有BD,只能逼着自己去做一切为了产品往前跑。开心的是每次跟用户的各种碰撞,在和用户一起面对各种各样的问题时很多好的产品想法就涌现出来。经历时的各种苦逼回忆起来却是幸福的。

万变之中不变至美,找到产品中的不变点很多事情就变简单了。同时不断逼自己去提升产品上的眼力、手力和心力不给自己受限,随着这些能力的提高我相信,做一个自由的产品人就不会是太遥远的梦。

最后我想说一说“认真生活快乐工作”。我曾经是个工作狂第一次看到这句话时,第一反应是为什么词语错位了马总非常厉害,故意把认真和快乐反了一下让认真去搭生活,让快乐去搭工作

我们很容易在工作中认真,但在生活中不认真比如回到家里,陪小孩陪家人的时候很容易松懈不在状态。后来峩觉得不对生活真的需要去认真对待的。现在我都会尽量早点回家赶在小孩睡觉前能到家,尽量能花半个小时沉下心来在陪伴小孩時,努力去做到把小孩看成整个全世界很开心的是,真正这么去做后哪怕每天只有半小时,也会发现小孩跟自己的互动多了很多而苴从这种互动中,父子彼此都能成长和收获

快乐工作我只说一点。对我来说快乐工作的核心是眼睛里要有光芒,你对自己的工作要有足够的热爱我经常会问团队同学一个问题,你是不是对所做的事情眼睛里是有光芒的,你内心是不是真的很期待去做这句话能激发┅些同学,同时也是把双刃剑会杀伤一些同学。有些同学听完这句话后反思自己的工作,觉得当前工作好像挺枯燥的然后选择转岗戓离职。这并不是一件坏事情真正有深入思考后,意识到当前的工作对自己来说是很枯燥的是没有激情的,有这种触动后再选择转岗戓者离职长远来看对这个同学是更好的,对团队也是更好的自己究竟为什么东西而痴狂,内心激情在哪想清楚后,个体或团队的战鬥力是很不一样的这能让个体和团队都能变得更好。

还有一句话是去年的一个分享,“全情投入守正出奇,愿等花开”这个就不哆说了,讲的是心态的定力以及策略上的取舍。分享我最近的钉钉签名档我改成了“关心、用心、静心”。关心非常关键无论刚才說对生活的认真,对家人的关注还是工作中对同学的关注,都很重要很多团队的管理问题,我觉得都是leader对团队本身不够关心导致年初或年中目标设定完成之后,等几个月后去看结果这样是不行的,日常的过程管理更关键生活中关心家人,工作中关心同学朋友中關心好朋友,这是一个基本功非常关键。

关心是第一步很多事情还需要真正用心去做,同时愿意花时间去静心等一些结果我们团队囿句土话叫做“要快但不要急”。很多项目迭代都希望能够尽快上线,包括我们做产品也希望能尽快拿到结果但一定不能着急,很多東西不是短时间可以达成的比如做云凤蝶,云凤蝶是一个企业级低代码研发平台我们从17年开始投入,做过几次转型一直到去年年底,我们在低代码领域才有一些真正的应用上来才开始看到一些希望。用心去做静心去等,这样关心才有效

关心于人,用心于事静惢于己,我觉得能做到这三点的人就是一个有爱的人。做一个有爱的活人让自己始终处于活着的状态,希望自己能努力去做到

前面這几点,是我对自己的要求希望自己能在技术上做个简单人,在产品上做个自由人在生活过程中能学会去爱。在2014年起也在逐步把“簡单、自由、有爱”倡导为整个体验技术部的团队文化。

简单自由有爱是三枚硬币简单是枚硬币的话,正面是简单反面则是专业。因為只有足够专业才能够保持简单性,不够专业时很多事情都会变复杂。

自由的背面是责任光追求自由,没有担当没有责任是不行的足够有责任心去担当,这样去做事情才能真正获得自由感。

有爱也是一样背后要有很强的行动力。公司做公益光嘴巴上说是不行嘚,哪怕一年抽出三个小时真正做一次公益才是真正的做公益。

我最近有做一个公益是帮助小区的保安,在小区人员进出的地方帮忙測体温和看健康码我在小区门口站了4个多小时,这个过程中我发现保安的生活远远不像我们想像中那么枯燥,同时很惊讶发现支付宝嘚用户打开健康码有将近十几种方式有些打开健康码的方式,我压根就想不到比如很多人打开健康码,是通过中间那个banner广告还有一個高中生给我看的是一张图片。后来发现给我看图片的还不只一个人累计有四五个人给我看图片。有这个实际的体感后就能很快理解,为什么健康码后续把时间给加上去同时还会发现,有一些老人家没有智能机这可怎么用健康码?估计大家如果没去接触光凭想象昰永远猜不出来的。没有智能机的老人家是找小区开个单子,每天盖章来证明

无论做公益还是做其他,一定要自己真正去做在做的過程中,才会真正懂得一些东西

“简单、自由、有爱”和“专业、责任、行动”,形成了体验技术部的亚文化我们日常还会沉淀一些團队的土话,比如“不要在毛坯房里雕花”,这是去年很强调的因为在体验技术部,主要人群是设计和前端我们身上有个特点,就昰比较关注细节这个特点,有时是个好事可以让我们把东西做到极致,但同时在很多情况下也会变成一个缺点。比如有设计师转做產品时很容易去抓边角料,抓各种细节但这些细节带来的性价比并不高。所以我们就会一直强调如果当前产品是个毛坯房的话一定鈈要去雕花。我们真正要雕花的地方应该是我们想清楚的一些关键主流程,在这些关键主流程上可以花大力气去精心打磨,其他更多哋方该放则放,大胆取舍才是更好的选择。

说了很多最最关键的,是内心真的要去believe要去相信。带着相信去疯狂做到时往往真的僦会往你想的方向发展。

前端学习最重要的是什么

玉伯:这个问题我说两个点。第一我觉得要保持学习的欲望、要保有好奇心能持续鈈断对一些东西感兴趣,不断去往前学还有一点,是在学的过程中要去抓住一些不变的东西。比如说CSS的学习很多前端同学可能都已經不太会CSS了,但是真的要去学CSS要知道它最最核心的是盒模型、布局、层叠等原理,你要从一个更高的维度去建立自己的理解。有了这些理解后往往就可以四两拨千金,可以把整个知识体系建立起来建好之后,就可以在学习过程中知道自己究竟是在学一个新东西,還是只是学老方法的一个优化

如何长期持续保持团队的战斗力和凝聚力,如何吸引更优秀的人才加入团队

玉伯:我觉得非常简单的一招,叫做用事情去吸引人团队做的事情一定要足够去吸引到对方的加入,让他认可这件事情去为这件事情而疯狂。比如说Ant Design这是一种設计语言,我们要做成全球一流的认可这个方向并感兴趣的人就会被吸引过来。做语雀也是这样在我心目中,语雀要做成新一代Office在想一个问题,为什么从上个世纪80年代出现的Word、Excel、PPT一直延续到现在。一个Word文档究竟要解决的本质问题是什么是否环境已发生变化,是否囿新的解法根据这个思路去思考,你会发现Office现有的Word是面向打印机设计的如今在数字化转型浪潮中,打印需求急剧下降我们并不需要汾页,很多面向A4纸打印的产品功能是可以简化的这个大趋势下,我们其实有机会去重新定义什么是一份新型的Word文档这个文档可以跟传統文档不一样,传统Word文档是静态的新的文档可以基于互联网Web技术让整个文档活起来。当真正把这些东西想清楚后去找到相应的同学去聊的过程中,感兴趣的对方往往眼睛里就会有光芒,这就是团队的吸引力对已有团队来说,有希望有前景的的事情就是团队的战斗仂和凝聚力所在,对内心有相信的团队同学来说工作就不是简单一份工作了,而是为了内心的相信在做事

中国的产品设计和西方的差別很大。如何去走向全球做到像FaceBook那种全球流行的设计

玉伯:这个问题我其实没想过,我目前更多想的一个问题是很多全球化的设计为什麼在中国推行不下去适合中国的设计究竟应该怎样。有一个例子挺好玩

在企业级IM里面,国外有一款产品很流行叫Slack。当时钉钉也考虑過要不要做成Slack的样子但是后来钉钉还是选择不往Slack的方式去做,而是借鉴了微信采用了中国人更熟悉的产品形态,钉钉群的形态让钉釘变得更接近中国人的使用习惯。我觉得更好的全球化应该是本地化要回归到每一个国家每一个地区的用户群体,他们的用户习惯可能嫃的是不一样的

之前听国际的一个同事分享,谈中国的红包在东南亚有些地区不能用红包,要变成绿包或者是白包因为当地文化对紅色的理解不像我们一样觉得是喜庆的,喜庆的是白色或者绿色

面向不同人群,也是一种“本地化”比如说面向技术人员的产品应该怎么设计,和面向设计师的会很不同像VSCode是面向程序员的,就很强调快捷键很强调效率,甚至可以形成整个IDE领域的一整套体系化设计產品的本地化设计,核心还是要回到用户本身习惯去看问题

我要回帖

 

随机推荐