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