「技术人生」专题第1篇：什么是技术一号位？

作者 | 贺科学（晨末）

来源 | 阿里巴巴中间件团队 

前言

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

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

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

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

以下是常见认知误区：

1.带人的是技术一号位，不带人的不是技术一号位。

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

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

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

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

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

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

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

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

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

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

分析你所在环境的局势

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

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

业务方面

• 你的大团队的业务大图是什么
  

• 你负责的业务的大图是什么

• 你负责的业务大图是否和大团队的业务战略匹配

• 你负责的业务和大团队的业务看似没有契合点的时候，你的leader跟你对焦以后的结论是什么

• 这个业务对客户的价值是什么

• 这个业务对组织的价值是什么

• 这个业务对你个人的价值是什么

• 这个业务是否会在未来承担社会责任，会有怎样的社会价值
  

• 这个业务目前处于什么阶段，是刚开始，还是已经成型等待发展，还是已经发展一段时间需要业务规模

• 这个业务目前存在最大的问题是什么
  

协作方面

• 谁在配合你一起做这个业务

• 和你一起做业务的同学中，分别有哪些角色，他们会在哪些方面和你有交集
  

• 和你一起做业务的其他角色的同学，是否对业务大图的理解和你一致
  

• 和你一起做业务的其他角色的同学中，谁是业务的负责人；或者关键角色的人员是否对自己是业务负责人有感知

• 业务上下游的同学段位怎么样，是否能在实际落地过程中跟上你的节奏
  

• 业务一号位的KPI是什么，你的KPI是什么，你们两人的KPI是否方向一致，你的KPI是否能支撑他的KPI

团队研发方面

• 现在是否有一个研发团队支持你一起做这个业务

• 和你一起做业务的研发团队是否在行政上从属于你

• 你带的团队人员每个人的特点是什么，有什么短板，在这个业务里面负责什么事情
  

• 研发团队里面谁是你的接班人
  

• 研发团队里面谁能补充你的短板

• 研发团队里面，每个人做事都有什么个人的想法？个人的成长目的

• 研发团队里面的每个人对业务大图是否了解，认知是否一致，目标是否一致
  

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

业务方面

• 业务的愿景是什么
  

• 业务的愿景在不同时间维度上拆解以后的关键业绩指标是什么

• 为了实现不同时间维度的关键业务指标，你准备投入什么样的资源？投入的资源之间相互怎么配合？相互配合的原则是什么
  

• 这个业务现在做是否合适？现在做不合适的话，需要在什么时候做合适

• 这个业务现在做不合适的情况下，哪些因素让你觉得现在做不合适
  

• 让你觉得现在做这个业务不合适的因素中，哪些因素是可以通过人为干预让它不再是阻碍性的，哪些是可以通过人为干预增加它对业务的积极作用

• 业务的现状及瓶颈问题

• 业务问题的技术解法

• 业务发展趋势
  

• 业务竞合分析

• 业务发展策略
  

• 业务的终局畅想

团队方面

• 团队的使命是什么

• 团队推崇的价值观（做事原则）是什么

• 当前团队的人才梯队是否合理
  

• 当前团队的人才储备方向是否完备

• 当前支撑业务的团队是否未来依然能够支撑业务的发展

• 当前团队不能继续支撑业务的战略规划的情况下，需要做怎样的调整
  

协作方面

• 业务是否可以向其他BU借力，或者借力于其他BU

• 当前的业务是否和其他BU可以相互配合形成某种合力的优势

• 当前业务和其他业务如何配合来完成未来的布局从而获取对应的优势

• 未来的布局落地后，想要形成什么样的局势

• 局势形成以后，对完成组织愿景，履行组织使命有什么决定性帮助

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

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

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

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

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

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

• 在产品方面具备基础的产品规划和设计能力；
  

• 在业务方面具备有一定深度的领域知识，或者具备相关的方法论可以快速向领域专家完成领域知识的学习。

• 在商业化方面能够提供合理的商业化模型设计，包含提供合理的计费维度和技术成本清单。
  

• 在产品运营方面能够了解常见的基础运营手段和方法论，能够结合运营策略给运营同学提供准确的专业知识的支撑。
  

• 在客户沟通方面，能够有良好的倾听能力，理解客户的诉求，辩证地转换为系统改进的动力。

• 在技术方面在公共技术服务的基础上完成全维度技术能力建设，考虑技术的投入产出比，不能只做架构或只做核心代码的实现。

• 在团队方面能够建设合理的人才梯队，储备必要的技术领域人才，推行组织文化，确保成员对做事的风格和原则理解一致，有行之有效的方法论帮助不同层次的同学找到成长的突破口。

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

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

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

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

• 建大图
  

• 定方向

• 找打法

• 撑业绩

技术方面

1.技术选型

• 业务需要什么样的技术能力支撑

• 需要的技术能力集团或其他BU团队已经具备了并且可以被你复用
  

• 如果不能复用，差异点在什么地方

• 如果不能复用，差异点不是方向上的根本问题，是否可以通过共建或提出合理需求来完成复用

• 如果不能复用，不能共建，是否可以使用开源项目

• 如果不能复用，不能共建，需要自研，需要个人具备什么样的技术背景，需要团队具备什么样的技术积累
  

• 团队或组织是否已经有了相关的基础框架或效能提升工具
  

• 业务是否需要考虑数据安全问题，组织或团队是否有安全防护相关的积累可以复用

• 业务是否需要考虑业务风险问题，组织或团队是否有业务风险控制的积累可以复用
  

• 业务一般情况下都需要数据服务做业务运行期的运转情况的监控和后期业务决策的支撑，组织或团队是否有相关的积累可以复用
  

