菡萏如佳人CTO结构
这里的CTO结构是指一个合格的CTO所具备的技术能力(知识)的结构。
什么是CTO
看到这个问题，是不是有人想啪啪的打脸了？上周大家讨论分享时都提过了什么是CTO，有人还给出了CTO的杰出代表人物张志东。怎么又问一遍？
是的很多人的回答相信都是Chief Technology Officer企业内部技术最高负责人。很多中国企业还会有技术总监，CIO（Chief Infomation Officer）首席信息官。
那到底技术总监，CTO，CIO之间有什么相同点和不同点呢？我查阅了关于三者的详细定义，总结出了三者主要的区别如下：
技术总监：重点在技术本身（偏向术的层面）
CTO:公司产品与技术结合过程（偏向法的层面）
CIO：重点在信息技术，业务方向（偏向道的层面）
那么目前所有的公司都是严格按照三者的定义来任命人员和执行方针的吗？很遗憾，很多公司都不清楚三者的区别，甚至混用三者，常常张冠李戴。一般从事IT的人员都分不清三者的准确定义和具体职责，更加不用说公司HR部门了。所以建议大家不要去纠结于这几个名词了，我们今天要讲的CTO就是复合型技术管理人才。
T型结构
我们看下几个有趣的观点,看看大家支持哪些观点。
- 不懂业务的CTO没有未来
- 只懂技术的CTO不是好CTO
- 写代码CTO不是合格CTO
- 不写代码CTO不是合同CTO
各种观点层出不穷，论据极其丰富，看后感觉都非常有道理。
怎么样？肯定有你支持的观点和你不支持的观点吧。其实无论你支持哪个观点，只要你用心，你都能找到大量的论据和事实来支持该观点。而我觉得以上这些观点都是正确的（先不要打脸，请听我说完）。
为什么呢？因为大家忽略了说这些话人当时所处的背景。就像我们使用的语言，如果脱离了上下文语境，听者能get到的含义会是千差万别的，因为每个人会根据自身的情况来判断这句话的含义。
说这些话的人，他们只是站在他们的成功经验之上和你娓娓道来，而你却不知道他们的上下文语境。所以如果你不认同上面的某个观点，那是因为你所处的环境或上下文和说该观点的人不同罢了，如果你赞同某个观点，那也只不过你所处的环境和上下文恰好和说该观点的人相同罢了。所以不同的团队，不同的公司规模，不同的业务发展阶段CTO扮演的角色是完全是不同的。
我举个非常著名的例子来加深大家对该浅显易见但又常被忽视的常识盲点的印象，注意粗体文字部分
1 玛丽曾有只羊：强调是玛丽，不是别人
2 玛丽曾有只羊：强调是曾经，不是现在
3 玛丽曾有只羊：强调是羊，不是其他动物
在软件开发过程中，一般做到小组长或者团队管理者肯定扮演过需求人员和coder的双层角色，一方面你会和甲方或者其他部门来沟通业务需求，另一方面你需要编码来实现业务逻辑。随着团队的扩张或者业务的熟悉，你工作内容中沟通者的角色会慢慢成型，且实际编码减少，需要结合原有业务功能，对新业务进行设计，所以设计师角色又慢慢浮现；
当然如果你们公司有结对编程或者良好开发规范的话， 你还需要编写单元测试来检查自己或其他人的代码；随着对整个系统的深入了解以及编码，网络，系统部署等技能拓展，你有可能担负起来架构师的角色；当然也有可能你不是一个纯粹的极客，你更喜欢把控项目的进度和协调各部门的工作，毕竟与机器斗，会变得又呆又萌，与人斗才其乐无穷嘛~所以你成了一名出色的项目经理；也有可能你不想当程序猿了，于是转职成了产品狗；随着你各方面能力的成长，你终于成为了你一开始最讨厌的那些人（给你分配需求和任务的人）你成为了产品，业务，技术的决策者；甚至成了战略的制定者。
在你职位维度不断发生改变的过程中，相信你的思维方式一定发生了转变。你不可能用程序猿的思维做着产品经理应该做的事或者用程序猿思维做着产品战略制定者做的事（当然每个程序猿都希望按照自己的意愿来开发产品）。
谈到这里，其实想表达的是不同职位维度，需要的技能是不一样的，最本质的区别是思维方式的转变。以上这些角色要干的活，作为一个CTO可能都会做过。比下面这四个阶段，比较简单的表示了一个小公司发展过程中CTO思维转变过程：
- 阶段一：创业萌芽期，加上CTO程序猿可能总共就3个，CTO更加关注的是技术和业务
- 阶段二：创业成长期，人开始多了，得花时间做下团队管理了，当然最主要还是技术啦
- 阶段三：创业发展期，产品获得了市场认同，需要参与到产品战略制定了，人多了队伍不好带了，业务复杂了，精力也分散了
- 阶段四：创业成功期，市场越来越饱和了，战略方向越来越重要了，你已经几乎不参与技术会议和实际编码了
当然不是每个CTO的成长之路是都如此，且公司到了一定规模，CTO也可能不只一个了，每个业务模块或产品都可以配备一个CTO，你可能成了公司技术VP。但要注意本文里说的CTO并不是传统狭义上的CTO，它包含的是具有管理职能的技术人才，不局限与具体的职位名称。
接下来我们看下技术维度，我们一般是怎么成长的。
先学会一门编程语言，从基础的语法糖和基础API类库开始，然后开始考虑多线程编程以及性能安全方面的问题，接着会了解到程序自动化构建、部署，接着从内网走到外网，开始了网络编程，随着编程经验的累计，开始学习总结一些编码技巧，设计技巧，熟练掌握设计模式，并开始学习大数据和分布式开发，也编写了一些适合自己公司业务使用的小架构......
整个的技术横向来看是不断拓展了软件开发流程知识，纵向来看是不断加深的编程技艺。整体刚好是一个T字型，这就是CTO技术能力的T型结构。总结来看就是：基础夯实+元程序思维法
这里的元程序也可以套用我们在学习编程课程时的一个公式：程序 = 数据结构 + 算法
不过这里的数据结构和算法的概念，需要做个扩充，以前的数据结构或算法我称之为狭义的。
这里数据结构包含了：狭义数据结构，领域知识，基础API，计算机基础（I/O,DB,OS等）
这里的算法包含了：狭义算法，常用框架，设计模式，设计思想（AOP,IOC）
Y型结构
接下来我们看看T型结构。一般我们学习一个新知识的时候，聪明的大脑都会拿我们已有的存量知识与新的增量知识建立联系，以此来方便记忆。
比如我们开始学TCP协议的时候，很多人都会记得一个名词叫三次握手，而我个人却喜欢用打电话的场景来记忆，因为我个人觉得打电话互相确认身份再传递信息和TCP三次握手很相似。再比如我在讲解DH算法的时候，如果直接从原理或者MOD运算上去演示，那么很多人理解起来会有困难，所以一般会采用一个颜色混合的比对动画先来讲述清楚其本质原理是如何的，最后以数学计算的方式进行一次讲解。一般大多数人就能够理解DH算法了。还有一个例子是本人在做代理商技术培训的时候，向大家介绍云合同安全体系时，通过人体免疫系统三层结构与云合同安全体系一一对应进行讲解，让不懂技术的人也能够获得大概的认知。
所以我们可以发现，无论是我们自己学习新知识，还是向他人传授我们已经掌握的知识，其实都是需要将A学科的知识映射到B学科来进行理解或讲述。从PPT中我们可以发现，它们之间天然的形成了一个Y型。
所以一个CTO（其实应该是每个优秀的人）所掌握的知识应该是TY型结合的方式，在T的横向上是各种领域知识的拓展，在T的纵方向上，是由专精的知识组成，且这些知识要能够和其它知识建立一种内部联系，由一个个小Y组成了T的纵向。
用一句很流行的语体来结束本章节的内容：不懂量子力学的产品经理不是好CTO 。所以单单掌握高深的技术还不能成为一名合格的CTO，你的高深技术能不能通俗易懂的讲出来？能不能和其它领域的知识做到触类旁通，才是成为一名好CTO的必要条件。
