CTO、技术总监、首席架构师的区别

简介:

经常有创业公司老板来拜访我,常常会拜托给我一句话:帮我找一个CTO。


我解释的多了,所以想把这个写下来,看看你到底需要的应该是啥。


一、高级程序员


如果你是一个刚刚创业的公司,公司没有专职产品经理和项目经理,你就是公司的产品经理,你如果对你现在的开发员能力不满,那么你只需要的是一个高级程序员。


你定义功能、你做计划推进和管理,他可以带1-2个副手把你规划的功能实现了,他是主力干活者,有技术难题也是他来亲自攻克解决。


所以,一个高级程序员,他的职责很清晰:

1、负责核心复杂功能的实现方案设计、编码实现

2、负责疑难BUG分析诊断、攻关解决


二、研发Leader


公司再长大些。如果你就有一个研发团队(含产品/开发/测试),你就一套主产品,而且你的研发团队小于15人,那么你需要的就是一个研发Leader。


因为你已经有了1-2个高级程序员,核心难题攻克和核心功能研发进度与质量保证,已经可以靠他们自身能力解决掉了。那么你需要研发Leader干什么。


研发Leader的职责是:

1、团队任务管理:开发工作量评估、开发任务分配

2、团队生产质量提升:代码审核、开发风险识别/报告/协调解决

3、团队生产力提升:代码模板研发与推广、最佳实践规范总结与推广、自动化研发生产工具研发与推广

4、团队专业力提升:招聘面试、新人指导、领导复盘总结改进


三、技术总监


如果你的研发团队超过20人了,而且有多套主打产品线了,你可能已经有了多个研发Leader了,那么你需要一个技术总监。


技术总监的职责:

1、组建平台研发部,搭建公共技术平台,方便上面各条产品线开发。


2、通过技术平台、通过高一层的职权,管理和协调各个产品线组。现在每个产品线都应该有合格的研发Leader和高级程序员了。


四、首席架构师


因为你已经有了技术总监了,所以技术平台不错了。技术平台和各条产品线的协调互动,也是技术总监管着。


因为你已经有了各个产品线的高级程序员,他们在靠个人能力维持着核心功能模块的开发进度和代码质量。


因为你已经有了研发Leader,所以代码模板研发与推广、最佳实践规范总结与推广,这些事都已经在日常按份内职责开展了。


那么,啥时候需要首席架构师啊。


也就是说,需要分离管理族和专业族了。你会发现,这个阶段你的研发团队已经超过100来人了,需要有人专注来做架构规划、设计、日常维护。不能让研发总监和研发Leader又做管理又做技术一股脑都扔给他们,你就等着总结果产出。这是不对的。


需要从技术总监和研发Leader身上剥离职责了。让技术总监和研发Leader偏项目管理(管理族),把各个模块之间的架构设计工作,独立出一个岗位,就是架构师,来负责。


每个产品线都有架构师,在技术平台部门也有技术平台的架构师。那么,技术平台和业务产品线的架构互动,就是首席架构师在衔接了。让技术平台架构能够和产品业务系统的架构互相促进和支撑,就是首席架构师的份内之事。


架构师的职责是:

1、架构分析:从功能性需求中识别出需要增加的非功能性需求,好满足性能、可扩展、解耦/集成、安全、可运维、高可用、易部署、易更新。并且识别完非功能型需求,还要做技术选型、技术架构风险识别、技术实现工作量评估


2、架构设计与实现:非功能性模块的架构设计、接口设计、代码实现。所以需要的是有代码实现能力还要有架构思维的工程师,不需要画PPT的工程师


3、业务架构设计与实现:需要对跨系统的接口进行识别、实现、维护,需要对能写成公共代码类库的进行分析、识别、接口设计、实现、变更维护。


4、重构:架构师需要经常做Bug分析、非模板性和公共类库代码检查,以发现代码腐烂程度,以发现还有哪些代码没有做很好的架构与精心的代码设计。所以重构是经常性维护发生的,不是攒到某一刻动大手术,甚至推翻重做,那就不叫重构了。


五、CTO


你把架构师团队组织建立完成,再往大长,你才需要真正意义上的CTO了。否则你一开始就招真正的CTO,他也不满意,你的期望也不对。现在你的期望也对了,他的能力模型也正好和你的期望职能匹配了,你能给他的和他想要的也正好匹配了。


有的公司有软件系统产品副总裁,也有软件系统技术副总裁,而且把软件系统技术副总裁叫CTO,软件系统产品副总裁叫产品VP。这就很怪异。


真正的CTO,是软件产品和技术是统一管理的。


他做的事情,是商业、产品、技术、管理、团队相平衡的综合统管。


