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