技术人生的发展与问题思考

本文将记录大量的方法论，但 大道理千千万万，有缘者得之真谛践于其行而非流于其表。

什么是技术一号位？

1. 是负责使用技术能力解决业务问题，提供稳定可靠的技术支撑，确保业务安全合规低风险地健康发展，并通过技术或业务创新来推动业务发展；
2. 负责向业务各方提供各种必要的技术支撑，通过合理的数据分析为业务决策提供依据；
3. 通过对技术领域的积累和发展，通过业务领域的理解和落地影响业务决策；
4. 负责构建梯队完整、能力全面、制度完善的技术团队来支撑业务发展。

总结：
   对一个具体的业务而言，自己是否处在技术领域责任链的最顶端。即是否为最终责任人。

   技术一号位需要意识到，“写代码”并非核心任务，需要弄清楚应该负责的事情和域，心态和认知需要从研发的角度进行转变。

分析所在环境的局势

业务方面

1. 你负责的业务的大图是什么
2. 你负责的业务大图是否和大团队的业务战略匹配
3. 这个业务对客户的价值是什么
4. 这个业务对组织的价值是什么
5. 这个业务对你个人的价值是什么
6. 这个业务是否会在未来承担社会责任，会有怎样的社会价值
7. 这个业务目前处于什么阶段，是刚开始，还是已经成型等待发展，还是已经发展一段时间需要业务规模
8. 这个业务目前存在最大的问题是什么

协作方面

1. 谁在配合你一起做这个业务
2. 和你一起做业务的同学中，分别有哪些角色，他们会在哪些方面和你有交集
3. 和你一起做业务的其他角色的同学，是否对业务大图的理解和你一致
4. 和你一起做业务的其他角色的同学中，谁是业务的负责人；或者关键角色的人员是否对自己是业务负责人有感知
5. 业务上下游的同学段位怎么样，是否能在实际落地过程中跟上你的节奏
6. 业务一号位的KPI是什么，你的KPI是什么，你们两人的KPI是否方向一致，你的KPI是否能支撑他的KPI

团队研发方面

1. 每个人的特点是什么，有什么短板，在这个业务里面负责什么事情
2. 研发团队里面谁是你的接班人
3. 研发团队里面谁能补充你的短板
4. 研发团队里面，每个人做事都有什么个人的想法？个人的成长目的
5. 研发团队里面的每个人对业务大图是否了解，认知是否一致，目标是否一致

如何成长为技术一号位

   先确定好心态的问题以后，接下来就需要一些可以被实践检验的方法论来帮助大家打破自己层级的束缚，完成自我突破，从而在成长的基础上获得负责更重要的事情的机会，通过做好更重要的事情来获取更更重要的事情的机会，这样一定会在某个阶段，你负责的事情，需要完全以真正的技术一号位的角色去落地，那么那个时候扮演技术一号位的角色也就是水到渠成的事情了。

---

浅谈如何成为技术一号位

工作中，绝大多数的人都有自己的思维定式，都有无形的枷锁束缚着自己的思维，从而导致行为也被束缚，所以在他人看来会有这样的现象：有些事情该做却没有做，有些事情不该做却做了很多。

因此，本章节将探讨如何看到这些束缚，打破这些束缚，从而获取站到更高层次的机会，完成自身角色的转变。

业务研发同学普遍的、存在思维定式的自我认知&产生的原因及解决办法

研发普遍的、存在思维定式的自我认知是什么？

• 业务研发同学普遍将“写代码”、“做技术”作为主要工作内容，形成了“技术人”角色认同。
• 这种认知在一定程度上是正确的，但若仅关注技术而不考虑环境要求，会导致行为与环境要求不匹配。

研发的这种自我认知和环境不匹配的原因是什么呢？

   一种情况是，所处的环境发生了变化，而从最开始你就对环境的要求有错误的认知，没有意识到差异，导致了这种“环境要求和个人行为结果”不匹配的矛盾随着时间的推移越来越大，一直大到无法被忽视的情况下，才会被重视起来，才会做出反思和调整。

   另外一种情况是，你所处的环境没有变，但是自己随着时间的推移发生了变化，从而导致环境对自己的变化产生了新的要求，但是由于你没有感觉到这种由自身变化而引发的环境要求的变化，没有做出对应的及时的调整，那么就会导致新的不匹配的出现。

解决办法

   从认知上先改变，而由认知的改变带来实际行动的改变。

如何做到个人的行为及其结果匹配环境对个人的要求？

正确认知环境对个人的要求:
   业务研发应该认识到，自己的角色定位是“业务数字化工程师”，需要注重业务需求和业务能力，帮助客户实现业务数字化，而不仅仅是写代码或搞技术。

技术一号位应当负责的职责范围：

