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