Strikingly CTO 郭达峰:从 Hacker 到 CTO

2017年6月30日-7月1日,EGO主办的第二届GTLC全球技术领导力峰会在上海举行。会上,Strikingly CTO郭达峰发表了主题为《从Hacker到CTO》的演讲。本文由EGO根据现场演讲整理。
公众号后台回复“GTLC”,下载峰会全部嘉宾演讲PPT。
演讲 | 郭达峰
整理 | 赵新龙

郭达峰,Strikingly联合创始人。于 2010 年开发了三款 Facebook 平台的应用,获取了超过 2 千万的用户。2012 年创立了市面上最简易的建站平台 Strikingly,成为第一家进入 YC 孵化器的华人团队。Strikingly 也在 2016 年发布了面对中国市场的产品 “上线了”。

非常开心能给大家做分享。我叫郭达峰,是Strikingly的CTO,从14岁开始写程序,大学期间写了几个Facebook的应用,用户量高达2000万,赚到人生第一桶金,大学毕业后一年创立Strikingly公司。

从小到大,我被最常问到的两个问题,第一个是你会不会修电脑,第二个是你会不会做网站。后来我就想,要不做一个平台,让不懂技术不懂设计的人也能自己做网站吧。所以我们就开发了一款工具,让大家通过DIY的形式做网站和小程序。我们有国际版本的Strikingly,去年刚刚上线了面向中国的产品,就叫“上线了”。

跟昨天和今天早上的嘉宾前辈相比,我的管理经验没有那么多。我把从开始做CTO到现在,很多人问过我的问题整理起来,给大家做一个分享,分享题目是《从Hacker到CTO》。

CTO写不写代码

第一个就是CTO写不写代码。回答之前,我们想一下,CTO是做什么的

硅谷会把CTO职位细分到两个不同的职位,一个是技术总监,另一个是首席技术执行官。这两个职位有不同的职责。技术总监主要是管理者,他的主要职责是帮助团队的每一个人达成个人或者职业目标,他也负责招聘。CTO的定义是什么?在一个公司里面,CTO往往是技术面上比较广甚至是最广的,他为不同业务提供解决方案。CTO不一定完全是写业务的人,但是他能够从业务架构上给出建议,既负责技术选型和方向定义*,也负责打造整个技术团队的文化**。

如果用一张图表示,X轴是技术能力,Y轴是流程设计,右下角是CTO,左上是产品经理,右上是技术总监,下面还有架构师。

在很多小公司,CTO兼顾了技术总监的职责。由于没人,很多时候CTO都要自己上,这是正常的。我们公司也这样。回到最初的问题,CTO写不写代码?如果你要解决技术问题,做技术选型,包括刚才讲的业务架构师角色,你很难不写代码。我自己实验过一个比较好的方法,就是我不写业务上的长线代码,我会在业务初期写一些所谓的原型代码,把业务摸透之后,综合我的技术经验,提出一套比较适合的架构。这样可以让CTO角色帮助整个公司的人理解技术方向,同时不必陷入到帮忙抢修BUG的事情中。

如何做技术决策

有人问我如何做技术决策。很多时候,公司大到一定程度,有时候你真的不是那方面的专家,但大家会期待你的建议。

这时候,怎么帮助这些人做技术决策?

我觉得,作为技术出身的人,我们做技术决策时,常常想这个事情能带来什么价值,却忽略了他可能带来很多成本。什么意思?作为技术人,我会认为一个更好的架构可以达到多少多少效果,但我们没有想过要花多少时间、多少成本去完成这个事情。比如微服务被炒得很火,我们都知道微服务发布速度更快、把项目复杂性拆得更散,这都是好的事情。作为技术决策者,我们要去思考,要反思后面带来的成本:你的运维团队是不是有足够的人员和足够的技术?人员招聘是不是跟得上?这是技术决策往往忽略了的——不去想一个决定会带来什么成本,只想到了带来的价值。这是技术人员第一个要思考的。

另外,当一个技术决策摆在我面前,我的第一个反应是能不能不做这件事情。如果不写这个代码就能实现这个功能,那我就不写。不做任何工作就能带来,这是最好的。我也会去考虑变更成本的概念。很多时候,可能你真的不确定选A或者选B,因为你没有足够的信息,也没有足够的信心。这时候,哪一个能够让我未来以更少的成本把这个决定推翻、哪一个有更小的变更成本,我就会做那个事情。在没有完整信息的时候,我会选择一个用更低成本能把它推翻的决策——当然前面说过了,我会更有限考虑能不能不做这个决策。

最后,我听到很多公司内部做微服务,他们在技术决策上吵得很凶。CTO角色不做最终拍板的决定,对公司的人员内耗是很严重。我认为,你必须做一个决定。我见过太多团队因为两边吵完之后一边心理上过不去而离职的,这对公司是很大的损失。而且,归到底就是选A还是选B的问题,需让公司进到下一阶段——可能这个决策本身真的很无所谓