业务研发同学如何成为技术一号位？

   在认识到自己做的事情是“帮助客户业务数字化”以后，在“做业务”方面的要求就会变得和“做技术”方面的要求一样重要了。

   关于“做技术”，所有的研发对此毫不陌生；但是对于 “做业务”，似乎没有那么多可以参考或学习的东西，更多的是个人经验的积累，那么想要成为技术一号位，怎么办？

   要想成为一个业务的技术一号位，要做的是加强 “业务学” 的广度的积累，围绕业务的全生命周期，熟悉它的组成，参与掌握、把控它对外界的影响和交互的过程，并且在自己负责的细分领域内做到全面的负责，就能够成为一个业务的技术一号位。

---

学会分析事物的本质

背景

   如何才能让团队成员在做业务的过程中不再是资源一样被消耗而是像资产一样自我增值？如何才能利用对业务发展趋势的预测打破规律提前布局，在战略上掌握主动性，从而在战役上既能先于对手做出稳定的产品，又能有足够的时间打磨产品从而提升用户的使用体验？

分析事物本质的操作步骤

事物内在分析

1）明确事物讨论的范围

   为了解决某个固定的问题，我们首先要确定的就是这个问题的范围是什么，它所处的环境是什么，讨论的问题的场景是什么。这些是展开所有的分析的基础，如果多人讨论的情况下，不把这部分内容对齐，就会非常容易导致讨论的时候各方论点风马牛不相及。

2）分析事物内部组成及其存在形式

   在明确好事物的范围以后，我们需要分析清楚这个事情中的各个组成部分，每个组成部分是以什么样的形式存在的。

3）分析事物内部各组成成分所 扮演的角色及其职责

   事物的每个部分，在这个事物中，都扮演了某种角色，这个角色是某个部分的职责和行为的抽象，所有的行为都体现着该部分的核心利益诉求。

4）分析各角色在职责限定下的 核心利益诉求

   明确核心利益诉求要限定范围和场景，不能一味只做抽象，只去看矛盾的普遍性而不看矛盾的特殊性。

如：

事物组成 1
	核心利益诉求
		讲清楚该事物组成 1 的核心利益诉求是什么
	核心利益诉求的由来分析
		讲清楚该事物 1 的核心利益诉求为什么是这样的

事物组成 2
	核心利益诉求
		讲清楚该事物组成2的核心利益诉求是什么
	核心利益诉求的由来分析
		讲清楚该事物 2 的核心利益诉求为什么是这样的

事物与外界相互关联相互影响的分析

1）事物所处的大环境是什么

2）事物所处的大环境内的关键事件是什么

3）事物所处的大环境未来可能有哪些变化

基于当前阶段，分析矛盾主要方面次要方面

   明确主要矛盾和次要矛盾后，就要看下，矛盾主要方面是什么，次要方面是什么，分别给出解决办法即可。

事物发展规律的预测和干预

   提前做好一些准备，甚至主动做一些事情，从而让事情按照我们的预期来发展。

   寻找事物的关键点，判断改变关键点对事物发展趋势的影响，从而让事情向我们期望的方向演变。

解决问题的规律总结

（略，并未发现干货）

技术、业务的一般规律及应对策略

业务的发展规律

各阶段的主要矛盾次要矛盾分析

启动期

• 前半段
  • 业务的存在与否；
  • 次要矛盾：业务价值证明。
• 后半段
  • 主要矛盾：业务的可行性，包括验证业务模式是否可行，客户是否愿意支付
  • 次要矛盾：业务规模化发展和获取收益。

发展期

主要矛盾：业务规模化复制以高效创造商业价值。
次要矛盾：业务成本控制和价值变现效率。

平台期
主要矛盾：业务成本和价值变现效率。
次要矛盾：其他问题，包括组织等。

衰退期&消亡期
主要矛盾：业务的可持续发展，基于过去的业务求变求新以适应新市场环境。
次要矛盾：其他问题，可能包括组织方面的挑战。

从整个业务发展的规律来看，技术一号位需要具备哪些能力

1. 业务洞察能力：

   技术一号位需要具备分析业务本质的能力，能够识别业务内部的主要矛盾和次要矛盾，理解业务模型、客户需求以及市场趋势。这包括了分析业务生命周期各个阶段的特点和关键问题，以便为业务提供技术支持。

2. 商业理解和平衡利益的能力：

   技术一号位应能够理解业务各参与方的核心利益诉求，并能够设计合理的商业模式，以平衡各方的利益需求。这包括了根据技术系统的特点来支持和维护商业模式，以满足各方的核心需求。

3. 数据分析和指标体系建设：

   技术一号位需要能够建立有效的数据分析体系，以监控业务的健康状况，同时将核心业务指标分解为可操作的指标，以指导业务的发展和决策。

4. 系统架构设计和规划：

   在业务初期，技术一号位应具备架构设计和规划的能力，能够根据业务问题领域设计系统架构，展现架构的前瞻性和扩展性。这需要考虑到市场趋势和业务发展趋势，以满足未来需求。

5. 技术生产力投入和长线投入：

   技术一号位需要了解并具备投入技术生产力的能力。这包括根据短期业务需求落地长期技术规划，以确保技术体系的长期可持续发展。这也涉及到技术团队的培养和持续学习。

