当前位置: 首页 > 后端技术 > Java

浅谈如何成为技术No.1岗位

时间:2023-04-02 09:59:18 Java

简介:在日常工作中认清每个人自己的思维模式非常重要,这将有助于改变一个人对很多事情的看法,而这种改变也会从根本上带来行为改变。也就是说,通过理论分析和实践,共同完成对个体实际生活的影响。在今天的文章中,我们先讨论一下业务研发同学,或者说大部分业务研发同学的自我认知,然后看看在这种普遍的自我认知中,是否已经存在着大家熟视无睹的思维模式;然后探讨思维模式形成的原因是什么,如何突破认知不足造成的自我约束;最后探讨业务研发同学应该有什么样的认知,如何完成自己从普通开发到技术一号的角色转变。作者|HeScience前言绝大多数人都有自己的思维模式,有无形的枷锁束缚着他们的思维,导致他们的行为被束缚,所以在别人眼里,就会出现这样一种现象:有些事情应该done但我没有这样做。有些事情不该做,但我做了很多。不谈公序良俗、社会公德、法律法规等在社会活动中制约人们遵守的东西,只谈在工作中可能束缚大家的无形之物,或者说“做事””,并与大家共同探讨如何看待这些枷锁并打破它们,从而获得站在更高层次上的机会,完成自身角色的转变。在日常工作中认识到每个人自己的心态非常重要。它有助于改变一个人对很多事情的看法,而这种转变也会带来行为上的根本改变。也就是说,通过理论分析和实践,共同完成对个体实际生活的影响。那么在今天的文章中,我们先来讨论业务研发同学,或者说大部分业务研发同学的自我认知是什么,然后看看在这种普遍的自我认知中是否已经存在着大家熟视无睹的思维,然后探讨思维模式形成的原因,如何突破认知不足造成的自我约束;最后,探讨业务R&D同学应该有什么样的认知,如何通过实践完成自己从普通开发Role到TechnicalOne的转变。商科R&D学生共同的自我认知与刻板印象&成因及解决办法“技术”和“大牛”似乎对理工科专业的人很有吸引力。在所有IT相关专业毕业后,这种“成大牛”的情结仍然发挥着重要作用,让毕业生在从校园走向工作后,依然能够带动自己继续学习,在工作中学习。积累(当然,驱动R&D同学提升能力的可能不是“大神”的剧情,而是“残酷的现实”——“不懂”、“不会”、“做不到”可能被“现实”打脸),提升自己的技术水平,继续朝着自己敬仰的“大牛”方向努力,完成个人成长的第一阶段。也正是这样的发展路径,逐渐让R&D学生形成了“技术人”的角色认同。因此,绝大多数业务研发人员都会把“写代码”和“做技术”作为工作的主要内容,认为自己是在“做技术”。这种认知的形成是由周围环境和个人日常行为共同推动的。这种自我认知本身是对的,唯独这种认知是错误的,是对个人角色的片面认识。在这种自我意识的驱使下,研发人员会关注编码标准、代码性能、编码技巧、研发效率、新技术、各种先进的技术术语及其背后的实现。但是,如果研究者仅仅用这种认知来驱动自己采取实际行动,那么行动本身和行动所获得的结果就不能满足研究者所处外部环境的要求。这就是为什么说现在大部分业务研发人员对自己都有刻板印象的原因。客观来说,大部分R&D同学的认知其实只是关注自己默认角色(R&D)的需求(足够高的技术能力),而没有关注周围环境的需求。知识基础上的偏差造成了“实际行动”与“环境要求”的不匹配,会带来很多问题,而这些问题并不是从原有的认知层面采取行动就可以解决的。2、R&D学生自我认知与环境不匹配的原因是什么?一种情况是你所处的环境发生了变化,从一开始就对环境的要求有错误的认识,没有意识到其中的差异,导致“环境要求与个人行为不匹配”结果”随着时间的推移,矛盾越来越大,大到可以忽略不计的程度,才会认真对待,进行反思和调整。但这种调整是被迫的,不是主动的。可以理解为一种无意识的应激反应。下次再遇到同样的问题,不同境界的人会有不同的反应:没有理解的学生,会任由这种不匹配继续导致无法忽视的问题,然后去“不自觉地”去解决;悟性较高的人会利用以往的经验,当问题处于可以清晰感知但尚未达到影响和不容忽视的阶段时可以解决。但是,靠经验并不是一个稳定可靠的方法,因为总有很多东西是以前没有经历过的,在没有经验的支持下,还是会出现和没有理解的同学一样的问题;看到本质,总结相关的方法论,在事情来的时候用方法论去分析问题,判断事情的发展趋势,仿佛可以站在一个更高的视角和维度上,去观察整个过程中发生了什么,如何为了避免它再次发生,如何减少这个问题的影响或者直接避免这个问题的发生。针对这种情况,比如刚毕业的学生往往不能适应社会工作和生活,又比如男女朋友结婚后,敏感的一方会觉得对方变了。变化以及环境中对个人的需求也会发生变化。因此,当你的个人环境发生变化时,比如跳槽到新公司、更换新团队、增加下属人数、改变业务方向或负责新业务等,你必须应对这些环境变化足够敏感,可以检查环境的变化是否为我们自己创造了新的和不同的要求。说白了就是检查自己的角色是否因为环境的变化而发生了变化,需要用变化后的角色来处理事情。另一种情况是,你生活的环境没有变,但是你自己随着时间的推移发生了变化,从而导致对环境的新要求改变了你,但是因为你自己感受不到这种变化而导致的环境要求的变化,不及时做出相应的调整,就会导致新的错配出现。针对这种情况,比如刚升职的学生,随着能力的提高,环境对你的要求也在变化。您必须使用新的角色来响应更改后的需求,而不是继续使用原来的角色。角色和做事的方式。因此,每个人都应该对自己的个人变化足够敏感,检查自己的变化是否引起了环境的不同要求,检查自己现有的做事方式是否能够满足需求的变化。要满足,就要分析什么样的角色可以满足,然后改变个人的认知,在这个角色中做事。综上所述,“环境变了你不变,环境变了它不变”,你需要分析环境对你的要求是什么,判断现有的认知驱动行为是否存在能符合这个要求;如果不能匹配,那么就需要分析什么样的行为可以匹配新的需求,这种行为应该起到什么样的作用,才能知道自己要改变的方向。这个理论和结论不仅适用于业务研发,而且具有普适性,只是讨论“个人与环境的要求是否匹配”的问题。这些理论分析,实质上是用《矛盾论》的理论方法来分析“人与环境”中“人的行为与结果和环境的要求”之间的矛盾。它随着时间、环境和个人的变化而变化。我们从枯燥的理论分析回到商科R&D学生的问题。业务研发的同学从入门到成长为技能过硬的技术骨干,经历了这两种情况。第一种情况,从学校毕业到工作,在经历了环境的变迁,经历了“社会的毒打”之后,大部分人都是通过提升个人技术能力来度过这个阶段的,而这种解决问题的方式也带来了很多麻烦给大家体验第二种情况:根据经验,提高个人技术能力可以满足环境要求,但实际上,随着你的成长,环境对你来说不再只是技术。是必须的,持续提升自己的技术能力只能起到提升个人技术能力的作用,并不能弥补环境对你的要求和你的行为不匹配的情况。很多研发负责人或者技术骨干都有过这样的痛苦经历,认为自己技术好就会被赏识,这样就没有问题了。但是问题本身跟你个人能力好不好没有关系,跟你能不能适应环境的要求有关系。好的技术只是从周围环境中获得新要求的一种“资格”,而不是解决方案,不断提升个人技术能力也不是真正的解决方案。真正的解决办法是认知的转变,认知的转变带来的实际行动的转变。3、如何使个体的行为及其结果与环境对个体的要求相匹配?如果说绝大多数R&D同学都存在这种认知误区,以后肯定会经历“环境对自己的要求会随着个人能力的提高而改变”这样的事情。那么如何解决这个问题呢?总之,“一开始要有正确的认识,以后要随时调整自己的角色”。首先,问题的原因是什么(环境要求与个人行为和结果不匹配),我们上面已经说的很清楚了,在知道原因的前提下,首先要做的其实很简单,就是就是,“正确认识环境要求”。商业研发学生面临的环境要求是什么?是“写代码”还是“搞技术”?不,“写代码”和“搞技术”只是你的工作内容(而且只是很小一部分),不是环境的要求,环境的要求是:帮助客户实现业务数字化(不反对和讨论,因为理论讨论毫无意义,但欢迎任何形式的实践测试)。也就是说,对于所有做业务开发的同学来说,从你认可这个理论分析的那一刻起,你就不再只是一个“研发工程师”,而是一个“客户业务数字化工程师”。你的默认角色——研发工程师,在当前的大环境下,增加了新的角色和相应的职责。在认知方面,他们需要改变以往毕业后形成的旧认知,努力转变到新的认知,理解新的。该角色隐含的要求和期望是什么。所以,以前我们常说的研发工程师、JAVA开发、前端开发、全栈开发、go工程师都是按个人技能分类的,不是按职责分类的。这种传统的划分方式也给你带来了很多误导和禁锢。要知道,如果你在业务团队,除了上面的工作角色,不管你的技术栈是什么,你都应该被称为“业务数字工程师”。这是你过去没有注意但一直存在的事情。“新角色”,这个“新角色”将从过去看不见的变成现在看得见的,从幕后走向台前。这个角色和相应的职责会让你在原有的工作内容上有一个新的维度感知。有了这个理解,你就会意识到,业务端知识学习、需求分析、领域建模、模型实现、流程优化的比重和基础性,不亚于写代码的比重,甚至更高。虽然我们讨论的都是业务研发类的同学,但本质上,做纯技术平台开发的同学也是一样的。你的任务是帮助商业研发学生数字化,或者让我们以更低的成本更高效地帮助你。客户业务数字化。您的业??务需求是技术性的。如果不能对技术平台的业务需求有足够的建模和分析能力,那么技术系统也会比业务系统有更高的逻辑复杂度和更高的抽象度。给你造成很大的困难。“帮助客户实现业务数字化”的要求,并不是说你停止开发自己的技术,而是需要你把更多的精力投入到“业务”这个词上,对它有一个新的认识,而不是把它当成“阻止我编写代码的事情”。所以用一个比喻来形容,就是:做业务开发的R&D同学,不管是什么级别,什么级别,带不带人,都需要“技术”和“业务”两条腿走路。这就是所谓“正确认识业务研发生对环境的要求”的意思:让业务研发生发现并注意培养自己的另一条“走路的腿”,用做业务的过程锻炼力量这条腿,通过掌握合适的方法论,加速力量的形成,加强这一退的力量,因为总有一天你需要依靠这两条腿,带领很多“一瘸一拐”的业务开发同学前行。为什么说“一瘸一拐”发展的同学呢?因为目前绝大多数商科开发的同学只是“做业务需要”,而不是“做业务”。业务能力和技术能力不匹配,还不能“两条腿走路”,顶多一瘸一拐。举个所有R&D同学都能看懂的例子,最后总结一下上面的意思:如果你认为自己只是写代码,做技术,那么你只关注写代码,只关注如何提高自己的技术能力,而不关注如何提高自己的技术能力。技能。如果你注重业务能力的提升,那么你就会掉进自己认知偏差给自己埋下的坑里。这种偏见本质上和下面两个一看就知道有问题的东西是一样的:1.产品经理只需要做产品原型。2、运营同学只需要给客户端推送广告即可。现在我能感觉到“R&D同学只需要写代码”是一种偏见吧?需求分析?做吧!各种沟通会?打开!业务发展规划?做吧!很多研发同学认为“干扰我写代码”的事情,其实是你角色必须做的事情,而且这些事情的比例甚至比写代码还要高。因为在帮助客户业务数字化的过程中,写代码、做技术只是第一步。下面两张图分别是普通业务研发人员看问题的视角和第一技术岗位看问题的视角。普通研发人员是站在资源的角度看问题的。如果他们从资源的角度看问题,他们只能对一件事做有限的动作,最后只能算是资源:技术第一从看问题的角度,你必须转以Owner的角度看问题,即与你相关的事情需要你负责(不一定是主要责任,但你必须负责):需要注意的是在“责任圈”中上图第二张,普通R&D同学受限于自己的认知,只能做写代码最里面的东西。随着技术能力的提升,职责范围可以逐步扩大,但是永远不能触及其他角色的职责范围,技术一号位的职责范围会逐渐扩大到与之相关的各方,甚至部分重叠。这是两人因认知差异导致角色扮演差异,导致行为和结果的差异最直观的表现。业务研发生如何成为技术一号位在意识到自己所做的是“帮助客户将业务数字化”之后,“做业务”的要求将变得与“做技术”的要求一样重要。关于“做技术”,在大学里可以学到技术领域的基本专业技能,工作之后有很多书和项目可以学习。所有研发人员对此都不陌生;可以参考或者学习的东西很多,更多的是个人经验的积累,那么想要成为技术第一应该怎么做呢?我们先做这样一个假设——“我们可以通过分析一个事物的组成,观察这个事物的生命周期,了解这个事物在其整个生命周期中与外界的关系和相互作用,来全面了解一个事物。“.我们既然要学习“做生意”的知识,从而有能力成为技术一号位,那么我们就必须充分了解一个事物,在认知的过程中知道它需要什么样的能力,而这些能力是我们需要通过各种方式逐渐锻炼出来的。所以想要回答R&D同学是如何成为技术No.1职位的,首先要了解一个企业包括什么,它有什么样的生命周期,它与外界有什么关系?数字时代,个人总结分析,从抽象的角度来看,一个企业会有如下信息需要大家了解:1.什么是企业涉及多个组织,根据一个共同的目标,通过信息交换?一系列过程,每个过程都有明确的目的并持续一段时间。2、企业存在的目的和价值是什么?通过创造价值给企业带来效益(可能是经济效益,也可能是其他效益,如品牌、口碑、社会形象等)3、信息时代涉及的常规业务有哪些在价值生产方面,数字技术、商业产品、产品运营、产品销售、客户服务、风险控制、综合协调4.什么是企业的生命周期?企业将对外产生什么价值,可以获得什么回报价值,通过物质或虚拟生产过程所创造的价值的传递和扩散,所创造的价值将被更多的外部主体所理解、接受,并愿意贡献创造的价值为价值交换付出,通过价值创造获得经济利益的回馈,以及外部主体对价值的回馈。价值本身得到提升,价值生产过程的改进是根据外部主体的价值反馈进行的。基于创造价值的成本和效率的考量,不断输出各种实际或虚拟的提升价值,不断为外部受众提供价值,不断获取利益价值的消亡,随着外界的变化,价值不复存在不再可用于交换赚取收入的能力,不再被生产6.为了让一个企业诞生,尽可能地实现它的目标,延长它的生命周期,必须要有建立一个商业项目的能力,证明其价值,让企业从无到有“成为可能”。业务的发展使业务从概念转变为实际交易。将业务的输出包装成产品,让客户以良好的感官去感知业务的结果。业务的运营让业务的输出获得更多的客户。客户服务,帮助客户解决使用产品过程中的问题,有机协调业务各方,使业务以最佳方式尽可能长地运行,通过各种手段延长业务生命周期7.什么是技术第一?岗位职责在产生业务价值的过程中,业务数字化过程中所有与技术相关的事务都是技术一号位的职责,协助业务一号位完成业务支撑,参与全过程业务生命周期,并参与业务决策过程利用技术能力在业务的各个环节为业务目标的实现和生命周期的延长提供支持。在理解了以上内容的基础上,我们需要知道一个客观事实:“做业务”和“做技术”需要的知识需要的知识本质上是一样的,都是个人的实践经验+以前的经验总结(知识在书本上),所以业务知识在知识形式上会和技术知识一样,具有以下特点:可以学习可以通过个人实践获得的知识分布形式,以形式被外界感知的知识树。知识树的分叉意味着知识会有不同的细分和一定的广度;知识树的层级意味着会有一定的深度系统,学习知识的人可能对某个分支的知识(知识深度)比其他人更深;他们还可能比其他人(知识广度)更广泛地掌握多个知识分支(知识广度)。技术领域经常被讨论如何在个人发展路线上权衡深度和广度这两个方向。同样的,同样的情况也存在于“商学”中。但是,由于现在是数字化时代,业务本身就包含了数字化技术,所以大家作为业务研发人员,自然在“业务科学”这个技术细分领域有很深的积累,而产品人员自然也有“业务科学”这个技术细分领域的深厚积累。商业科学”产品在细分领域有较深的积累。运营人员自然在“商学”的运营细分领域有深度积累,职业经理人自然在“商学”的综合管理细分领域有深度积累。因此,要想成为企业的NO.1技术岗位,需要做的就是加强“业务学习”广度的积累,关注企业的全生命周期,熟悉其组成,参与掌握和控制其对外界的影响和相互作用的过程,并在自己负责的细分领域全面负责,才能成为一个企业的技术一号位。目前这个结论只是为了让大家在思想上认识到对技术一号位的整体要求,改变以往对“研发标准”的认知误区。至于如何一步步通过实践成为技术No.1岗位,需要继续阅读其他文章掌握相应的知识,依靠掌握的方法论来指导实践,少走弯路。﹀﹀﹀解决方案咨询技术交流群:搜索钉钉群号31704055加入,可以获得详细的云原生解决方案资讯和专家答疑。版权声明:本文内容由阿里云实名注册用户投稿,版权归原作者所有。阿里云开发者社区不拥有自己的版权,也不承担相应的法律责任。具体规则请参考《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如发现本社区涉嫌抄袭内容,请填写侵权投诉表进行举报,一经查实,本社区将立即删除涉嫌侵权内容。