原创不易，求分享、求一键三连
前段时间有个粉丝问了一个问题：
小钗你好，我十分喜欢技术，但真的转到工程团队后又十分困惑：工作没人评价也没人push！
做得好没人夸奖，做得差没人批评，工作自由，几个月不产出也没人问，这样下去感觉得废啊...
很好的问题，该同学从业务团队转岗至工程团队后难以适应，表面原因是该同学自己找不到技术创新点，甚至也不太“自律”，所以慢慢“随波逐流”了。
其实这里进一步原因是：对于业务团队，上层有大量运营、产品天天抓破脑子想需求，所以业务团队目标性会很强，时间节点要求也会很高，业务技术多是解决执行问题，在思考方面的压力会很小；但技术工程团队负责的是技术基建，他的业务方多是技术Leader们和自己，技术基建工作涉及到大量的技术选题和真实难题发现，这需要大量信息输入与独立思考，而多数人并不擅长信息输入与思考，自然也很难做出令大家受益的技术服务了...
因为工程团队其实是服务于技术团队的，他代表了技术团队的创新能力，做得好可以提升技术负责人的影响力，做得不好便是技术负责人的后花园，基建工作多数情况和产品业务没有直接关系，所以很少有业务方会认可技术基建，他们会觉得这是一群“闲人”...
所以，问题的本质是团队应该在技术基建投入多少资源。
技术基建
业务需求解决的是公司战略问题；技术基建解决的是技术团队在公司的地位问题，两个定位完全不在一个量级，所以业务投入一定会远大于技术基建。
如果技术基建结果能直接加速业务迭代效率，那么这个就是好的基建、业务方认可的基建，否则都是在扯犊子。
关于什么是好的技术基建，什么是不好的技术基建？结合这些年的工作经历，给一些例子：
Hybrid框架
很多年前的App全部是Native，随着业务发展，NA迭代速度慢，发布痛苦、用户不更新等问题一再暴露。
这个情况下，Hybrid框架应运而生，一套代码三端运行，开发效率杠杠的，于是后续的业务多使用Hybrid开发。
这个Hybrid框架就是非常成功的技术基建，他极大的提高了业务迭代效率。
Hybrid框架导致了一大波红利，技术人陶醉其中持续绣花，后续也产生了很多进阶版本，但每次版本进阶，技术人就想做一次系统升级，这会导致极大的耗损。
活动运营平台
APP体系兴起后，对应的营销活动必不可少，这些活动就像脏水一样又多又急，如果全部开发多少技术也不够，为了解决这个问题，活动运营平台应运而生，让运营同事自己拖拽完成活动发布：
活动运营平台的出现，极大的方便了运营同学，同时也释放了技术团队，这是好的技术基建。
活动平台的出现在公司带来了一些红利，于是各个部门争相效仿都想做一套差异化的平台，资源投入不小，差异化效果寥寥，这种重复造轮子行为，是一种资源浪费。
重构
一个系统因为年久失修导致事故不断，业务方怨声载道，这会影响技术团队的口碑，所以团队会做业务重构，这种因为稳定性而发生的少数资源投入，业务团队也是赞成的；
但业务重构是无止境的，代码重构可以一优再优，如果长时间的重构投入，最终影响了迭代速度，那就不是好的技术基建了。
产品体验
还有一类的技术投入旨在提供更好的产品体验，这种技术基建正常情况都不会遭到反对，但如果是花大力气将体验从99分做到100分，业务方就不会买单了，ROI太低。
好的基建
所以，业务方眼中的好基建无非三种：
- 提升了迭代效率；
- 提升了产品体验；
- 提升了系统稳定性；
如果一个技术基建的结果与这些无关，那么在业务方的眼里都是技术负责人在自嗨，这种自嗨包括那种想要提升迭代效率，但是没有成功的技术项目。
在技术人的眼里，评价标准还会额外加一条：自己技术实力是否得到进步，这条标准甚至会优先级最高，因为这跟他的工资直接挂钩...
技术人的矛盾
技术部存在的本质工作是完成产品的实现，因此技术负责人会承担来自业务方莫大的压力，因为技术团队需要一个未来、需要一个口碑，所以基建投入是必不可少的；但如果大量资源投入又没有产出，那他就要背负藏人的恶名，这导致了几个结果：
- 技术Leader对于基建的态度很矛盾；
- 做基建被业务方看不起，不做基建被技术和业务方一起看不起；
- 业务开发觉得工程团队无所事事，是个黑盒；
- 工程团队觉得业务开发技术平平，只是工具人；
- 因为工程团队事实上在给技术Leader打工，所以还不得不给不错的绩效，这又会引起一些人的不满；
总之是不做不行，做多了不行，做了没效果更不行！
就是因为如此种种原因，工程基建失败了可以大事化小小事化了，工程基建成功了又要适当包装大势宣传。
失败没成本，成功重奖励，一进一退之间技术氛围倒是好了，甚至会被渲染为工程师文化，但这造成了很恶劣的结果：不计成本的重复造轮子，这背后的资源浪费是惊人的。
基建的投入问题
“念念不忘，必有回响”，资源在哪里，哪里就会发展，如果技术团队想要有所发展，基本的资源投入是必不可少的。就这几年心得：
低于团队资源20%的技术基建投入是可接受的，10%左右的技术基建是比较合理的，小于5%的技术基建投入是没有希望的...
举个例子，Devopts、质效平台、数据采集、数据监控......这些系统有没有用，当然有用！但如果技术团队一年的成本是一个亿，请回答以下问题：
- 你愿不愿意用两千万去买上述系统？
- 两千万花了，上述系统是不是就好用了？
就我来看，首先是不值得买，其次是未必做得好，如果有成熟的系统，建议直接采买；如果没有成熟的系统，也要酌情开发。
在某些时候，还会有些特例，会导致技术基建投入超过20%，这多半是上层业务出了问题，技术团队无事可做，不得已自己找事做，这是非常危险的信号。
结语
最后回到文章之初的问题，该同学所处工程团队现在一定属于“失控状态”，这里有可能的原因是：
该工程部游离在业务边缘，并不解决业务问题，另一方面技术Leader没有提供明确的技术选题，也没有提供足够的信息输入，只是任由工程团队野蛮生长，就造成了工程部“无所事事”的情况。
如果没想清楚工程部存在的价值，大可将他们先回归到业务部门，在想清楚后再重新组建，作为技术Leader要有个认知：
技术创新带来的业务增量 > 技术基建带来的效率提升 >= 技术基建带来的稳定性、性能提升 >>> 技术基建带来的自我满足
如果要藏人做技术创新，那就想办法做ROI最高的那个吧...
好了，今天的分享就到这，喜欢的同学可以四连支持：
想要更多交流可以加我微信：
