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