前言

什么是技术一号位、有哪些关注点、怎么做技术一号位？

做了研发团队的技术 leader 以后，要处理的事情非常多，如果对自己扮演的角色没有一个清晰的认知，就会出现该做的事情没有做，不该做的事情投入了过多的精力，造成实际行动和结果既不匹配上级的要求，又不匹配下级的期望。特别是对于刚开始带领研发团队的新人 leader 而言，角色的转换和适应的过程，增加了认清自己的角色本质的难度。今天我们抛开纯技术团队的同学不谈（其实本质一样），只讨论业务研发团队的同学，如何以技术一号位的角色来做事。

如何识别自己是不是技术一号位

在开始谈如何做事之前，首要任务是判断自己是不是技术一号位，而要判断之前，首先要明确判断标准，跳出思维误区。这里我们列出一些常见的思维误区。

以下是常见认知误区：

  1. 带人的是技术一号位，不带人的不是技术一号位。
  2. 级别高的是技术一号位，级别低的不是技术一号位。

以上的认知误区，错误地把是否带团队、技术等级的高低和是否为技术一号位关联起来。虽然事实上带团队的业务研发同学成为技术一号位的概率更大，但是本身这两者不是划等号的关系。

那么什么是区分是否为技术一号位的决定性因素呢？很简单：对一个具体的业务而言，你作为该业务的直接技术参与者，是否处在技术领域责任链的最顶端。这句话翻译过来就是，对一个明确的具体的业务而言，多种角色的同学一起合作的时候，你是否是技术序列的最终责任人，即：谁承担对应的责任，谁就应该扮演对应的角色。

当产品经理、运营、研发共同做一个业务的时候，某个研发同学独自或者带领其他几个研发同学，或者带领跨 BU 的研发团队，共同支撑 PD 的业务需求。那么这个研发同学就是这个业务的技术一号位，不论他是否带不带人，也不论他带的人在行政上是否从属于他。一般来说，负责单一业务的研发团队 leader 一般就是这个业务的技术一号位；负责多业务线的研发团队的 leader 的下属，是每个业务线的技术一号位，而研发 leader 本身是更高层面业务的技术一号位。

所以，做业务开发的技术同学，不论是什么层级，带不带人，都可能是某个具体业务的技术一号位的。这一点非常重要，只有认清这个事情以后，业务研发同学才能在做业务的时候，明确下来自己除了需要写代码以外还需要做什么，关注什么；这些关注点需要做到什么程度，才能对上满足期望，对下不让团队走弯路、不和下属抢功。

当你经过以上判断以后，确定自己是技术一号位时，恭喜你，你已经不再是一个仅仅需要写代码的研发同学了。很多研发同学眼中还是只有写代码这一件事情，如果以这种方式做业务，那么就会发现业务过程会有各种没有做到位的事情，会在做业务的过程中“交很多学费”，甚至会因为自己的能力不够而拖慢业务发展。

虽然成熟的研发团队可以通过完备的研发过程管理，来避免个人能力不够而对业务产生太多负面影响，但是本质上强制的规定和“上级要求”只是在依靠行政管理手段在强制一个人做这些事情，并没有唤醒他的创造力和责任心，反而会被认为是“工作琐事”。

这些“工作琐事”本质上是需要他扮演的角色来负责的，但是由于他没有意识到自己实际上已经是这样的角色了，而仅仅把自己停留在“研发”的定位上，把“写代码”当做核心任务，这样一来，会让研发同学对那些看起来 “和写代码无关但是是技术一号位必须做的事情” 非常抵触。这种抵触情绪发生的时候，leader 再强调 Ownership 也都没有太多效果，因为不是他不负责任，而是他没有意识到，这是他应该负责的事情。当他的心态和认知转变以后，一些原来看起来不怎么负责的人会变得负责（不排除有人本身就是不负责的人，那么这样的人不是良好的技术一号位的候选人，主管要有识别能力）。

作为业务开发同学，一定要仔细认清辨别自己实质上是不是一个业务的技术一号位，而不用考虑自己的层级，不用管自己是不是业务其他参与者的 leader。当你意识到自己是这个业务的技术一号位的时候，就要迅速切换角色，从原来自己给自己的定位 “写代码的、搞技术的” 转变为 “某个业务的技术一号位”，开始进入角色，发挥出你的价值。这也是很多研发同学通过做业务能迅速成长的原因，抛开技术上的成长之外，他比其他研发同学接触了很多 “做事情需要思考并为之行动” 的维度，这些维度的丰富是普通业务研发同学很难看到、很难感觉到，因此更难悟到的。

