Do Great Things

上周的 Teahour.FM 迎来了两大内容平台的创业者做客，简书的创使人林立和 Logdown 的创始人 xdite。在节目中，林立和 xdite 分享了他们做内容平台的想法。最近五六年是社交网络的天下，各种社交应用的爆发同时也把人们带入了碎片化时代，尤其是 140 字的限制，使得人们在快速生产内容，快速消费内容，越来越少的人愿意沉下心思考，记录一些文字。我们的生活其实少了很多精彩，所以很高兴能看到这一年间内容平台重新兴起并且回归，Medium、简书、Logdown、Ghost 等，每天去看看简书或者 Logdown 里面的推荐文章，我相信一定会有被感动的时候。

节目中问了一下 xdite 一年的产出是多少，直接被吓到了。在做 Logdown 之前 xdite 已经达到了年写 400000 字，平均一天 1100 字，做 Logdown 之后是只多不少，对于一个创业者、技术开发人员而非作家来说，我必须得说是非常惊人的数字，当然在这个产出下，获得的回报也是惊人的，比起之前写的一篇文章就给 Logdown 带来了 30 万的 PV。

37signals 曾在其畅销书 『Getting Real』 中提到，招聘时，永远选候选人中写得更好的，无论是设计师、程序员、运营人员、销售还是其他。写得好的人也必然同时更善于思考和沟通，所以也能更好的与代码和人打交道。

程序员大多都很痛恨写文档，尤其是写那些认为没用的文档，继而懒得记录自己的思考和心得。我们在 teahour 也聊到这点，理解但非常推荐开发人员多写文字，坚持写作对个人成长带来的好处是你无法估量的。我自己在团队中，每一个功能发布，都是要求负责人直接去写发布博客，不但要会实现，还是能给用户讲明白前因后果。

......

Read more →

最近 MetaLabs 既 Flow 之后正式对外发布了一款面向团队的新产品 Peak，看着挺吸引人，所以准备去玩玩看。不过当我进入注册页面后，我犹豫了，相对冗长的信息填写，还要求信用卡信息，再回去看看定价方案，必须年费支付，思考了一会，最后打了退堂鼓。我们做产品的都会有一个共识，尽可能的降低用户的进入门槛，减少注册路径，让用户能尽快的了解产品的特色。而这里 Peak 是反其道而行之，我相信跟我一样因为犹豫最后放弃了的访问会不在少数。但是细细思考后，这种验证 MVP 的方法真好！

精益创业的核心是以最低的成本做出最小可行产品（MVP），小步验证快速迭代。这里面很难的一点是，怎样才算『最小可行』产品，即使同一个团队每个人心中的答案可能都不太一样，所以最后只能由用户说话。Peak 和我现在在做的风车一样，都属于企业服务，所以最好的验证方式就是用户用真金白银来实际支持你，变成了客户。只有这样，我们才能知道到底是不是在正确的道路上，我们提供的解决方式是否具有足够的价值。国外的企业服务在产品刚推出期间经常会用类似的进入方式，如 14-天免费试用、信用卡准入、年费支付、甚至还有预付等等。我很喜欢这种方式，商业社会从第一天开始，其本质和基础就是建立在价值交换上，你给我提供了价值，我付给你钱，就这么简单。所以，从一开始就开始以吸纳客户为目的的 MVP 验证方式在我看来非常正确，反观国内，不知从何时起，得屌丝者得天下之论甚行，大多创业者喜欢跑马圈地，先把用户圈起来，然后想着总有一天有机会来剪羊毛。然而，可惜的是，绝大多数的创业团队，都撑不到那一天。

......

Read more →

最近一两年间，继 『Lean Startup』 之后，又有一个新的 Buzz 名词在创业圈子里很火：『Growth Hacker』。Growth Hacker 专指那群既懂技术又懂运营，以技术的手段来驱动市场运营的人才。这里姑且不论这个名词到底是不是被玩坏了，但是其定义的背后，是很多非常好非常值得学习的实战经验，称之为 Growth Hacking。维基百科上对 『Growth Hacking』 的定义是技术创业型团队通过数据分析和量化指标来推广产品时所使用的一种市场运营技术，其中有两个非常重要的点，分析和指标。一切分析的目的都是为了更好的了解你的用户，更好的了解你的产品对于用户的价值，并以指标化数据来指导我们的下一步工作。

