原文地址：http://mp.weixin.qq.com/s/Lb-y-H1g8DLZqnXs6zqfuQ
当绝大部分的技术人还在思考创业团队 CTO 需要有什么胜任力的时候，有人已经把技术团队从 7 年前的不足 10 人带到了千人规模的技术团队。
聊起这 7 年的经历和故事，远比在纸上讨论“CTO 是否要写代码”要精彩得多。现实中的 CTO 面临的挑战也不止于技术挑战，还有业务挑战、团队挑战、视野挑战等等。
9 月 9 日，51CTO 旗下 CTO 训练营第五季的开营课上，国美互联网 CTO 于斌平为现场的 40 位技术管理者分享了他在国美 7 年的 CTO 经历以及对 CTO 七大基础能力的理解，从这些经历里面我们也可以窥见一些领悟。
CTO 七大基础能力
能力一：核心目标管理
明确公司目标，充分理解业务，技术目标与之配套
01
与公司目标一致
作为 CTO，要时刻明确公司目标，实现公司目标是首要任务。其次才是与之配套的技术目标。
02
充分理解业务，比业务更熟悉业务
如何让业务增长，是每个做技术管理的人都要考虑的问题，也是最根本的价值体现。
每个小团队的业务/技术人员只需了解所负责的业务即可，但作为 CTO 要比这些人更了解业务，了解每个业务的同时还要把所有业务串起来，明白整个公司的业务和规划是什么样。
03
支撑业务，引领业务发展
大家常说，互联网行业技术要引领业务，但支持业务正常开展是基石。在业务正常开展的基础上，才能站在未来看现在，才能进一步创新，通过技术驱动/引领业务发展。
在核心目标之下本质的内容，是企业愿景及战略目标、业务目标、技术战略、产品规划、行业分析等战略层次部分和系统架构、系统建设等战术层次部分。
如出现 CTO 和公司/CEO 的目标不一致情况，只有两条路，要么调整到一致；要么离开。
技术管理者充分理解公司目标之后，就是要确立非常明确的技术目标。
主要列举以下几点：
-
整体技术战略目标。
-
眼下要完成的事&近期要完成的事&中长期要完成的事。
-
技术路线&实现方法。
-
技术架构。
-
建立和带领团队。
-
规范、制度、流程。
-
考核方法。
当然，这些内容不是一成不变，而是不断修正的过程。
能力二：项目管理
提炼是“基本功”，合理分解是“基本规范”，沟通是核心
无论有多少个部门、是瀑布/敏捷开发、还是大小的各种目标，所有都可以拆分成件件小事，每件事都可当一个项目来看待。
如下图，左侧是九大项目管理，右侧是四个关键环节。
左侧图中所示的这些技术管理者必备的常见基本技能，大家都已经很了解，在此不一一展开。
右侧是提炼需求、分解需求、沟通、如期上线等四大关键环节：
-
提炼需求。面对老板及业务提出的众多需求，从中提炼出核心的目标是“基本功”。当然是在充分理解业务下的情况下，才能做出清晰正确的梳理和判断。
-
分解需求。提炼出核心需求后，要根据轻重缓急合理的拆分需求，分解成多个项目阶段是“基本规范”。这里等同于敏捷开发过程中的合理迭代，但切记要先上线简单可用版本，之后再纵向切，逐步推进。
-
沟通。沟通是项目管理的核心，管理过程中，沟通对最终结果起到决定性作用。
-
如期上线。项目的最终目标是“如期上线”，否则之前做的所有事都是白用功。“如期上线”不是简单的上线完成任务就行，质量和成本一个都不能少，尤其是质量不能忽略。
更不能为了上线而上线，表面上上线完成了项目，但实际跟原来的目标相差很远，甚至用户都没法使用。
其中，沟通、资源整合和成本控制这三方面无论项目大与小，都贯穿整个管理过程，且对于大多技术管理者来说，多少会遇到一些难题，下面分享一些方式方法。
01
沟通
前面说到，沟通是项目管理的核心，但很多技术管理者并不是很擅长沟通。
面对不同的人，要如何进行沟通呢？方法如下：
-
与职级高的人。提倡跨级沟通，但需采用一些技巧，如发送邮件同时抄送直属领导；如和直属领导打招呼，再去汇报；如非正式，“恰巧偶遇”，不经意提及；如从团队中找到善于沟通的人去做沟通。
-
与职级相同人。和同级别人沟通，就需要把技术语言翻译成非技术语言，以便业务、财务等不懂技术的管理者更好的理解。
-
与团队和下属。初创/互联网公司与下属的沟通相对开放，职级的观念相对较小。但对于大型传统的公司来讲，下级会对上级不自然产生戒备/恭敬的心态。技术管理者需要做的是先缓解心态，之后像朋友一样坦诚的去沟通。
-
与合作商。与合作商沟通，要时刻谨记自己代表的是公司，然后是合作共赢，找到利益平衡点，把可能的情况先谈清楚了，避免后续一些不必要的麻烦。
02
资源整合
一个项目完成与否，资源会从中起到很大作用。资源在未整合之前大多是零散的，要发挥其最大的效用，转化为竞争优势，为企业创造价值，还需要运用科学的方法将不同来源、不同效用的资源进行配置与优化，使有价值的资源融合起来，发挥“1+1>2”的放大效应。
业务、营销和财务这些属于企业内部资源，合作商、市场和投资方属于外部资源，这些大家都很了解。这里需要注意的是直属领导/领导的领导是很好的内部资源，用好会事半功倍。
03
成本控制
很多人感觉做技术管理和成本没有关系，成本是采购才会考虑的问题。
实则不然，例如：
-
时间和人力。如一个项目管理不善，因工作效率或其他原因，导致不仅超时完成，还用人过多，这是看不见的最大成本浪费。如一个项目研发三个月，最终没有上线放弃，这也是一种成本浪费且还可能丧失机遇。
-
招聘牛人。要招聘当前需要的人，一些技术牛人可能未必适合当前阶段。初创小公司不需要很牛的人，只需要成熟技术，能支撑业务，保障业务的正常运行就好。当业务达到一定量，才需要招聘牛人，反之就是成本浪费。
-
超前技术。很多时候，时间和人力的浪费，就是因为招聘牛人，研究超前技术所致。所以在每个阶段，需考虑技术是否合适。
-
技术方案。不要迷信最好的技术方案，根据实际情况，采用最快方式实现目标。
综上分享的核心目标和项目管理是做技术管理最基础的胜任力，下面我们来分享作为CTO必备的看家本领，如下图：
如图中所示，一名合格的 CTO 必须具备的四大看家本领分别是架构建设、产品能力、研发能力和基础建设。
能力三：架构建设
CTO 应该精通大架构，不是仅仅单一的技术架构
提及架构，很多人认为是代码的架构，涉及方向也是采用哪种框架，是开源还是自研等。这里分享的架构是作为一个 CTO 应该精通的大架构，如下图：
-
业务架构。业务架构是 CTO 应该首要知晓的，就是所处公司的业务组成及发展规划，清楚具体业务，以及它们之间的关系，是相关，还是独立等。
-
应用架构。对应业务，决定采用什么样系统配套支持，是要采购，还是必须自研，是纵向独立划分，还是横向逻辑划分。
-
数据架构。一定要了解数据流的现状，很多技术牛人会忽视数据架构，对于数据如何存储、如何流转、安全机制都不是很了解，往往信息安全问题，就是因数据流出现状况所致。
-
技术架构。这里就是有些系统架构，如代码框架、中间件、服务治理等。
-
运维架构。进行运维建设、安全建设等，做好风险控制，针对系统、账户、财务做好安全保障。
从业务、应用、数据、到技术、再到运维整个贯穿下来，就是做 CTO 应该有的视点，切记不是仅仅做单一的技术架构，那是架构师或研发主管应该做的事情。
如下图，是电商行业基本的技术架构：
如图中所示，用户层/流量入口、业务单元、应用系统、业务服务、中间件、平台层，这一层层逐级下来是一个很清晰的电商行业比较通用的架构。作为 CTO 要清楚每一层的数据流、运行机制，由哪些人在主导，关键负责人是谁。
如下图，是架构设计原则：
做开发的人对于这个图都很熟悉，可用性、可扩展性和成本这三大原则大家应该都很了解，这里不一一展开。
作为 CTO 要走在前面，在扩展、成品和可用三者制约的情况下，架构要如何建设?
建议遵循 DID 原则，按照 20 倍体量去设计，因会遇到如双十一等流量猛增的情况。之后，开发按照 3 倍的体量去实现，上线按照 1.5 倍的体量去部署。
能力四：产品能力
交互和业务逻辑是基本功，懂技术实现和项目管理是升华
作为 CTO 首先要很清楚研发的系统/产品，最终用户是谁？根本诉求是什么？之后才是用户体验、业务和产品的设计及产品创新。一定切记，从用户、业务、运营的三个角度出发去设计产品。
01
用户体验
产品整体要简约而不简单，提供给用户应该是视听上的体验，还要强调舒适性。操作方面，要尽量满足易用/可用性。目标信息尽可能的醒目而亲近，让用户能认同、抒发自己的内在情感。
02
业务设计
要充分理解产品背后的业务逻辑，基于市场目标和公司业务需求，梳理业务流程，勾画业务蓝图，设计业务场景及功能，分析和优化流程。业务、财务、数据、用户操作等设计要尽可能形成闭环。
03
产品设计
依据业务蓝图和功能设计软件产品，重要的是如何让用户用的“爽”。最后的输出结果才是 PRD（是结果不是目标）。
04
产品创新
创新方面，要以潜在的需求为出发点，开发出具有差异性或全新的产品，将潜在的需求激活为一个现实市场，实现产品价值，引领/驱动业务发展。要清楚产品上线仅是开始，还需以数据为检验标准，不断运营和优化。
这里需要提醒的是，有的产品经理侧重于交互，但对业务逻辑不是很清楚。有的产品经理很明白业务逻辑，但交互方面较弱。
一名合格的产品经理，交互和业务逻辑是两大基本功，在此之上，还要知道产品如何技术实现、也具备一些基本的项目管理能力。
走的相对较远较顺的产品经理，一定是对上要懂 CEO，对外要懂市场、懂用户，对中间要懂业务，在实现方面还懂一些开发的逻辑。
能力五：研发能力
不是某位技术牛人，而是团队整体多方面的调整与标准制定
谈起研发能力，很多人会想我就是一个技术牛人，可以一人顶几人。但是当项目很多的时候，又能顶几个呢？
所以，从技术牛人晋级 CTO，还需要在关键技术、交付效率、代码规范和开发模式等方面做很多调整和标准：
-
关键技术。作为开发领导最好能亲自制定代码框架，确定使用哪种技术框架或者方案。要始终保持学习最新的技术及资讯，至少在理念上与行业同步。还要不间断的研究技术。
-
代码管理。制定合适的代码管理规则，制定合适的分支模式，并建立代码管理规范。
-
规范标准。需要在项目早期建立一系列的编码规范、接口规范、中间件使用规范、加密规范、密码规范、字符集规范等等。
-
开发模式。用敏捷还是瀑布要依照实际情况而定，对于轻量级的需求，或研发人员较少的情况下，可采用敏捷开发模式。当业务很重，就选择瀑布模式，把项目规划清楚，做好细节拆分，可规避需求不匹配的情况。
-
开发质量。要实现代码 Review 机制、单元测试机制、持续集成、自动构建和自动发布。
能力六：基础管理能力
从传统响应服务向自动化、可持续集成提升
基础管理能力，更多是体现在运维方面，服务器宕机，网络不通，如何配置/部署/监控等都属于运维范畴。
早期运维是 ITSM（IT 服务管理），侧重流程，是一套帮助企业对 IT 系统的规划、研发、实施和运营进行有效管理的方法。
布设总服务台来监控，出现故障后服务台负责通知相关开发人员，响应机制和绩效挂钩。ITSM 整体过程很流畅很严格，但它的缺点是事后的管理。
现在提倡 ITOM（IT 开发运维、运营管理），侧重 IT 运营管理，从开发设计开始就考虑上线后如何运维，如何设计代码架构、部署架构，如何发现问题，发现问题后如何自动故障转移和修复，包括申请资源、建设配套的 CMDB-DCMS 等。
ITOM 更侧重于一个 IT 运营或者运维的管理思想，目标是持续交付和自动化运维。
整个运维的流程大致由四步构成分别是：
-
服务监控。硬件、软件、流量、数据、故障的自动化监控。做好问题和故障反馈机制及故障响应机制、处理机制。此外，还需设计故障预案，实现预案的自动化执行。
-
配置管理。包括集群、部署、变更等管理。
-
硬件管理。网络及服务器架构，VM、资源分配机制。
-
运维机制。自动化部署、自动化运维是基本目标。还需建设日志平台，报警机制及相应处理机制。
如下图，是我们的基础架构（GCP）：
能力七：团队能力
拥有团队能力的基础上，还应了解学习一些领导艺术
团队能力部分，主要总结六点，如下图：
作为 CTO/技术管理者具备团队能力的同时，还应该了解一些领导艺术。这个时代的比拼不仅是兵对兵，更是将对将的较量。
只有领导的能量不断放大，团队的竞争力才能整体提升。也可以说，领导之道是现代化竞争中的核心要求。
领导艺术主要体现在三方面分别是：
-
多个部门的协作。合理选择，知人善任；扬长避短、宽容待人；合理使用，积极培养；用人要正激励人才。
-
工作效率的提升。统筹兼顾、把握关键、指令明确；决断及时；想象力、洞察力、应变力、善于调动他人的积极性。
-
快乐的工作。平等待人，尊重别人，注意方法；简化语言，积极倾听，控制情绪；把握主动；创造互信环境。
啥样的人能晋升 CTO
最后，啥样的人能晋升 CTO？个人认为，晋升 CTO 主要看三方面：懂技术、懂管理和修炼。
懂技术
CTO/技术管理者自始至终都要懂技术，不断地研究学习新技术，才能够带领技术人员往前冲，对团队给出有高度的建议和合理的技术架构、技术方向的判断。
懂管理
技术再牛，不懂管理，不知道核心目标，不能理解业务，不知道怎么管理人，也不是优秀的 CTO/技术管理者。
修炼
技术和管理是基石，修炼是一个长期的过程，个人的视野和能力修养通过不断历练才能升华。
站在山下跟站在山腰看到的风景不一样，站在山顶看到的风景和感觉又不一样，从山脚到山顶的路途肯定不平坦，付出的不仅是汗水和努力，不经历风雨，如何见彩虹。
这所有的过程，都是历练，也是修炼。“横看成岭侧成峰，远近高低各不同”，“五岳归来不看山，黄山归来不看岳”，这形象的反映出了一个人的境界。
总之，不会打仗的士兵，做不了将军；只会打仗的士兵，也做不了将军；CTO/技术管理者晋级之路就是不断学习，历练、升华的过程。祝各位成功！
作者：王雪燕
编辑：陶家龙、孙淑娟
本文选自CTO训练营