代码质量VS迭代速度

第三个问题就是代码质量和迭代速度。我纠结了很久。以前我是一个人写代码的,我总是对细节抠得很紧。在一个团队里,有业务压力的时候,抠细节需要很多时间,那会影响迭代速度。两者之间怎么做取舍?分享一下我的建议。

先跟大家讲一个关于苹果的故事。2007年,苹果推出跨时代的iPhone。发布会上整个过程很流畅,乔布斯在上面点了很多不同的功能:打电话、发邮件、浏览网站。在当时,这是划时代的产品。在一部纪录片里,iOS的主要负责人提到,如果乔布斯当时没有按照给定剧本顺序去按——比如突然按错一个地方,可能整个iOS就会崩溃。这个故事让我反思,我相信背后的代码肯定是混乱不堪的——作为观众、作为用户,我们根本不在意那个代码是什么样的,最终结果就是我们看到是一个划时代的产品。

另外一个是我跟GraphQL的作者聊天的故事。他想解决API在移动端的适用问题,我在一次会议上跟他聊天,我说很多时候写完代码都有一种想要重写的冲动,因为我觉得有太多东西可以写得更好。他说他也有这样的时候,第一次写代码的时候,你对整个业务是不了解的,写完之后回去再写,你肯定会写的更好。这是他给我讲的。

这两个故事让我看到,相比于代码质量,一个比较伟大的公司和一位全世界比较出名的开源库作者,都更倾向于把迭代速度提上去。所以我现在的看法是快速迭代、摸清需求、然后重构,变更成本特别高的部分尽量不要妥协,比如API的设计。另外要记录技术债,设定指标,比如我们只能存在20个技术债。

打造产品团队

最后,跟大家分享怎样让工程师参与产品。很多人看到我们公司产品、跟我们的工程师聊过之后,都觉得跟很多其他公司不一样:我们的工程师特别热爱自己的产品。他们很羡慕,问我是怎么做的。

我想跟大家分享两点。第一点是客服。在传统的客服中,用户跟客户经理聊,客户经理整理需求之后给产品经理,产品经理做需求分析,最终才传递给工程师。工程师会觉得自己是一个执行者,根本不知道用户需求从哪儿来。信息在每个环节都会有丢失,在交接时间也会有损失,有可能每个环节会花一两天时间,最终到达工程师的时候,可能需求已经完全变了。用户会觉得好像是在跟黑盒子对话,而团队成员也感受不到自己的价值——因为他跟价值离得太远了。我们的做法是什么?我们提倡一个概念叫全民客服,包括工程师在内的所有人都参与客服,这样每个人都会直接收到反馈,基本上没有信息丢失,迭代也会更快。另外很重要的一点就是,每个人都会感受到自己的价值——看到用户有BUG,他们马上就修好,这样用户很开心,他也会很开心。

Paul Graham创业的时候很喜欢做这样一件事情。当用户打电话说你们这里出了一个问题,他会问哪里出问题了。在他提问的时候,他已经暗中把BUG给修复了。然后用户就会说,现在好像没问题了。他说对啊,是网络抽风了吧。他很喜欢做这种事情,用户遇到BUG他马上解决。

这有一个弊端是,你得到的反馈局限于当前已有的客户,可能有些客户觉得产品不好用就走了。我们也有另外的方式,让大家参与到更没有局限的产品。我们用了一个方法叫Hackathon。这个做法可以突破已有的产品思维,你听到的反馈不局限在已有客户,可能是工程师大开脑洞就想去做一下。我们每三个月组织一次,用两天的时间,让大家把这些想法实现出来。最开始是Facebook在做,我们觉得很有意思,就也开始做了。Facebook讲过,黑客马拉松是很有意思的事情,可以让工程师没有边框地写代码。下图是我们公司内部的Hackathon图片。

我就分享到这里。针对刚刚提到的几个问题,希望能够和大家继续交流探讨。谢谢大家。

今日荐文

点击下方图片即可阅读

百度主任架构师谭待:打造非职权技术管理机制


现代互联网逐步形成了越来越多的规模性协作社群,人们通过技术、资源、知识连接在一起,产生出远大于 1+1的价值。EGO 就是这样一个有边界的技术社群组织。

每一位 EGO 会员都是领域内的杰出人士,他们拥有至少 5 年技术工作经验、两年以上的管理经验、带领过 30 人以上技术团队。目前,EGO 已经在北京、上海、广州、深圳、杭州、成都等 6 个城市建立分会,全国会员总数超过 350 人。

EGO会员招募季第二季将于9月份正式开启;加入EGO,与杰出的技术领导者为伍。

(0)

相关推荐