阅读 334

实践出真知,聊技术人在业务中成长

写在最开始

写出来并不是说我做的很好,教大家怎么做。主要是想记录。
另一方面,这一年来确实在打怪升级,小小感悟,贻笑大方。
本文借鉴了来自阿里巴巴中间件的系列文章「技术人生」,也是激起我记录的主要灵感。

「技术人生」专题第1篇:什么是技术一号位?

「技术人生」专题第2篇:学会分析事物的本质?

「技术人生」专题第3篇:解决问题的规律总结

「技术人生」专题第4篇:技术组织业务的一般规律和应对策略

前言

常听见大家的一个抱怨:我们每天都在做业务,哪有时间搞技术?

做业务的时候,我们绝大多数人都是在不停处理业务需求,产品经理和运营也不会特意留出时间给研发思考技术,要的很急立马上线是我们的常态。但是缺乏技术考量的业务上线又往往带来额外负担,陷入恶性循环,需求越做越多,越做越急,效果越来越不好。

在有时间做技术的时候,我们又往往理想很丰满,现实很骨感。一心想把各种高大上的东西用起来,满足个人的技术成长欲望,消除自己在技术上积累缓慢的焦虑。自我安慰的效果达到了,业务价值却说不清也道不明。

业务发展和技术发展是对立的矛盾面么?我们是否能在业务落地的过程中实现技术进步?想聊一聊这一年中产品中的实践经验。

保持有技术一号位的心态

这个答案其实是拥有一种心态。我们姑且把他叫做技术一号位。意思就是我们不能认为自己只是一个写代码的,搞技术的。这个业务安排了我去做,那么我就是技术上的负责人,站在业务的整个角度去思考是我的责任。我写的这行代码,以后业务发展了有没有变更的可能性;我执行的这个需求到底产生了什么样的业务价值,哪个方案更适合。明确自己的角色和定位是技术序列的最终责任人。

当我还是一个写代码的小兵的时候,我并不觉得这些事情和我有任何关联,理所当然地觉得安排事情思考业务是领导的职责,我听指挥就好了。然而,后来发现,与期待相反,领导正好认为,我既然安排了你去做业务,思考周全做好业务是你的责任。所以不要去觉得级别高的或者带人的是技术一号位。做业务开发的技术同学,无论是什么层级,带不带人,只要你是这个业务的直接参与者,不用过多纠结是不是,可以本着“就当自己是”的心态把自己放在技术一号位的心态上来进行工作实践和思考。

在工作中尝试形成自己的方法论

确认了自己的角色以后,我们就要开始技术一号位的具体工作。比起写代码,我们多出来的这些责任到底我们应该怎么样去落地。要开始寻找或总结一些方法论,要自顶向下地对业务有一个清晰的认知,知道自己比过去多了哪些维度的事情要关心,知道接下来会面临什么样的挑战,要知道自己在挑战中应该扮演什么样的角色,采用什么样的手段去解决业务在不同阶段一定会出现的各种问题。

认识业务

  • 认识流程。 要画图,弄清楚负责业务的具体流程,业务的上游和下游。如果没有这种全局意识。以这种方式做业务,那么就会发现业务过程会有各种没有做到位的事情,会在做业务的过程中“交很多学费”,甚至会因为自己的能力不够而拖慢业务发展。

  • 理解业务价值。理解了业务的价值,写下的代码就有了意义。会带来比较明确的成就感和抗挫折的能力。尤其是带领一个技术小组的,leader对业务价值的理解能够极大的增加团队的协作能力。

  • 业务当前的阶段。两个好处:1是可以提前知道每个业务阶段整体的对技术的要求是什么,能完成提前的布局。在技术架构上有很强主动性。在启动阶段即在满足“有无”的时候,不再是过去那种无脑地堆代码,而是结合下阶段业务发展周期对架构的要求,对长期架构设计进行最短路径地落地:即我设计好完整的架构以后,启动期需要哪些能力,我就只按照架构设计落地哪些功能,其他没有业务需求用到的部分,一律只保留代码框架不做具体的逻辑实现即可。2:可以做业务和技术间的平衡。业务通常按照能用-易用-产品化-商业化-商品化的路线演进,如果是业务开始的阶段,有没有,能不能用这些更重要。技术上可以妥协一些。如果业务已经有很多用户了,那么业务的场景就必须考虑,技术上必须付出的代价是逃不掉的。