对于创业者而言，每天我们的工作就是让产品能变得更好一点，让客户用得更舒服一点。但是，我们如何才能知道产品是在往好的方向走还是坏的方向走？当我们添加了一个功能后，我们如何知道用户是喜欢这个新功能还是讨厌之？我们又是否知道用户为什么喜欢我们的产品，亦或到底不喜欢哪些地方？我们每天都充满了这类的疑问，而回答这些疑问的最好方式莫过于寻找到那些隐藏在产品背后的真实数字，让数字说话，建立量化模型。只有这样，才能更好更快的成长。知易行难，我相信大部分创业者都知道数据驱动的价值，但是该如何去做去获取这些数据，又应该特别关心哪些数据却是知之甚少。下面就让我们围绕着『分析』这个中心，盘点一下优秀的统计分析工具及其背后的设计思想。

......

Read more →

上周末，应邀在 Hacker News 上海聚会和 Ruby 上海活动上做了『风车』架构介绍的分享，在此感谢各位组织者和活动场地提供方。

风车这个项目开始于 2011 年 11 月份，之前叫做 Pragmatic.ly。从第一天开始我们基本上就定了大致的框架结构，在今天回头看，基本上整个架构都没有什么变化，可以算是个很成熟和很适合时代的方案，☺。

最近一两年，作为技术人员，我们都能很明显的感觉到前端技术的飞速发展，比如 HTML5 支持，移动端优先、响应式界面设计以及层出不穷的各种客户端框架。而所有这些，都是基于一点：浏览器的高速发展。Chrome、Firefox、Safari、Opera 甚至于 IE，最近几年发展的都很快，不夸张的说，这些浏览器已经不再是浏览器，而是成为开放平台，有各自的扩展插件机制。这些极大地改变了网站开发的方式，网站开始应用化。

风车即是如此，设计得非常接近桌面应用，比如下面这些特点：

1. 重客户端，所有的业务逻辑都在客户端，响应非常迅速
2. 单页系统，项目内操作不需要刷新页面，操作非常流畅
3. 三栏布局，左中右栏自左向右各司其职，信息非常清晰
4. 实时更新，项目内任何更新都会实时的同步到你的页面

而在这个设计的背后，就是其本身的技术栈。

......

Read more →

自从在博客上放了 Skype 账号，聊过不少有意思的人，大多都是有创业的想法，也有不错的项目想法，但是犹豫着要不要做，认为没有投资的话不太可行，不太敢启动项目。每次我都会说，只要你开始了，即使使用自有资金，只要合理的使用和合理的做事，其实并没你想的那么困难，足够能给项目开启一个很好的头和到达一定的阶段了。

我们在一开始准备自己做风车的时候，其实也没太多考虑，很大程度是受到我们非常喜欢的两家公司的影响，GitHub 和 37Signals，我们也希望能按照我们自己的想法去打磨一款用户喜欢的产品，所以没有想太多，决定先把项目做好。我们有很多的理由去寻找资本，比如降低创业风险、获取更多的资源、人才对接等等。但是这两年走过来，回想起来，感觉挺不错。我也觉得，对于技术驱动型团队，Bootstrap 是一个更合适的启动项目方式。

1. 相比非技术人员，技术团队创业的时候有一个天然的优势，可以自己来编写代码实现产品想法。即便只有一个人，也能把事情先做起来。
2. 在产品开发初期，其实成本不高，主要还是时间付出。而在产品出来的时候，你也有很多低成本的推广方式。
3. 在产品开发初期，因为是自有资金的原因，相比会更节俭，一分钱扳两份花，同时花钱会更有目的性，这样即使后面资本进来，这段经历会让我们更加懂得如何花钱。
4. 创业是一个想法不停修正的过程，而这个修正来源于跟用户的大量沟通交流，尤其是在初期，所以会让你把精力放在用户和产品本身，而不用浪费在寻找资本上。

所以，如果有心尝试，与其犹豫不决、畏头畏脚，不如勇敢的迈出去，绝对另有一番天地，:) 但是作为一个技术型团队，有下面几点需要特别注意。有些是我们犯过的错误，有些是身边的朋友犯过的错误。

......

Read more →