CTO的职责:

1、业绩达成:洞察客户需求,捕捉商业机会,规划技术产品,通过技术产品领导业务增长,有清晰的战略规划、主攻方向,带领团队实现组织目标


2、前沿与平台:到这个研发规模规模级别了,一定要有专门的团队做技术应用创新探索和前沿技术预研。而且要和技术平台团队、应用研发团队形成很好的联动作用,让创新原型试点能够很平滑的融入商业平台再让应用研发线规模化的使用起来。大量的前沿探索都死在了内部,做完试点就停滞了,这就需要CTO做好整体的衔接推动工作。


3、研发过程管理:站在全局立场来端到端改进业务流程,为业务增长提供方便


4、组织与人才建设:公司文化和价值观的传承;研发专业族团队梯队建制建设、研发管理族团队梯队建制建设;创建创新激发机制,激发研发人创新向前发展,激发黑马人脱颖而出

本文转自  陈小龙哈   51CTO博客,原文链接:http://blog.51cto.com/chenxiaolong/1829600
相关文章
|
5月前
|
设计模式 存储 前端开发
MVVM、MVC、MVP三种常见软件架构设计模式的区别
MVC、MVP 和 MVVM 是三种常见的软件架构设计模式,主要通过分离关注点的方式来组织代码结构,优化开发效率。
123 12
【各种问题处理】X86架构和ARM架构的区别
【1月更文挑战第13天】【各种问题处理】X86架构和ARM架构的区别
|
17天前
|
存储 前端开发 调度
Flux 与传统的 MVC 架构模式区别
Flux是一种用于构建用户界面的架构模式,与传统的MVC架构不同,它采用单向数据流,通过Dispatcher统一管理数据的分发,Store负责存储数据和业务逻辑,View只负责展示数据,使得应用状态更加可预测和易于维护。
|
16天前
|
前端开发 测试技术 数据库
DDD架构中assembler和converter的区别
在 DDD 四层架构模式中,assembler 和 converter 常用于对象转换,但两者在实际项目中的使用较为随意。本文从英文释义、语义区分和模型层区分三个方面探讨了两者的区别,建议按模型层区分,即 Interface 和 Application 层使用 assembler,Infrastructure 层使用 converter,以避免混淆和随意使用。此外,将转换代码抽离为独立方法有助于保持代码整洁和可测试性。
51 1
|
25天前
|
存储 JavaScript 前端开发
Flux 架构模式和 Redux 区别
Flux架构模式和Redux都是前端状态管理工具,Flux强调单向数据流,通过Dispatcher分发Action到Store,再由View更新;Redux则简化了这一流程,使用单一的全局Store,通过Reducer纯函数处理状态变更,使状态管理更加集中和可预测。
|
1月前
|
机器学习/深度学习 弹性计算 编解码
阿里云服务器计算架构X86/ARM/GPU/FPGA/ASIC/裸金属/超级计算集群有啥区别?
阿里云服务器ECS提供了多种计算架构,包括X86、ARM、GPU/FPGA/ASIC、弹性裸金属服务器及超级计算集群。X86架构常见且通用,适合大多数应用场景;ARM架构具备低功耗优势,适用于长期运行环境;GPU/FPGA/ASIC则针对深度学习、科学计算、视频处理等高性能需求;弹性裸金属服务器与超级计算集群则分别提供物理机级别的性能和高速RDMA互联,满足高性能计算和大规模训练需求。
|
3月前
|
机器学习/深度学习 算法 数据库
阿里云服务器架构区别解析:从X86计算、Arm计算到高性能计算架构的区别参考
在我们选择阿里云服务器的架构时,选择合适的云服务器架构对于提升业务效率、保障业务稳定至关重要。阿里云提供了多样化的云服务器架构选择,包括X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器以及高性能计算等。本文将深入解析这些架构的特点、优势及适用场景,以供参考和选择。
阿里云服务器架构区别解析:从X86计算、Arm计算到高性能计算架构的区别参考
|
3月前
|
边缘计算 人工智能 物联网
传统架构与RISC-V架构有什么区别?
计算机架构的发展经历了多个阶段,从最早的CISC(复杂指令集计算机)到后来的RISC(精简指令集计算机)。RISC-V作为一种新兴的RISC架构,以其开放性和模块化设计受到广泛关注。
91 2
|
4月前
|
Kubernetes 关系型数据库 分布式数据库
PolarDB产品使用问题之PolarDB-X的架构形态有什么区别
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
|
3月前
|
程序员
软件设计与架构复杂度问题之战略编程与战术编程的主要区别如何解决
软件设计与架构复杂度问题之战略编程与战术编程的主要区别如何解决