• 技术投入产出比

2.系统架构设计

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

• 一般而言，不同的业务场景会体现出不一样的技术特征，对技术反应出不同的需求。

• 面向B端客户的传统企业级应用，通常情况下对稳定性要求高，对数据安全要求高，需要保证业务操作结果和实际数据匹配。业务流量不大，系统用户对用户体验不如C端用户敏感。针对这类系统，往往通过简单的单体应用做高可用部署即可，使用单一数据库并通过数据库保障业务数据变更的事务，界面契合客户业务。
  

• 面向C端客户的互联网应用，通常情况下对流量承载能力要求高，对数据安全要求高，对用户体验敏感，对稳定性要求高，业务流量巨大，特殊的业务场景会出现特殊的流量峰值。针对这类系统，往往需要构建分布式系统做大流量高并发高可用系统架构建设，自顶向下分层优化，从终端层的静态资源CDN化，到应用层的前后端分离，应用逻辑和底层服务分离，再到核心业务层的微服务架构建设，从服务发现服务治理，到无状态应用的规模化部署，从大量基础中间件的使用，到大量公共业务服务的构建，每一层都需要做好对应场景的优化和架构设计。
  

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

• 大流量高并发高可用系统架构
  

• 业务流程异步化
  

• 使用限流手段确保系统不被突发大流量压垮

• 使用降级手段确保下游系统不可用时能够快速失败避免请求堆积造成系统无法接受或响应外部请求
  

• 使用逻辑隔离或物理隔离手段确保多租户模式下各租户互不影响

• 使用合理的资源调度策略确保不同规模的租户享受同等技术服务水平
  

• 使用合理的资源使用策略确保成本维持在合理水平

• 使用合理的监控手段提前发现系统承载能力的变化，及时通过扩容或缩容来应对系统流量变化

• 使用分库分表或根据业务需求采用合适的NoSql数据库来支撑海量数据持久化
  

• 使用缓存抵挡大流量对数据库的压力

• 使用分布式锁处理高并发业务场景下的公共资源抢占问题
  

• 使用幂等服务屏蔽高并发场景下的重复请求

• 使用分布式事务服务确保业务数据的最终一致

• 使用负载均衡承接业务流量，分配给后端应用服务器，避免单点风险
  

• 使用同城双机房来规避单机房风险

• 使用异地多活技术来规避单个城市的不可抵抗风险
  

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

• 业务复杂的情况下，采用微服务架构
  

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

• 如果是单体复杂业务应用拆分为微服务，则应该按照业务领域来拆分，拆分后通过服务接口对外提供标准服务。
  

• 如果是开始就确定要做成微服务架构，那么要先做领域划分和建模，然后大的复杂的领域单独形成业务服务，公共依赖的领域做成服务，使用合理的服务治理框架，选择合理的服务通信协议，构建业务系统。
  

3.业务建模

• 业务领域知识学习。

• 业务领域建模，使用领域驱动设计完成战略设计（领域上下文的划分和上下文之间的协作模式的确定）和战术设计（领域内的实体、值对象、领域服务、实体工厂、仓储层、数据持久化层的设计）。

• 业务建模是否合理，是否采用了合适的方法论来应对不同复杂规模的业务？
  

• 面对复杂业务，是否有完整的领域设计和匹配当前阶段的落地路径？
  针对复杂业务，不需要最开始即按照完整的业务模型做落地，而是根据实际业务需求和时间进度合理定制业务模型的落地计划，既确保需求能按时完成，又确保代码落地始终在业务模型设计范围之内而没有腐化。
  
  

4.研发落地

略

5.项目管理

• 项目目标
  

• 完成时间

• 想要取得的结果

• 项目成员

• 关键里程碑
  

• 风险预警

• 多方协调沟通

• 日常进度追踪
  

6.项目复盘

1）质量保障

• 代码扫描

• 代码评审

• 研发单元测试
  

• 团队业务需求沟通及评审

• 测试用例编写

• 测试用例评审
  

• 基础功能测试验收
  

• 上线发布验证
  

• 灰度测试
  

• 线上验收测试

• 自动化冒烟测试

• 每日自动化测试
  

2）稳定性建设

• 关键业务流程日志打点
  

• 全业务链路跟踪
  

• 系统技术指标监控
  

• 系统业务指标监控

• 告警

• 自动化告警恢复
  

• 关键业务场景预案建设
  

• 关键业务场景预案执行
  

• 值班响应机制
  

3）风控建设

• 业务风险点定义

• 业务风险点识别

• 业务风险点级别定义
  

• 业务风险点分级处理

• 业务风险点报警

• 业务风险点触发趋势

• 实时业务风险控制

• 离线业务风险扫描

• 业务风险点诱因分析
  

团队方面

• 成员 1v1 沟通
  

• 成员优劣势分析

• 成员做事意愿分析

• 成员角色定位对焦
  

• 成员能力梯队聚焦
  

• 方法论的探讨与实践

• 帮助不同的人看到自身不足，定制不同的成长规划
  

• 根据不同人的优劣势和做事意愿，安排调整合理的事情和责任范围，激发做事的主动性，为其发挥出创造力营造良好的环境

• 业务大图的解读和 KPI 的设定
  

• 工作原则和工作要求达成一致认知
  

• 明确团队要什么，不要什么，推荐怎么做，不推荐怎么做
  

• 要创新不要墨守成规
• 要思考不要苦劳
• 要打破思维定式和束缚，不要自我设限
  
• 要 Ownership，不要推脱
  
  

如何成长为技术一号位

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

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

更多精彩

识别二维码领取创业加油礼包

点个在看，让更多人看见