作者丨胡键
编辑丨小智
对于CTO的概念，即使是CTO们自己也很难有一个统一的定义。而今年发生过的一些大事件，更是让技术人围绕这个名词热议不息。CTO这个职位，跟技术总监有什么区别？本文转载自「老胡闲话」，已获授权。
2015年9月，我们获得了一笔千万级别的投资，公司由西安搬到了杭州。这一年，我的Title也变成了CTO。
很早以前，技术总监和CTO在我的眼里并没有什么分别。当时，我天真地认为，这两个词不过就是同一种身份的不同叫法，都代表了公司内技术上最牛的那一个人。可是，后来发生的两件事让我意识到我的想法大错特错。
第一件是在一次西安社区活动之后在TW附近的饭馆吃烤肉，当时我已经部分介入到目前公司的一些开发事务中，负责整个系统的技术架构和开发管控。在听我说完我对开发团队所做的工作之后，朋友仰头喝下一杯啤酒，说道：“那你相当于是CTO，而不是技术总监。”这句话对当时的我来说，就像投向平静水面的那颗石子。
第二件则是今年闹得沸沸扬扬的“冯大辉丁香园离职事件”，吃瓜群众自动自发地发起了一场关于CTO职责的大讨论。此时，我已搬到杭州。也就是这一事件，让上面的那次对话又浮现在了我的眼前。这已经过去了好几年。
现在，我依旧无法很清楚地说明白两者的区别，但我至少知道了两点：
这样看来，我的Title也多少是名副其实的了。然而，在初创公司哪里能分得了这么清楚。顶着CTO的帽子，做着技术总监、项目经理，甚至程序员工作的人不在少数，我也不能例外。
我这一年的时间线
按照时间线来看，我这一年还真干了不少事情：
2015年7月，投资消息得到确认。但随之而来的就是面临公司需要搬迁的问题，为了给一直以来同甘共苦的弟兄们有交代，同时为了保证公司搬迁之后的开发不受招人等事务的影响，说服公司保留西安，并说服部分开发人员跟我一起去杭州开拓新大陆。
2015年10月，新公司成立之后的第一个发布正式上线。在随后的开发中逐步明确开发规则：搭建CI环境、Ticket管控、迭代周期、发布前演示……开发也慢慢走上正轨，由于开发队伍长期合作培养的默契，两地开发并没有成为一个明显的障碍。
2015年11月，回交大招人，但没有招到合适的开发，主要集中在运维和UI设计。
2015年12月，平台基本成型，涉及的主要业务均能在线上走通。在这个过程中，说服开发队伍认同并接受“快速迭代、快速调整、每次可用”的思路。说的直白点，这个过程相当于在航行的同时把船由小造大，边开船边更换零部件。
2016年1月，杭电招人。
2016年3月，有感于开发队伍技术薄弱，并且缺乏学习的方向，整理出公司开发队伍的“技能图谱”。
2016年4月，业务层的开发已经上轨道，我不再关注这部分的内容，转而将精力放在接入层。随后对这部分进行了大规模的重构，以应对未来大量设备的接入。引入了消息队列和集群处理，测试效果还行。
2016年5月，鉴于公司硬件产品本身就是基于工业标准（Modbus和CAN），提出工业云的概念，建议公司跳出压缩机行业。主攻工业设备接入和运行数据存储，同时提供Web API。
2016年6月，几位老员工因个人原因离职，包括硬件团队负责人。虽无限感伤，但也不得不坦然面对。临时接管硬件团队，同时搭建了外部的技术支持力量，包括硬件兼职人员和与外部公司硬件团队负责人的长期联系。
2016年7月，随着设备数据的积累，原来作为存储支撑的MongoDB渐渐有些吃力，考察再三之后，决定弃用Mongo转向HBase，同时引入实时数据的DownSampling。注：这里不能完全归咎于Mongo，我们之前因经验不足导致的设计缺陷也是让这一问题最终爆发的原因。未来会专门撰文详述这一过程。
2016年8月，实时数据库的底层存储变更完成，效果不错，查询速度也较之前快一个数量级。
2016年9月，苦闷于业务发展不令人满意，深度反思，指出开发队伍只顾埋头开发不问世事的风气。同时内部明确提出业务的优先级。
2016年10月，跟运营部门一起重构服务市场，将其改造成面向经销商的服务管理SaaS。市场出现正向反馈。
从这份“草根CTO创业1年大事记”中，不难看出我把主要精力放在了三个方面：项目管理、技术管理和团队建设。
一直以来，我自认为是一个不错的项目经理，不仅表现在过往参与的项目都还不错，也表现在跟甲方（国内某大型国企）和合作方（国际知名IT咨询公司）的关系也能处理妥当，建立起了不错的私交。即便后来进入外企，也在人数相对减少Release增加的情况下，利用有限资源制作一些自动化工具，设法按期完成交付。而这一次，作为项目管理者，我主要确立了以下几条规则：
凡代码变更均有Ticket
自动化测试代码 + Jenkins CI + 基本的部署自动化 + 基本的运维自动化
基于Gitlab的代码提交和协作：Branch-per-Feature、Merge Request、MR触发CI、主库 + 开发者库 ……
建立开发节奏，每两周部署3个平台：Web + Android + iOS
建立起与业务运营团队的沟通机制：计划会议和发布前评审
在初创公司，当然没法要求所有规则都如大公司一般严谨和教条，但基本雏形已经具备。这一切都是为了让队伍养成良好的习惯，以便我们能走得更好，同时也更远。
作为技术管理者，技术选型和架构设计自然是主要工作，但除此之外，对于初创公司而言，我还做了以下自认为重要的两件事：
后期，开始尝试建立公司内部的技术委员会，开始考虑将队伍分拆成业务组和平台组。
讲到团队建设，这可有点伤脑筋。一方面，就工作而言，我不是一个太好相处的人，因为我对代码和技术有要求，而且标准不低，看到垃圾代码会难以抑制住心中熊熊怒火，有时会让小弟们比较难堪；另一方面，我也是一个好相处的人，比如我不是那种小心眼的领导，跟团队的人吵完架之后还能照常一起把酒言欢，该涨工资自然会给你涨，基本能做到对事不对人。而且我自己虽然八卦，但我极度厌恶那种打小报告的人和风气。
所以呢，能适应我的人大多能跟我保持不错的关系。而那些不适应的呢，则会渐行渐远。正是这种不够圆滑的性格，或许给团队的某些人带来了一些伤害，在此，我说声抱歉。
总的说来，我今年在团队建设方面做得远不如其他两方面，表现在：
没能在杭州建立起一只跟西安旗鼓相当的技术队伍。这固然有一些原因在里面，如初到杭州人生地不熟，滨江的招人环境不佳等等，但无法抹杀事实。
虽然做到了让团队意识到自己的不足进而开始有自我提高的意识，但远远低于我的预期。
团队的激励制度做得不够，这或许是团队自我驱动力不足的主因。
信任和放权做得太晚，目前看来如果能早点将担子交给年轻人，整个团队的精神面貌要比现在更上一个台阶。
看到这里，请不要误解我们的技术队伍是一只缺乏生气和向心力的乌合之众。若真是如此，他们不会在公司融资前最艰难和最黑暗的那一段时间依旧守卫在公司身旁；若真是如此，他们不会在公司获得投资需要移师杭州之时，跟着我一起背井离乡；若真是如此，他们也不能保证开发节奏，每2周交付3个平台的功能。
这不过源于我贪得无厌的高标准，以及他们尚属稚嫩的人生经历。
我这一年的得失
纵观这一年，我作为CTO的第一年，我开始意识到“授人以鱼不如授人以渔”，有意识的促进团队的自我思考能力，而非像以往一样，强行贯彻我的思路。
传播项目管理知识，同时说服团队接受并适应“在行进中开火”、“边开船边造船”的工作思路。
在后期，让团队意识到业务并非只是业务运营团队单方面的职责。让开发团队开始关心关键的运营数据，以此来评估开发效果，并且鼓励开发人员参与业务运营方面的讨论，而非单方面对业务需求“有求必应”的态度。
向团队灌输怀着“尽快验证失败”的心情去做某一个功能，在这样的思想指导下，自然会以最经济的方式去实现功能。当效果不佳，直接丢弃就好；若相反，则着手深耕细作。力求把好钢用到刀刃上，避免一上来就进行一个大设计。
让团队意识到自己的不足，知耻而后勇，开发人员开始意识到自己的代码难看，知道要重构代码。
说到底，就是营造一个好的环境和好的土壤，我认为这是作为管理者最重要的工作。
同样也在这一年，我最大的失误在于：对业务介入太晚，甚至一开始怀着嫌麻烦的心态主动避免。在此，我并非要对业务运营取而代之，绝非此意！现在看来，我至少在几个方面做得不足：
虽然我们很早就添加了如百度统计分析脚本和ELK日志分析，但并未很好的利用它来指导业务运营，同时没有为业务运营团队提供有价值的建设性意见。而只是简单地将它交给运营团队，并未给出技术方面的指导。
作为联合创始人之一，没有很好地帮助公司明确战略重心，整个队伍对公司的业务重点没有形成统一的认识。
在外围技术合作伙伴方面推进乏力，而只是沉溺于新技术的研究，说到底是躲在舒适区自High。
在技术大幅领先业务时，没有正确使用这种力量去拓展新业务线，以巩固公司的局部优势。
一言以蔽之，缺乏创业维艰的那根弦，想的多做的少。所幸，今天的我已非昨日的我，只是这一切的代价有点大。
2016年11月，我又回到了西安，心态归零，重新出发。
胡键，超过15年的从业经验，先后就职于各类 IT 企业（从国内外大型IT企业到创业团队）；也负责过软件开发各阶段任务（从研发，架构，PM 到 QA ）。一句话，经历复杂。西安社区活动组织者，曾经的 InfoQ 社区编辑，热衷分享。目前关注于将 IT 技术应用于工业领域，对物联网，大数据，微服务和 MES 有浓厚兴趣。
“双11”过后，各电商巨头对技术表现如何总结？机器学习大热，业务与之结合会擦出怎样的火花？视频直播与新闻资讯，新业务需要怎样的新技术与之配置？业务针锋相对，技术精彩不同，在年终的技术擂台上，各家将展示怎样的技术杀手锏...ArchSummit最后2天倒计时，点击“阅读原文”了解更多！
今日荐文
点击下方图片即可阅读
究竟什么样的技术 Leader 是称职的？
喜欢我们的会点赞，爱我们的会分享！