10 月 29 号，著名洗脑公司 37signals 发布万众期待的新书 《Remote - Office Not Required》，随书 37signals 发布新网站 http://weworkremotely.com，专门做远程工作招聘服务。回想年初，Yahoo 宣布取消远程工作方式时，舆论哗然，远程工作是否适合互联网团队，曾在 IT 圈引起激烈讨论，却着实让人对远程工作充满了憧憬。而现在年底 37signal 的新书，必然会让远程工作这把火燃烧得更旺盛。

对于个人而言，要开始远程工作是一件很容易的事情，就像我在 07 年的时候觉得每天朝九晚五不是我所期望的工作方式，我需要更大的刺激，所以直接从网易离职，然后在网上寻找远程的工作机会，从个人做自由职业者接项目到参与到一家坚持远程工作的公司，再到现在创业做 Fengche.co 团队协作工作，整个过程选择哪个工作方式的自主权都在我自己这。说服自己的成本比起说服别人的成本可远远小多了。所以，要让公司层面接受远程工作这种新兴的工作方式是个更艰难的决定和更漫长的过程。所以尽管最近半年发现使用远程工作方式的国内 IT 公司开始慢慢变多，但是整体上这种工作方式的公司比例还是非常少。我们可以做个假设，如果你随便去一家公司，问所有员工想不想远程工作，我想答案多半是 “为什么不”，但是你问公司领导要不要远程工作，多半答案会是”为什么要”。对，为什么要？但是如果100% 知道远程工作能带来更好的工作质量，但是会有一段初期的阵痛期，你会选择尝试一下吗？可能会有部分的人的答案是“可能吧”，没有人会拒绝更好。所以，最主要的疑虑在于能不能带来更好的工做质量，也不知道这个是不是适合，而这...

......

Read more →

上个月在北京的时候去拜访了一下天放，课程格子有两项措施我特别喜欢，一个是 productivity city，如上图，是在办公室里隔出来的非常独立的一个小房间，里面不准说话，手机必须静音，同时这个房间不能超过三个人。天放介绍了一下这个是给团队成员需要专注工作时提供的一个特殊场所。另一点是天放给所以员工提供了住房补贴，鼓励团队的人住在公司边上，这样就可以不用浪费时间在交通上，以一个饱满的状态进入工作状态。

我之所以喜欢远程工作，正是因为能让我独处专注地工作和不用花时间在交通上，工作更高效，这也是我为什么认为办公室很容易成为效率杀手的原因。而这两项措施非常聪明，在我看来正是在减少办公室的副作用，最大化办公室的正向作用。

其实不管是远程办公还是本地办公，最终的诉求都是要更高效的工作，提供更好的工作成果。但是，怎样才算是更高效，更好的工作成果？最直觉的评判是，像我们做 Consulting 的时候按照时薪计费，看 Terry 的 「我如何把薪水从 50 人民币/天提升到 100 美元/小时的」 系列文章，那么，是否是我们在一个小时内有更多的产出就是高效？ 如果是体力工作者，可以说是对的，比如富士康车间，一个工人生产出了更多的机器就可以认为是更高效。但是对于脑力工作者…. 这不科学啊，因为除了数量还有质量，同样是我们，不能说是写了更多行的代码就是更高效，也不能说是完成了更多个功能就是更高效，抑或其他。所以，只能依赖一些不靠谱的可以量化的数据，比如在办公室呆了多久。但是，有一点每个人都会知道的是，办公室是不是你工作效率最高的地方？停下来仔细想想，我相信很多人会说不是，比如很多工程师在夜深人静时，编码如泉涌，两三个小时做的事会等于或者超过白天在办公室的八个小时。所以，如何提高在办公室的工作效率，如何科学使用办公室资源，是一个很值得团队思考的问题。

......

Read more →

毫无疑问，Stephen R. Covey 的《The 7 Habits of Highly Effective People》和 David Allen 的 《Getting Things Done: The Art of Stress-Free Productivity》 是个人管理类的超级畅销书，让我们学会如何才能成为高效能人士。然而，即使团队里的所有人都是高效能人士，这个团队也不一定是 个高效能团队。我们常说“一个和尚有水喝，两个和尚挑水喝，三个和尚没水喝”，正是出于这个道理。顾名思义，团队协作是指所有团队成员之间协同、合作，里 面会有分工、沟通、协调，甚至会有妥协，所以我们需要一些规则和工具来帮助团队提高协作效率。本文的一些心得和实践来自于我在小团队（<10）的经验，并且在团队内部相互信任、目标一致的基础上，所以不涉及办公室人事管理，适合于创业型开发团队。

