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图片。

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