78 lines
9.3 KiB
Markdown
78 lines
9.3 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
166 俞圆圆：合格CTO应该做好的5件事（上）
|
||
你好，我是VPGAME的CTO俞圆圆，感谢极客时间的约稿，让我聊聊CTO的素质与战略这个话题，因为是命题作文，所以在正文开始前还是需要说明一下：CTO的素质和战略虽然有关联，但其实是两个不同的主题。做一个小小的类比吧：
|
||
|
||
|
||
两匹狼来到一个草原。
|
||
第一匹狼感到很沮丧，因为他没有看到肉。这是视力。
|
||
第二匹狼感到很兴奋，因为他知道有草就一定会有羊。这是视野。
|
||
|
||
|
||
素质当然会影响你的战略决策能力，就像视力会影响你的视野一样，但一名合格的CTO不能局限于必须看见了羊，才能判断出一定有肉吃。
|
||
以下想分5个点来和大家具体聊一聊：
|
||
1.技术原点：At the end of the day, 你还是一个工程师
|
||
2.技术方向：工程（Engineering）和技术（Technology），何者优先
|
||
3.技术决策：通过“常识”来做判断，做正确的事
|
||
4.技术外沿：项目做好了，但还有其他的事
|
||
5.技术人才：CTO是技术团队最重要的HR
|
||
|
||
技术原点：你的原点应该还是一个工程师
|
||
|
||
CTO这个角色容易进入2个误区：
|
||
|
||
|
||
认为管理能力的重要性要远重于技术能力。
|
||
认为管人(people management)的重要性要远重于管事(project management)
|
||
|
||
|
||
有人总喜欢用军事指挥官的例子来做类比，声称好的将军不需要自己上前线冲锋陷阵。这样的类比中的逻辑漏洞稍微仔细思考一下就不难发现，但这里我想强调的是：诚然，出色的管理能力是CTO/技术VP/技术总监这样的领导岗位上必备的能力，但“学而优则仕”的逻辑不能僵化引申到技术职场上来变成“码而优则管”。不要盲目地鼓励或同意优秀的程序员转到管理岗，不然你可能收获一个三流的管理者而失去一个一流的工程师。
|
||
|
||
与此同时，我们不能轻视技术能力对于技术领导岗位的绝对必要性。我自己认识和了解的范围内，没有一家成功企业的CTO是一个管理学上的大师但却是技术上的弱鸡。我所认识的优秀的技术管理者几乎都是同时在技术专业领域持续不懈地坚持与时俱进的人。
|
||
|
||
反面的例子我倒是遇见过，几年前曾和某大型跨国电商公司的中国区技术高管一起吃饭，席间这位前辈一直在谈论他的管理艺术，并展示了一些他团队开发的被他称为“之前没见过吧”的厉害系统，我看了以后觉得这样一个企业内部的私有监控告警系统虽然复杂，但也未必就达到“没见过吧”的程度，毕竟那时公有云上类似系统已经是10x的规模了。这之后那家大型跨国电商公司在中国的业务节节败退，被很多本土的后起之秀（有阿里、京东也有后来的唯品会、拼多多等）抛离，而这位前辈也淡出了技术圈。
|
||
|
||
总之，CTO绝对不能放下技术，而技术能力的养成没有什么捷径，只有不断学习与时俱进，才能不至于“不知有汉，何论魏晋”。
|
||
|
||
有人说我也想继续学习新技术，但实在没有时间，管理上的事务已经忙不过来了。我比较好奇的是，Jeff Dean管理Google Brain 3000人的团队，每周尚有时间自己写代码，难道你管理的团队超过3000人了？
|
||
|
||
在《技术领导力300讲》专栏的文章里，我写的第一条居然不是什么宏大的管理理念，还是在唠叨敲代码，可能感觉有点怪异，但我确实是想说，在技术人员成长的这条道路上，不论我们去往哪里，我们都不应该忘记自己的原点。在我们承担起团队管理职责的同时，我们能否保持这样的自律：
|
||
|
||
|
||
每年学习一种新的编程语言
|
||
每年深入关注一个新的技术领域
|
||
|
||
|
||
技术方向：工程（Engineering）和技术（Technology），一体两面
|
||
|
||
虽然自己是TGO的会员，但该吐槽的还是要吐槽的：曾经参加过一个TGO的辩论活动，题目好像是“创业公司应该是业务驱动还是技术驱动”。这样的命题其实挺傻的，因为这本来就不是一个矛盾的问题。
|
||
|
||
对于技术团队来说，实现业务大体上就是指团队工程（Engineering）能力，但追求业务项目的落地实现和追求技术能力（Technology）的迭代演进，不应该成为两个互相矛盾的事。这两者本来就是互相促进螺旋上升的，比如，实现一个随机抽奖的功能是一个业务实现，实现一个最高可供10w人同时在线每1分钟进行一次随机抽奖的功能就有点挑战了，实现一个可以通过弹性扩容支持0到10w人同时在线，以“真.随机数”(TRNG)的安全级别每1分钟进行一次随机抽奖的功能则可能是大多数工程师都不会小觑的技术难题了。
|
||
|
||
同样的业务场景，在不同的性能要求下，对团队就会不断提出更高的技术要求。而另一方面，没有解决实际问题的技术方案，即使听起来很酷炫，它的价值也十分有限。比如说不久前还火的不行的区块链，2017/2018年的时候，好多机构和组织都在招聘区块链专家、上马区块链项目、吹捧区块链技术，但时至今日，一地鸡毛，很少有人说得上来当时我们到底是要解决怎样的实际问题。
|
||
|
||
其实花点时间了解一下区块链底层技术就知道，blockchain最开始的技术底层并没有发明太多的新内容，其核心还是由一系列经典的基础模块重新组成的算法逻辑，比如说哈希算法、非对称加密、分布式系统中的一些工作原理等等。也许在某一个时间会有适合区块链技术场景的实际问题出现，但显然不是2017/2018年那时候无脑狂欢的形式。
|
||
|
||
类似的问题在人工智能领域也出现过，这几年风头正劲的深度学习框架底层依赖的神经网络理论，在21世纪初的时候都还不算是人工智能学术界主要关注的领域，在人工智能的大学课程里，神经网络的内容往往是被匆匆带过。一直到了21世纪第一个十年后，随着能够支撑大型神经网络并行“学习/训练”（training）的算力基建逐渐成熟并生产化，神经网络理论才真正地被大量认可并采用，其核心原因还是因为这个技术终于能够解决我们的实际问题了。
|
||
|
||
总结一下：
|
||
|
||
1.业务，或者说工程（Engineering），一点也不low，在不同时空复杂度的要求下，它会不断演变出新的技术（Technology）挑战来。
|
||
2.警惕过度追逐没有实际问题可解决的技术热点，对于团队中类似“一直在做业务，技术没有进步”这样的困惑能胸有成竹地回答。
|
||
|
||
最后还有一点有必要提一下：作为团队的技术领导者，要有能力识别一类问题，这类问题是需要技术预研先行的，我们不能等着产品需求提出来了才去做技术预研或储备，这样被倒逼往往会十分被动。在此举一个小例子：我们团队在2017年的时候了解过Apache Flink，但当时只是作为流式计算框架的一种去调研的，并且最后也没有采用。但2017年下半年的时候，我们了解到有阿里巴巴的团队在致力于将“流处理”和“批处理”两种数据处理模式统一在Flink框架下（新产生的框架称为Blink），当时虽然还没有业务场景需要使用到这样的技术框架，但我们感到在不久的将来很可能会出现这样的业务场景，因此我们一直密切关注相关的技术发展并积累一些实践经验。最近，我们也开始基于一个真实的业务场景落地Blink的使用。
|
||
|
||
有的时候，技术部门主管做出这样决策的时候是会受到很多挑战的，比如业务部门可能希望把研发力量更多地配置到急需实现的当前业务项目中去，比如财务部门可能会对这些前瞻性的投入提出投入产出比的质疑等等。面对这些挑战，技术领导者能否有审慎的判断和足够的自信去推进他所认为正确的工作，这是一个不小的挑战。如果说技术领导者需要具备什么战略眼光的话，这可能是其中一点吧。
|
||
|
||
感谢你的阅读，我们今天分享了CTO在“技术原点”、“技术方向”两个方面应该具备的素质和能力，下一期文章中，我们将继续聊聊CTO在“技术决策”，“技术外沿”，以及“技术人才”等几个方面的能力，下期再见。如果你觉得这篇文章对你有帮助的话，也欢迎将它分享给更多的朋友。
|
||
|
||
作者简介
|
||
|
||
俞圆圆，VPGame CTO，TGO鲲鹏会会员，前UCloud 基础云计算研发中心总监。曾经分别供职于 Microsoft Windows Azure 和 Amazon AWS EC2，历任研发工程师，高级研发主管，首席软件开发经理。经常深入第一线为客户提供技术支持，全面参与日常运维和现网问题排查，并组建和带领过实战能力极强的研发团队。在大规模、企业级分布式系统、面向服务架构、TCP/IP 协议栈、数据中心网络、云计算平台服务的研发和运维等方向积累了大量的实战经验。
|
||
|
||
|
||
|
||
|