6. 支撑体系建设：

   在业务中期，技术一号位应逐步完善业务支撑维度，全方位构建支撑体系。这意味着将支撑体系的解决方案化，并促使业务支撑解决方案在不同业务之间的复用，以提高效率和质量。

7. 技术沉淀和新产品孵化：

   在业务末期，技术一号位需要有能力完成技术侧的沉淀，并能够孵化出新的技术产品或解决方案。这有助于继续创新和适应不断变化的市场环境。

技术的演进规律及对应的应对策略

认知统一：

  业务研发过程的内核是业务问题，技术研发过程的内核是技术问题，而技术问题是一种特殊的业务问题。

   业务研发过程的主要问题是对外传递业务价值，次要问题是技术在某些领域的先进性；
   而技术研发过程恰恰相反，其主要问题是在当前技术领域的先进性，其次才是本身价值的对外传递，因为其价值本身是基于它自身的先进性的。

1. 技术的演进规律

业务研发中的技术规律:

• 业务研发中的技术需要应对复杂业务模型，支持多个维度的需求。
• 技术从单一维度逐步发展到多维度，包括数字化、研发效率、运营效率、稳定性、风险控制、财税法支持等方面。
• 技术发展趋势从简单的业务运行到全方位支持业务发展，不断提高生产力。
• 多个业务团队可能复用通用业务服务，逐渐形成业务中间件，实现多业务复用。

技术研发中的技术规律:

• 技术研发中的技术既有技术性又有业务性。
• 技术经历特定生命周期，演进路径包括“能用—易用—产品化—商业化—商品化”。
• 技术的深度和粒度随着不断投入不断提高，成本逐渐增大。
• 技术演进与支持的业务规模相互关联，业务规模推动技术发展，技术发展支持更大的业务规模。

2. 如何利用规律或打破规律

理论最大的用处，是提前对事物构建一个理性的、全面的、动态的认知，从而指导对该事物的实践过程。

2.1 技术规律对一般研发同学的启示

• 认识到生产力形成的过程是和团队的生命周期相关的。
  • 成熟的团队生产力相对较高，新成立的团队次之
• 认识到业务生命周期和团队生命周期之间的关系。
  • 成熟的团队做的业务往往是比较稳定的，新兴团队一般处理的是新兴业务
• 认识到技术研发过程和业务研发过程的客观转换规律。
  • 成熟的 技术团队 已经经过多次迭代，从技术侧已经完成了阶段性的目标，会逐步将重心调整到整个技术的对外输出上，因此会变成以业务研发过程为主；
  • 成熟的 业务团队，业务上完成了对应阶段的业务使命，而继续发展下去生产力就会变成制约业务继续增长的瓶颈，所以除了业务能力建设以外，还会投入更多资源进行技术能力的建设，因此团队主要研发过程会从业务研发过程转变为技术研发过程。

2.2 从技术的发展规律来看，如何选择广度或是深度

• 结合个人内在的驱动力和外在团队的要求去考虑
• 个人内在的驱动力：一般情况下，在某个技术领域达到专家的程度，然后再去考虑继续深入或者发展广度。
• 外在团队的要求：如果是业务研发团队，技术的广度是必然的要求；如果是技术研发团队，那么技术的深度也是必然的要求

2.3 从技术的发展规律来看，如何在做业务的过程中有突破

• 业务与技术发展的错觉： 大多数人将业务发展和技术发展视为对立的过程，需求越做越多，越做越急，却最终越做越慢。
• 业务与技术规划双线并行： 每次迭代技术规划落地和业务需求要3-7开，把业务需求研发和技术研发有机地统一在一起的模式。技术规划为业务长期发展打基础，借助业务需求来阶段性落地长期的技术规划，从而最终业务需要更先进的技术能力的时候，技术已经做好了相关的准备。
• 技术作为生产力：技术是第一生产力，不仅可以支持业务、保障业务，更应该驱动业务发展。除了围着业务转以外，自己也可以作为孵化器来孵化出技术产品。

2.4 从技术的发展规律来看，如何在做技术的过程中有突破

• 做的东西怎么能让更多的人都愿意用起来：降低学习成本、使用成本等

3. 从整个技术的发展规律来看，技术一号位需要具备什么样的能力

• 宏观认知与规划： 理解两种研发过程的辩证关系，看清它们之间的对立统一面，以及相互转换的过程和发生的条件。能够在适当的时机推动这两种过程的转换，以满足外部环境对研发团队的要求。

• 团队梯队建设： 技术一号位需要在主观上认清负责的事情需要的研发过程，并根据不同研发过程阶段进行梯队建设。避免团队人员配置单一化，确保团队能够顺利完成整个过程的转变，并能够支撑对应的业务或技术产品的研发。

• 长短结合的执行力： 在执行上，技术一号位需要具备长期规划和短期需求有机结合的执行力。避免团队走弯路，确保在规划和执行之间取得平衡，以应对长期技术发展和短期业务需求的挑战。