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