技术意识

  • 有意识地做设计。业务构成不是以代码写完,能通过测试case为终点。要有意识地做体系化的思考。以后端举例,从数据库设计开始,er图,数据流转。到接口文档定义。到日志定位,监控和追踪。一旦出了bug如何快速定位快速解决。技术选型,难点风险点都需要考虑。业务研发过程涉及到的技术从单一维度向多维度演变;从简单的“把业务跑起来”,逐步形成全方位支撑业务发展的技术解决方案。技术本身也从满足“有无问题”的粗犷模式,逐步演进到解决“降本提效问题”的精细模式,这是一个由主到次的过程,也是生产力提升的一个过程。这就是业务研发过程中的一般规律。

  • 有意识地思考稳定性和风险。不要把懊悔、决心、对稳定性的思考和执行力体现在事故复盘会上。在上线之前就该有各种意识,要有意识地训练自己思考一些风险,比如是否需要缓存,数据读写特征是否需要异构。比如高并发环境下表现。是否创建了无用的对象。还比如一些中间件使用,消息队列会不会丢失消息或者重复消费。还要思考回滚方案,是否有风险点和避险方案 。受制于经验,我不认为有人能一开始就做得很好。但这是一个建立和完善自己脑中技术模型的一个好的机会。

团队是必选项,不是可选项

在我自己从写代码的小兵开始慢慢打怪升级到带几个同学的时候,也慢慢接触到团队这个概念。才开始的去适应这个角色的时候,一度表现的非常挣扎,因为每天要处理的事情非常多,对自己扮演的角色没有一个清晰的认知,出现该做的事情没有做。不该做的事情投入了过多的精力,陷在代码中。尤其是在和团队成员协作上表现出了比较大的短板,间接导致了一位伙伴的离职。当时一个激烈争论的主题是休息时间如何运维线上bug,尤其是凌晨和周末。如果不是我开发的bug是不是需要我处理。看起来是非常小的事情,但是亲身经历后也慢慢悟到,团队建设就是从小事一件一件堆叠起来的。

成熟的研发团队可以通过完备的研发过程管理,来避免个人能力不够而对业务产生太多负面影响,但是本质上强制的规定和“上级要求”只是在依靠行政管理手段在强制一个人做这些事情,并没有唤醒他的创造力和责任心,反而会被认为是“工作琐事”。长时间做这样的“琐事”,会让伙伴对那些看起来 “和写代码无关但是必须做的事情” 非常抵触。这种抵触情绪发生的时候,leader 再强调 Ownership 也都没有太多效果,因为不是他不负责任,而是他没有意识到,这是他应该负责的事情。所以和伙伴解释这些琐事的价值,把上下文尽可能多的传递给大家,并且给大家足够的选择权利。成了我主要的探索方向。

1.jpg

无限进步

总结来说,想在做业务的过程中有突破。第一件事情就是要建立一个技术是可以在做业务中进步的认知,并且在实践过程中完善自己的方法论。第二件事是注重认知的升级。不管从事哪个行业,我们一生可以持之以恒一直做下去的东西就是不断改进自己。

实践和认知的关系有很多伟大的著作,我是虔诚的学徒。摘抄了一段毛选中的实践论。

任何的认识来自于实践,人在实践过程中,开始只是看到过程中各个事物的现象, 看到各个事物的片面和事物间的外在联系。这些事物引起了我们的感觉,在我们脑子里产生了一些印象。 但是感觉到的东西,我们还不能立刻理解他。处于认识的感性阶段,就是感觉和印象的阶段。 在实践过程中,使人们在实践中引起感觉和印象的东西反复了多次,在脑子里就会引起认识的突变 ,产生了飞跃,这个时候感觉就变成了概念。 此时,认识经过感觉到了思维层面,关注事物的内部规律性和本质。 认识的深化,让我们懂得客观世界的规律性,因此能够解释世界。

最后,以我最喜欢的四个字结尾。 无限进步。

文章分类
后端
文章标签