目标一致

不仅要确保团队的长期目标一致，还要确保短期目标一致。如同在足球场踢球，刚开始比赛时，大家战术和思想都是一致的。而一旦进球后，就会出现有人想守，有人想攻的情况，这种不一致会造成局面被动并可能导致输球。创业团队也是如此。所以在任何时候，团队成员都要保持一致意见：现阶段的目标是什么，什么事情对团队最重要，然后所有做的事情都配合这个目标来完成。

......

Read more →

昨天在 36kr 看到一篇文章很有意思，「为什么很多技术合伙人参与创业时会先谈钱」，其实简单说就是信任问题，要不对人缺乏信任，要不对要做的事情还缺乏信任。因为一个靠谱的技术人员，可能这种场景又见多了，一开始会出于保护先以怀疑的眼光看待整个事情。比如下面这两个桥段，很多技术朋友都觉得很熟悉。

<p>用了你们的产品觉得不错，团队挺强。我有个非常 NB 的想法，能颠覆行业改变世界，就是没技术团队来做。如果你们跟我一起做的话，一定 XXX</p>

<p>我有个很 NB 的想法，我也认识很多投资人，只要你们给我做出来肯定就能拿到投资再做大，我可以给你 X% 的股份。</p>

我经常会收到这样的邮件或者 IM 消息。如果我回答说要收一定的费用，他们就会非常惊奇，这么好的项目拉你一起玩你竟然还在乎前期的那点收入，真是鼠目寸光。QNMD，真的，我不需要。

也经常有朋友让我给推荐靠谱的技术伙伴，我也一直说：“我可以帮忙牵线。靠谱的人就那么点，也从来不缺乏各种机会，所以如果看轻技术的话就算了。真要谈，请给予足够的尊重和诚意，剩下的真得看缘分。”

启动项目的机会成本

假设真的启动一个创业项目，表示大家对产品方向的认可，意味着不出意外会在这个产品至少花一两年甚至更久。可是对于技术人员来说，在职业生涯中还有多少个可以折腾的一两年，还有多少次试错的机会。思考的成本是很低的，但是一旦项目开始启动，时间成本机会成本都是巨大的。所以，做为一个技术人员，对待那些拍脑袋想出的 idea，不会说我们做出来试试吧，然后花上个几个月半年的时间奉献自己。相反，会看看你到底有多少诚意，会故意”刁难”你，了解你是否愿意花钱去做这个产品，逼迫你去想得更清楚。

你是否真的是找技术合伙人

回过头来，仔细思考一下，你是否真的是在找一个技术合伙人，合伙人。技术合伙人相当于 CTO 的角色，...

......

Read more →

在 「让代码审核成为你的团队习惯」 一文中，我们分享了我们团队做代码审核的一些经验心得，在微博上引起了热烈的讨论，引出了一些非常有意思的工作流介绍，比如下面的几点。

<p>我们有 master-dev 分支，比较大的功能才会新开 branch，小功能都是直接到 dev 上的，再加上团队在一起开发所以固定时间看昨日的代码，效果还不错。我们同样没有 QA，自己做的 ticket 也会找对方来做测试，但多是功能的完整性上的测试了。<cite> - <a href="http://weibo.com/iamroody" target="_blank">@iarmroody</a></cite></p>

<p>我们团队小，每个开发人员一个 git 分支，基本上工作不会互相打扰。我们的分支策略是，对于新功能，从主干开一个功能分支，然后每个开发在功能分支上开个人分支。合并时，先 BI（Backward Integration)，，再 FI（Forward Integration)。每周四定期合并，合并时 review。之所以放在周四，是因为如果合并出错，周五还有时间修复。<cite> - <a href="http://weibo.com/u/2128792480" target="_blank">@施懿民</a></cite></p>

每个团队都在寻找最适合自己团队的工作方法，希望能提高工作效率和团队协作。我们也是，这也是为什么我们除了代码审查之外，还需要过程审查这类的执行过程。像上面提到的两种方式，肯定也是在各自团队推行中觉得效果不错的，但是个人觉得在过程上在效率上还是有改进空间的，具体理由看下面，可以对比我们的目标和相应方式。目前我们使用的这一套 Git 工作流，是我们这几年不断的过程演进而来，目前 4 个人做 Fengche.co 在用，之前 10 个人做...

......

Read more →