不排除有悟性高的研发同学能够自己悟到，但本质还是由于他所处的环境、他面临的问题在逼迫他做出思考，然后为之实践。如果一开始就知道自己做事情要找准自己的角色和定位，那么就会少走很多弯路。

分析你所在环境的局势

当你意识到自己是一个业务的技术一号位的时候，不用过多怀疑自己究竟是还是不是，而是要本着“就当自己是”的心态来进行接下来的工作实践和思考。需要大家明确的一点是，任何一个工作角色，都有对应的责任，也都有履行对应责任的方法论。我们要做的，不能再像过往做普通研发的时候那样懵懵懂懂去做事，听“需求”指挥，而是要开始寻找或总结一些方法论，要自顶向下地对业务有一个清晰的认知，知道自己比过去多了哪些维度的事情要关心，知道接下来会面临什么样的挑战，要知道自己在挑战中应该扮演什么样的角色，采用什么样的手段去解决业务在不同阶段一定会出现的各种问题。

在开始所有的思考之前，先要做一件事情，就是分析你目前所处的环境的局势。

业务方面

协作方面

团队研发方面

如果你本身已经是专家级别以上了，那么下面这些维度可能是需要你继续深入思考的：

业务方面

团队方面

协作方面

找准自己的定位，明确自己的定位的含义

当理清楚自己所处的环境以后，知道业务是什么情况，和自己配合的人又是什么情况以后，需要知道自己扮演的角色究竟意味着什么。从我个人的经验来看，技术一号位是负责使用技术能力解决业务问题，提供稳定可靠的技术支撑，确保业务安全合规低风险地健康发展，并通过技术或业务创新来推动业务发展；负责向业务各方提供各种必要的技术支撑，通过合理的数据分析为业务决策提供依据；通过对技术领域的积累和发展，通过业务领域的理解和落地影响业务决策；负责构建梯队完整、能力全面、制度完善的技术团队来支撑业务发展。

应该有什么样的工作原则和要求

1、以业务一号位的视角思考，辅助业务一号位构建合理的业务大图。

2、以技术一号位的角色保障业务落地，协助业务一号位实现业务的客户和组织价值。

3、掌握和业务建设过程中各种角色的上下游协作者合作的专业能力：

履行技术一号位的职责具体需要感知哪些事情及其要点

下面这张图从大方面上列出了一个技术一号位需要感知哪些方面的事情（图中未列出产品运营、售前售后等一系列其实很关键的方面，但是如果技术一号位负责的业务是有商业化需求的，则还是需要关注这些维度的事情的）。

顶级技术指标有什么（技术人生专题第1篇）(1)

这些事情是必须知道，但不是必须亲自做的，要能够借助团队的力量完成该完成的事情。下面是具体从业务、技术、团队角度来详细理清楚技术一号位需要感知的事情及其要点：

业务方面（后面会有单独的文章详细解释业务方面怎么做）

技术方面

1、技术选型

2、系统架构设计

1）业务场景在技术侧映射出来的特征是什么，对技术侧的影响是什么？

2）如果业务会在某个发展阶段涉及到大用户流量，对应的系统技术架构是什么样的？

3）如果业务非常复杂，领域众多，那么采用什么样的架构更合适？

4）如果确定要采用微服务架构来支撑复杂业务，那么领域划分和每个微服务是否匹配，微服务拆分粒度是否合适？

3、业务建模

4、研发落地

略

5、项目管理

6、项目复盘

1）质量保障

2）稳定性建设

3）风控建设

团队方面

如何成长为技术一号位

目前还不是技术一号位的业务发开同学，虽然现在的岗位只负责一小部分，但是本质上来讲，只要你负责某个事情，那么不论这个事情大小，你都是这个事情的技术一号位，只是由于事情的难易程度和规模大小，导致很多可能需要做的事情其实并不需要做，但是这些问题并不妨碍你知道技术一号位要做什么，应该怎么做，更不妨碍你以技术一号位的心态去做事。

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

作者：贺科学（晨末）

本文为阿里云原创内容，未经允许不得转载。

,