技术管理进阶——把控基建与业务的比例和节奏

原创不易,求分享、求一键三连

前段时间有个粉丝问了一个问题:

小钗你好,我十分喜欢技术,但真的转到工程团队后又十分困惑:工作没人评价也没人push!

做得好没人夸奖,做得差没人批评,工作自由,几个月不产出也没人问,这样下去感觉得废啊…

很好的问题,该同学从业务团队转岗至工程团队后难以适应,表面原因是该同学自己找不到技术创新点,甚至也不太“自律”,所以慢慢“随波逐流”了。

其实这里进一步原因是:对于业务团队,上层有大量运营、产品天天抓破脑子想需求,所以业务团队目标性会很强,时间节点要求也会很高,业务技术多是解决执行问题,在思考方面的压力会很小;但技术工程团队负责的是技术基建,他的业务方多是技术Leader们和自己,技术基建工作涉及到大量的技术选题和真实难题发现,这需要大量信息输入与独立思考,而多数人并不擅长信息输入与思考,自然也很难做出令大家受益的技术服务了…

因为工程团队其实是服务于技术团队的,他代表了技术团队的创新能力,做得好可以提升技术负责人的影响力,做得不好便是技术负责人的后花园,基建工作多数情况和产品业务没有直接关系,所以很少有业务方会认可技术基建,他们会觉得这是一群“闲人”

所以,问题的本质是团队应该在技术基建投入多少资源

技术基建

业务需求解决的是公司战略问题;技术基建解决的是技术团队在公司的地位问题,两个定位完全不在一个量级,所以业务投入一定会远大于技术基建

如果技术基建结果能直接加速业务迭代效率,那么这个就是好的基建、业务方认可的基建,否则都是在扯犊子。

关于什么是好的技术基建,什么是不好的技术基建?结合这些年的工作经历,给一些例子:

Hybrid框架

很多年前的App全部是Native,随着业务发展,NA迭代速度慢,发布痛苦、用户不更新等问题一再暴露。

这个情况下,Hybrid框架应运而生,一套代码三端运行,开发效率杠杠的,于是后续的业务多使用Hybrid开发。

这个Hybrid框架就是非常成功的技术基建,他极大的提高了业务迭代效率。

Hybrid框架导致了一大波红利,技术人陶醉其中持续绣花,后续也产生了很多进阶版本,但每次版本进阶,技术人就想做一次系统升级,这会导致极大的耗损。

活动运营平台

APP体系兴起后,对应的营销活动必不可少,这些活动就像脏水一样又多又急,如果全部开发多少技术也不够,为了解决这个问题,活动运营平台应运而生,让运营同事自己拖拽完成活动发布:

《技术管理进阶——把控基建与业务的比例和节奏》

活动运营平台的出现,极大的方便了运营同学,同时也释放了技术团队,这是好的技术基建。

活动平台的出现在公司带来了一些红利,于是各个部门争相效仿都想做一套差异化的平台,资源投入不小,差异化效果寥寥,这种重复造轮子行为,是一种资源浪费。

重构

一个系统因为年久失修导致事故不断,业务方怨声载道,这会影响技术团队的口碑,所以团队会做业务重构,这种因为稳定性而发生的少数资源投入,业务团队也是赞成的;

但业务重构是无止境的,代码重构可以一优再优,如果长时间的重构投入,最终影响了迭代速度,那就不是好的技术基建了。

产品体验

还有一类的技术投入旨在提供更好的产品体验,这种技术基建正常情况都不会遭到反对,但如果是花大力气将体验从99分做到100分,业务方就不会买单了,ROI太低。

好的基建

所以,业务方眼中的好基建无非三种:

  1. 提升了迭代效率
  2. 提升了产品体验;
  3. 提升了系统稳定性;

如果一个技术基建的结果与这些无关,那么在业务方的眼里都是技术负责人在自嗨,这种自嗨包括那种想要提升迭代效率,但是没有成功的技术项目。

在技术人的眼里,评价标准还会额外加一条:自己技术实力是否得到进步,这条标准甚至会优先级最高,因为这跟他的工资直接挂钩…

技术人的矛盾

技术部存在的本质工作是完成产品的实现,因此技术负责人会承担来自业务方莫大的压力,因为技术团队需要一个未来、需要一个口碑,所以基建投入是必不可少的;但如果大量资源投入又没有产出,那他就要背负藏人的恶名,这导致了几个结果:

  1. 技术Leader对于基建的态度很矛盾;
  2. 做基建被业务方看不起,不做基建被技术和业务方一起看不起;
  3. 业务开发觉得工程团队无所事事,是个黑盒;
  4. 工程团队觉得业务开发技术平平,只是工具人;
  5. 因为工程团队事实上在给技术Leader打工,所以还不得不给不错的绩效,这又会引起一些人的不满;

总之是不做不行,做多了不行,做了没效果更不行!

就是因为如此种种原因,工程基建失败了可以大事化小小事化了,工程基建成功了又要适当包装大势宣传。

失败没成本,成功重奖励,一进一退之间技术氛围倒是好了,甚至会被渲染为工程师文化,但这造成了很恶劣的结果:不计成本的重复造轮子,这背后的资源浪费是惊人的。

基建的投入问题

“念念不忘,必有回响”,资源在哪里,哪里就会发展,如果技术团队想要有所发展,基本的资源投入是必不可少的。就这几年心得:

低于团队资源20%的技术基建投入是可接受的,10%左右的技术基建是比较合理的,小于5%的技术基建投入是没有希望的…

举个例子,Devopts、质效平台、数据采集、数据监控……这些系统有没有用,当然有用!但如果技术团队一年的成本是一个亿,请回答以下问题:

  1. 你愿不愿意用两千万去买上述系统?
  2. 两千万花了,上述系统是不是就好用了?

就我来看,首先是不值得买,其次是未必做得好,如果有成熟的系统,建议直接采买;如果没有成熟的系统,也要酌情开发。

在某些时候,还会有些特例,会导致技术基建投入超过20%,这多半是上层业务出了问题,技术团队无事可做,不得已自己找事做,这是非常危险的信号。

结语

最后回到文章之初的问题,该同学所处工程团队现在一定属于“失控状态”,这里有可能的原因是:

该工程部游离在业务边缘,并不解决业务问题,另一方面技术Leader没有提供明确的技术选题,也没有提供足够的信息输入,只是任由工程团队野蛮生长,就造成了工程部“无所事事”的情况。

如果没想清楚工程部存在的价值,大可将他们先回归到业务部门,在想清楚后再重新组建,作为技术Leader要有个认知:

技术创新带来的业务增量 > 技术基建带来的效率提升 >= 技术基建带来的稳定性、性能提升 >>> 技术基建带来的自我满足

如果要藏人做技术创新,那就想办法做ROI最高的那个吧…

好了,今天的分享就到这,喜欢的同学可以四连支持:

《技术管理进阶——把控基建与业务的比例和节奏》

想要更多交流可以加我微信:

点赞