采访达峰 - I've shipped the Code. What's next?
本文是 Teahour 第 65 期的录音文本,音频版本请访问这里 http://teahour.fm/2014/10/22/work-after-ship-code-with-dafeng.html。
Dingding:大家好。今天是我们第二场的中国 Ruby 大会的会前采访,来做客 Teahour 的是 Strikingly 的联合创始人和 CTO 郭达峰。熟悉 Teahour 的听众对达峰应该不会陌生,去年我们曾经采访过达峰,那是第 28 期,达峰向我们介绍了 Strikingly 的创业故事。你好,达峰。
达峰:你好!
Dingding:虽然上过节目,还是按照惯例,给大家打个招呼和做下简单的自我介绍吧。
达峰:大家好,我是郭达峰,是第一家进入 YC 孵化器的华人团队 Strikingly 的联合创始人。在 Strikingly 主要负责技术这一块。我从14岁开始编程,创建 Strikingly 之前我也写过几款超过 2000 万用户的 Facebook 应用。
Dingding:达峰身上其实有非常多的标签:第一支 YC 的团队、投行背景、工程师等等。我们今天的这个采访是关于 Ruby 大会的采访,我们更关注工程师这个标签。达峰你在本次大会要分享的这个题目,在我看来很有标题党的感觉:『I’ve shipped the Code. What’s next?』我第一次看到题目的时候也不确定这个是要讲啥。你能解释一下吗?
达峰:好的好的。要讲一下这个内容是什么,可能要先讲一下选这个题目的原因。我相信这次大会上有很多团队都是在创业,或者在创业团队工作的人。作为创业团队为什么选 Ruby ,就是因为 Ruby 可以快速开发,这一点对创业公司非常重要。
我自己参加过不同的讲座和不同的技术分享,发现国内这种分析很多都是专注在技术上,比如:测试应该怎么做,性能应该怎么优化,或者在架构方面的技术。听完很多这样的分享之后,我觉得对于创业公司来讲 ,在追求技术的时候,有时候却忽略了创业的初衷。我们的初衷是:Want to make something people want! 我们想做成一款大家会喜爱的产品,大家会用的产品。你可能可以有 100% 的测试覆盖率,性能非常优化,有完美的架构,但是如果没有用户用你的产品的话,What does it even matter? 根本就不重要!我发现作为技术人,我们常常把上线当成是终点。上线了,搞定了,就以为用户自己就会来。
Dingding:我曾经也犯过同样的错误!
达峰:产品完成、上线是我们比较擅长的,我们做技术的,这个是我们的专长之一。这是我们的特长专业。其实从上线的产品到用户热爱的产品还有很长的一段路。我发现很多人都在讲技术,都在讲怎么把产品做上线,越快上线,或者上线之后技术上的维护。很少有人讲,上线之后改善产品。我今天想分享的这个就是技术人员,怎样利用技术去做上线之后改善产品的事情。
Dingding:其实改善产品在我看来有很多种方向,那你在这支大会上是从哪个角度改善产品的?
达峰:我着重去做的就是怎么样把产品做到 Make something people want! 我用一个框架讲这个内容:如果你不去测量的话,你不确定产品有没有在改进(You can’t improve if you don’t measure)。如果你不去测量一个新功能对产品的影响,你没有办法有力的说明产品在改善。我讲的内容会通过数据分为三步:
1、一开始上线,创业初级的时候,你没有数据的时候,你应该用什么方式去改善产品; 2、有一些数据时,应该怎么做; 3、做到完全的有数据驱动的产品改善的流程。
Dingding:我开始有点明白了。其实整一套像比较火的概念:Growth Hacker ,专注于 User Growth 。就像你说从 User Growth 分成几个阶段:从没有用户怎么做,有了一定用户怎么做,有大批用户怎么做。是讲这块对吧?
达峰:目的当然是要更多用户来用我们的产品,但是你要拿到更多的用户,你可以有很多方法,你可以去做市场,上广告。这也是增加用户的方法。我想讲的是,怎么去改善产品,从产品本身去改变。
Dingding:可以稍微不要卖这么多关子啊,举个例子啊。比如说,我一开始没有用户的时候嘛,然后我产品上去了,这个时候你觉得要怎么做呢?
达峰:没有数据的时候你根本没法 measure 东西。其实在没有数据的时候,YC 讲过一句话是,我认为在初期最优化的:一开始的时候只做 2.5 件事。我上次分享的时候也讲过:第一件事情,make product;第二件事情,是 talk to users;第 0.5 件事情,是 exercise。
实际上第二件事情是当你没有数据的时候你最应该做的。这个时候,你应该想尽不同的方法跟你的用户沟通,他们的需求是什么,这是我会分享的。你总不可能每次都给你的用户打电话吧?第一次你会不好意思,第二次你会觉得这么奇怪啊,每天都打电话给我。我会给出几个方法,让流程更自然一点,也能更有效的帮助你去跟用户沟通,反馈你整个的开发流程。
Dingding:我都有点不想把这个当成一个会前采访了,想直接来跟你讲下去了。
达峰:我们采访完之后我们可以分享下~~~
Dingding:我们刚刚讲的是没有数据的时候。没有数据的时候做法肯定会和有数据的时候不太一样啦。当我第一阶段已经顺利迈过去之后,有数据之后,会遇到一个问题:噪音很多。这个时候有什么奇技淫巧可以用吗?
达峰:这个要讲一下。我相信很多团队也遇到一个问题:用户有很多声音。他想要这个,想要那个,我到底要去听哪一个声音呢?团队里面也有一些纠纷。A 觉得那个对,B 觉得另外一个对,那到底应该用什么样的框架来做决策呢?实际上就是数据。当有些数据的时候,你可以综合数据和判断去做决策。比如说,做一些 A / B 测试,或者开发完之后这功能是可以提高某方面的数据的。那我们可以做一个测试。先把这个功能发布给某些用户,结果如何。如果结果好的话,我们再去花更多的时间把功能做好。如果我们效果很差的话,我们再专注在另外的事情上。
Dingding:这个有点像最近被吐槽很多的:微博的 V6 版本,你可以手动升级,是这样子么?
达峰:这个倒不一定。我觉得 V6 的这个概念比较跨越性,很难说 V6 失败,就把它 rollback 到 V5。这种跨越性的进展,我认为很多时候从用户沟通完之后,你也可以做测试,但是并没有办法做到这么大规模的,我将的更多的是小的 feature。像它这么大的功能肯定也不是每天发生的。但是在一些小功能的话,我们可能每个星期都有很多这种测试同时进行中。
Dingding:这点好像我在去年的大会还跟 Github 的 Zach Holman 聊过怎么做。Github 那边好像也是类似这种。他们 Github 在发布新的 UI 也介绍过:在发布前他们只在内部和 shipped 了几个 clients 用并且用了很久了。他们那边自己用了很久才会正式的给所有用户。包括 Facebook 那边,上次不知道是不是听你介绍的,每个正式发布的功能都有人已经用了半年以上了~~~
达峰:Facebook 那边是叫 Dark Release 。Github 用的这方法,我记得在几个星期之前 Holman 也写过一篇文章:Move fast, break nothing! 实际上它也讲了很多从 process 本身,engineering process 本身去做一些事情。我讲跟他这个不是同一种方法,是类似的这种方法。Github 数据更多,同时 run 的 campaign 也会更多。
Dingding:这个真的很精彩,是我非常非常想去学习的东西。正好你们这边有非常多的实战经验,所以,这次大会我一定要非常仔细的向你请教。
达峰:我想做这个分享,也是因为我们经历过这一轮:我们从第一步没有数据的时候,到有些数据;在第二步的时候你的数据量或者你跟踪的所有的行为还不完整的时候,你从主观的看哪些功能比较好,到开始引入一些数据的分析之后;到现在第三步,有很多数据的时候,这个时候我们怎么把主观的这些东西客观化,用数据启动。我想做这样一个分享。
Dingding:非常精彩~~~ 但是我有一点想了解:你刚刚说的这些有些是工程学上的,有些是产品学上的。我们毕竟是一个技术的分享大会,所以工程学上,你会着重哪一点呢?
达峰:在 Strikingly ,并不是我一个人把这些事情都想透的。作为一个 CTO ,技术负责人,我是把公司发展、开始用数据驱动这些决定的时候,我作为技术人,我 improve 哪些东西,我开发了哪些东西,去帮助整个公司慢慢往这个方向走——这是我想讲的。所以我会分享一些我们用的工具,我们用了哪些方法,一些很实战的东西!如果你是创业的,你回家以后马上就可以开始直接应用到的东西。
Dingding:其实我觉得你带来了一个很大的东西,目前在国内圈子里很少分享的一点:工程师更应该去了解它的用户,而且是通过 measure 的方式了解他的用户。
达峰:我为什么很强调数据这一点,为什么框架都是数据这一点:数据不是假的!我作为一个技术人,我跟另外一个团队成员,我可能真的是只是说,这个功能好不好,我认为好,他认为不好。到最后,这样的纠纷没有实际的意义:所有的东西都很主观,以至于到最后都不知道该做什么。这时候有数据的话,这个就是很客观的事实。你说这个功能好,我们推出一个 MVP,试一试能不能实际上改变这个数据。如果改变不到的话,要不说明这个功能不对,或者我们可以再改进一下。
Dingding:从另外一个角度,我不确定:这个可以来了解一下你们的实战经历。从你们目前的经历来说,你要做这些东西,在开发上花额外的时间,你们从开发上多花的成本和结果来说,你来怎么评估和衡量这两点。
达峰:这个时候我会去讲,在你没有数据,你肯定是跟用户沟通来决定的。这个第一阶段你可以走很远很远,我个人认为不是说我有多少用户,公司成立多久了来决定的——这个是根据公司情况。你跟用户沟通完之后,你会真的发现,很多东西很难做决定的时候。你先把第一阶段用到尽,很难再用主观的方式来判断哪一些功能是要开发的时候,我们再进入下一个阶段。这个时候你才能够 justify 么。如果你第一步没有数据,通过跟用户沟通的时候,你都可以做的很好的话,你就没有必要进入下一步。这是我个人的看法。这意思我的分享会非常着重在第一步和第二步。在你没有数据,或者只有一点点数据的时候你应该做什么。
Dingding:Ok,这真的是非常实战的一些经验。好了,今天到此为止了,我真的是非常期待你的 Talk 。感谢你今天抽出时间来录节目,我们在 Ruby 大会上见。我一定要把你抓来好好聊一下。如果大家做一个好产品感兴趣,对如何把产品上线之后继续做好产品,这一场大家一定不要错过。
达峰:好,大家大会上见~~~