政务网站建设工作计划结尾,泰安建设局网站,电子计算机哪个专业最吃香,资阳优化团队平台前言 什么是技术一号位、有哪些关注点、怎么做技术一号位#xff1f; 做了研发团队的技术 leader 以后#xff0c;要处理的事情非常多#xff0c;如果对自己扮演的角色没有一个清晰的认知#xff0c;就会出现该做的事情没有做#xff0c;不该做的事情投入了过多的精力 做了研发团队的技术 leader 以后要处理的事情非常多如果对自己扮演的角色没有一个清晰的认知就会出现该做的事情没有做不该做的事情投入了过多的精力造成实际行动和结果既不匹配上级的要求又不匹配下级的期望。特别是对于刚开始带领研发团队的新人 leader 而言角色的转换和适应的过程增加了认清自己的角色本质的难度。今天我们抛开纯技术团队的同学不谈其实本质一样只讨论业务研发团队的同学如何以技术一号位的角色来做事。 如何识别自己是不是技术一号位 在开始谈如何做事之前首要任务是判断自己是不是技术一号位而要判断之前首先要明确判断标准跳出思维误区。这里我们列出一些常见的思维误区。 以下是常见认知误区
带人的是技术一号位不带人的不是技术一号位。级别高的是技术一号位级别低的不是技术一号位。以上的认知误区错误地把是否带团队、技术等级的高低和是否为技术一号位关联起来。虽然事实上带团队的业务研发同学成为技术一号位的概率更大但是本身这两者不是划等号的关系。 那么什么是区分是否为技术一号位的决定性因素呢很简单对一个具体的业务而言你作为该业务的直接技术参与者是否处在技术领域责任链的最顶端。这句话翻译过来就是对一个明确的具体的业务而言多种角色的同学一起合作的时候你是否是技术序列的最终责任人即谁承担对应的责任谁就应该扮演对应的角色。 当产品经理、运营、研发共同做一个业务的时候某个研发同学独自或者带领其他几个研发同学或者带领跨 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不要推脱
如何成长为技术一号位 目前还不是技术一号位的业务发开同学虽然现在的岗位只负责一小部分但是本质上来讲只要你负责某个事情那么不论这个事情大小你都是这个事情的技术一号位只是由于事情的难易程度和规模大小导致很多可能需要做的事情其实并不需要做但是这些问题并不妨碍你知道技术一号位要做什么应该怎么做更不妨碍你以技术一号位的心态去做事。 先确定好心态的问题以后接下来就需要一些可以被实践检验的方法论来帮助大家打破自己层级的束缚完成自我突破从而在成长的基础上获得负责更重要的事情的机会通过做好更重要的事情来获取更更重要的事情的机会这样一定会在某个阶段你负责的事情需要完全以真正的技术一号位的角色去落地那么那个时候扮演技术一号位的角色也就是水到渠成的事情了。 作者介绍 贺科学晨末毕业于北京科技大学工作10年在企业级应用架构及研发方面有长期积累。擅长分布式系统架构擅长复杂业务的领域建模及开发落地掌握领域驱动设计及开发相关方法论有实际成熟线上产品案例2014年入职阿里云先后参与或主导过阿里云控制台、阿里云容器服务、资源编排服务、云分期等云服务的建设。目前带领小型团队负责新零售业务相关的研发工作累计C端用户过亿承接阿里巴巴集团内外众多流量业务的积分兑换实物商品业务。 除业务以外个人精力也投入在“复杂业务系统落地过程数字化”这一命题上目前有一定思考和实际积累。实际工作中有3年带团队全面独立负责复杂业务系统的经验所以在技术一号位的工作方面有相关的实践和思考。
原文链接
本文为阿里云原创内容未经允许不得转载。
