保持专注的能力是你实现自我的关键。在一个容易注意力分散的世界中，这种能力变得空前重要。 Nir Eyal，《上瘾》一书的作者，为我们提供了消除干扰和保持专注的有效方法。

为什么我们总是容易分心呢？事实证明，分心往往有内部原因。分心是因为我们总想想摆脱心理上的不适。为了避免分心，我们需要从内而外地解决问题。

确定注意力分散的内部触发因素​

下次注意力快要分散的时候，请尝试记录你的感受以及触发这种感觉的原因。这样一来，你就能从一开始了解内部触发原因。之后便可以通过使任务变得更加有趣来避免分心。

优先为自己的生活腾出时间，然后再安排工作​

制定计划可以防止分心，因为你将明确地知道自己的目标。但是，优先安排工作时间并不是最好的开始。正好相反，首先要为你自己和人际关系做好计划。这样，玩耍的时间已经安排好了，你就不会因为想要玩耍而中断工作。也就是说，在该工作的时候工作，该玩耍的时候玩耍。

减少办公室的干扰并学会组织​

办公场所中通常会有很多分散注意力的外部因素，比如邮件通知。试着让他人知道你需要完全专注于手头的任务，这样他们才不会打扰你。另外，学习如何有效整理自己的邮件，确保每天只有很少的电子邮件需要关注。除了电子邮件，工作场所还​​有很多其他分散注意力的形式，学习以最少的精力来应对它们。

利用条约防止分心​

一个不得不承认的事实是，我们与分心之间的斗争并非一日之战。你可以使用一些阻止分心的App。或者跟其他伙伴一起集中工作。同时，以罚款的形式作为没完成目标的惩罚也很有效，这一做法让作者自己受益匪浅。

打造健康的工作文化​

工作文化失衡是无止尽分心的开始。在失衡的工作文化中，员工负担沉重，甚至被要求在下班后回复电子邮件。雇主应创建一个平台，使员工能够安全地提供反馈，而不必担心被解雇。

20% 时间​

工程师被允许花费他们 20% 的工作时间给任何一个他们自己想要贡献的项目，不用寻求他们经理或者其他人的同意。这非常有价值，因为：

1. 只要有好的想法，甭管一开始听起来有多烂，都有充足的时间去实现它到一个可以 demo 的状态。
2. 给管理者看到他们原本看不到的活动，否则工程师会搞“skunkwork” 偷偷干活。
3. 允许工程师干一些有趣的东西，防止他们 burn out，激励他们让他们更开心。有干劲的工程师和 burnt-out 的工程师在产出的差距是远超 20% 的。
4. 鼓励创新，如果周围其他人都做 20% 项目，你也会受到感染去做。

OKRs​

个人和团队都必须公开记录他们的目标和对目标的衡量。

• Objectives 目标
  • 设置季度和年度的目标
  • 个人和小组的目标要和大组的目标看齐 （align ）
• Key Results 关键结果: 通过可测量的关键结果，可以算出达到目标的进度，范围是从 0 到 1。
• OKR 尽量往高里设，最后一般达到 0.65 是一个不错的标准，如果你的执行结果常常低于它说明目标设置得太高，高于它说明目标设置得太低。
• 好处
  • 大家互相知道在干什么，能够互相激励
  • 让执行有了目标，让目标更容易被执行
• ORKs 与绩效考核不是直接相关的

项目继续做还是终止？​

尽管对于重大的新发布的审查是流程化的，但是某个项目该不该做这种问题却没有定论，有些是自下而上的决定，有些是自上而下的决定。

重组 (re-org)​

组的分拆以及合并是家常便饭，似乎这样做能够优化效率。

我的评价​

20% 时间的结果是好的，比如孵化了 Gmail，AdSense 等等举足轻重的项目。在一个跑马圈地的年代，鼓励优秀的工程师花一些时间做一些新东西是非常合算的。在公司还小需要用非常好的福利措施来吸引人才的时候，宣扬 20% 时间也是一种特立独行的手段。我更倾向于 20% 时间是一种管理风格，而不是成功的必然原因。

ORKs 与绩效考核不直接相关，这种区分非常重要 —— 换句话说，就是愿景与执行分离，目标管理与绩效管理分离。举个例子，你开车从 A 点到 B 点，“你有没有到终点？”，对比，“你开的这辆车是不是好车？”，其实是两个不同的问题。同样的道理，产品最后卖的不好，与工程师有没有做出好的产品，是两件不同的事情。

对于普通的工程师来讲，在大公司里面跟其他组，包括跟你具体工作没关系的其他组，保持好的关系很重要，因为这相当于你在劳动力供求的市场上多出了一些需求方。这样一旦发生重组或者其他不利的事件的时候，你能够有更多的选择。

业界公认，谷歌是一家工程能力超强的公司。它有哪些好的工程实践？我们可以在里面得到哪些启发？其中又有哪些地方是被人诟病的？这些内容比较细致我们慢慢讲，本篇主要是讲开发。

代码库​

• 截止15年有 20 亿行代码存在少量的 Monorepo 单一代码库中，绝大部分代码对所有人是可见的。谷歌鼓励工程师见到有问题就可以改，只要所有人审核通过，就能进库。
• 几乎所有的开发都是在代码库的头部 (head) 进行的，而不是在分枝上，避免 merge 时候遇到问题，安全修复也更方便。
• 每个改动都会触发测试，有错几分钟内就能通知作者和审查者。
• 代码库的每个子树至少有两个所有人，其他开发者可以提交修改，但是所有人批准才能进库。

构建系统​

• 分布式构建系统 Bazel 让编译、链接、测试轻松快速。
• 成百上千台机器。
• 可靠性高，确定的依赖输入导致确定的结果输出，不会出现奇怪的不确定的抖动。
• 快。一个构建结果缓存了，依赖它的构建会直接采用缓存，不必重新勾结。只会重新构建改动的部分。
• 提交前自检 (pre-submit checks)。一些快速的测试可以在提交前先执行。

代码审查​

• 有代码审查工具
• 所有改动必须有审查
• 发现 bug 之后可以去之前的那个审查上指出问题，相关人员会被邮件通知到
• 实验性质的代码不用强制审查，但是生产环境下的代码一定会被审查
• 鼓励每个改动尽量小。百行以内是“小”，三百行以内是“中”，一千行以内是“大”，超过一千行是“超tm大”。

测试​

• 单元测试
• 集成测试、回归测试
• 提交前检查
• 自动生成测试覆盖率
• 部署之前做压力测试，并产生相应的关键指标，尤其是延迟、错误率随着负载的变化

Bug 追踪工具​

Bugs, feature requests, customer issues, process 等等都记录起来，需要时常 triage 以确认优先级然后分配给相应的工程师。

编程语言​

• 限制有五个官方语言 C++, Java, Python, Go, JavaScript，以便代码重用和开发协作。每种语言有风格指南。
• 工程师要经历代码可读性培训。
• 当然某些场合的 DSL (Domain-specific language) 也不可避免。
• 这些语言之间的数据交互主要是通过 protocol buffers。
• 通用流程很重要，不同的语言，同样的工作流程

Debug 和分析工具​

• 服务器崩溃时，崩溃信息会自动记录下来。
• 内存泄漏会附带上当前的 heap 对象。
• 有大量的 web 工具帮你检测 RPC 的请求、改变设置、资源消耗等等。

发布​

• 大多数的发布工作是普通的工程师自己做的
• 及时发布很重要，因为快速的发布节奏能够极大地激励工程师多干活、更快地得到反馈
• 典型的发布过程：
  1. 找最新的稳定 build ，做一个 release branch，可能再附带 cherry-pick 一些小改动
  2. 跑测试与构建、打包
  3. 发布到 staging 服务器上内部测试，这时候可以 shadow 一下线上的流量，看看有没有问题
  4. 发布到 canary 上承接少量的流量公开测试
  5. 逐渐发布给所有的用户

对发布的审查​

用户可见的、或者是重大的发布必须有相关的法务、隐私、安全、可靠性、业务需求相关的审查批准，确保相关人员被通知到。有专门的工具来辅助这个流程。

尸检报告​

有重大的 outage 事故发生之后，相关责任人必须写尸检报告，内容包括

1. 事件标题
2. 总结
3. 影响：发生了多久、影响了多少流量、损害了多少利润
4. 时间轴：记录时间的发生、诊断和消弭
5. root causes
6. 做的好的地方，做的不好的地方：有什么经验能够帮助他人在下一次更快更准地找到并解决问题？
7. 接下来的可行动作：有什么接下来可以做的事情能够避免将来类似的事情发生？

对事不对人，这里的关键是理解问题本身、以及将来如何避免类似问题。

重写代码​

大量的软件每隔几年就会被重写一次。坏处是确实成本高，好处是

1. 保持敏捷。市场在变，软件的需求也一直在变，代码也需要随之变化以应对不时之需。
2. 降低复杂度。
3. 传承知识给新人，让他们有拥有感。
4. 提高工程师的移动性，促进跨领域创新。
5. 采用最新的技术栈和方法论。

我的评论​

谷歌的单一代码库和强大的构建系统是小公司不可学的，毕竟小公司没有资源和能力让构建系统快到敏捷可用；保持小、简单、快速会让小公司跑得更顺畅，更加专注于核心业务逻辑。

构建系统通常是定制化的，你的知识无法迁移和衍生。强大的构建系统对新手甚至是有害的，因为提高了新手俯瞰全局的成本。

知识无法迁移和衍生也是完善的内部工具 (in-house tools) 的问题。我在职业生涯中会尽量避免使用不会开源的内部工具，比如 Uber 的 Schemaless，只针对特定的场景且没打开放出来算做大做强 ；而相反的， Linkedin 的 Kafka 则是一个有开放性和衍生性的知识的好产品。

在公开市场，这整个开发、测试、集成、发布的流程都有非常好的工具帮你来做，举个 JS 社区的例子：

流程	工具
代码库	Github, Gitlab, Bitbucket, gitolite
代码审查	Github Pull Requests, Phabricator
提交前自检、测试与 Lint	husky, ava, istanbul, eslint, prettier
Bug Tracking	Github Issues, Phabricator
测试与持续集成	CircleCI, TravisCI, TeamCity
部署	发布在线服务的 Heroku, Netifly, 发布移动 App 的 Fastlane, 发布库的 NPM

最后，我可能有一个洞见，不注重这些工程流程自动化的细节的公司，在工程上会损失巨大的竞争力。我甚至为了良好的工程实践自己配了一个 JS 全栈开发框架 OneFx。快节奏与慢节奏、高质量与低质量差别，通常是指数级别的，因为 —— 通常，快会让你更快更多，差会让你更差更少。

每个有抱负的企业家都知道，创造没人想要的东西是个致命的陷阱。这就是我们为什么必须进行正确的数据分析。 《精益分析》（Lean Analytics）一书为创业者评估成功提供了一些良好的指标。

朝着正确的方向，然后数据驱动​

数据对业务至关重要。企业家需要用数据来说服别人。有时候，企业家往往高估自己的成功，但数据不会撒谎。它可以帮助创始人脚踏实地。但是，追求什么数据的个人判断也很重要。企业家不应该只是做数字的奴隶。

什么是好的指标？​

为了收集数据，你需要找到一些可以提供有意义数据的指标。 好的指标具有三个特征：

• 可比较的：一个好的指标可以在不同时间段，消费者群体之间进行比较
• 可理解的：良好的指标简单易懂
• 比率：指标通常是比率，因为比率有效且具有可比性

初创企业将经历的五个阶段​

• 移情阶段——确定人们的需求，确定你的小众市场
• 黏性阶段——找出如何满足需求的产品，把用户留下来让他们反复使用
• 扩散阶段——加能够吸引人的功能
• 营收阶段——业务开始产生收入
• 规模化阶段——扩展或打入新市场

专注于一个指标​

为了取得成功，创始人必须专注于最关键的一项指标。知道什么是最重要的指标可以防止你迷失在数据世界中。

最好的指标是什么？​

从来没有统一的最佳指标。在不同的行业中，最佳指标有所不同。对于电子商务公司，最重要的指标是每位客户带来的收益。但对于媒体网站，最重要的指标是点击率。

每位有抱负的企业家都应该时刻警惕构建没人想要的东西这一致命陷阱。这就是为什么正确的分析变得如此必要。书籍《精益分析》为初创企业创始人提供了良好的指标，以帮助他们在未知中导航并评估他们的成功。

朝着正确方向的数据驱动​

数据对商业至关重要。企业家需要数据来说服他人相信他们的想法是可行的。有时，企业家倾向于高估他们的成功，但数据不会说谎。数据帮助创始人保持对现实的清醒认识。然而，个人对追求何种数据的判断也很重要。不要仅仅成为数字的奴隶。

什么是良好的指标？​

为了保持数据驱动，您需要找到一些能够提供有意义数据的指标。良好的指标具有三个特征：

• 可比较：良好的指标可以与不同的时间段、消费者群体等进行比较
• 易懂：良好的指标简单易懂
• 比率：比率有效且可比较

精益分析框架的五个不同阶段​

精益分析框架建议初创企业将经历五个阶段：

• 同理心 — 识别人们的需求 / 确定您的细分市场
• 粘性 — 找出如何用产品满足需求
• 病毒传播 — 添加吸引人的功能
• 收入 — 企业开始增长并产生收入
• 扩展 — 扩展或进入新市场

专注于一个指标​

为了取得成功，创始人必须专注于一个最关键的指标。了解最重要的指标可以防止您在数据的海洋中迷失方向。

最佳指标是什么？​

一般来说，没有最佳指标。在不同的行业中，最佳指标各不相同。对于电子商务公司来说，最重要的指标是每位客户的收入。然而，对于媒体网站来说，最佳指标是点击率。

Uber 在 2014 至 2018 年间造了不少的轮子，比如服务发现的 Hyperbahn, 任务队列 Cherami, 基于 MySQL 的 NoSQL Schemaless, 资源调度器 Peloton, 服务部署平台 uDeploy 等等。如今 Uber 裁员甚至裁到了工程团队上，股价低于15年的估值，到底造这些轮子是功是过？创业公司应该招人造轮子还是应该拿来主义？

管理是个金字塔，花花轿子人抬人，人是靠人顶上去的，任何管理者的政治素养第一课就是把手下的人招的多多的。招大量的工程师在 VC 投钱的公司来讲也是一个有意思的指标，因为投资者不懂技术，而认为人头数多的公司自然发展的更好。

所以很多人都有为自己多招人的动机，而如何衡量这个动机的正当性呢？这个对于机械性的工作，比如在工厂，是比较简单的，因为产出是直接可衡量的；而脑力工作则不好说，尤其是写代码这种事情。比尔盖茨说，靠代码行数来衡量开发进度，就像是凭重量来衡量飞机制造的进度。我甚至听说，谷歌有专门的组来计算每个组对于公司的贡献程度。

管理者喜欢招人，工程师喜欢造轮子。一方面，创造者天生享受创造的乐趣；另一方面，工程师可能会有要不得的 ego 觉得，如果用别人的技术，岂不是显得我的技术不行。管理者提供“想要什么”，工程师提供“想做什么”，做出来的东西是这两种力量产生的结果。

比如，老牌零售公司请了来自硅谷的新 CTO，新 CTO 招大量 Engineer 做项目，并坚称一旦找到了好的人才，就能够带来有用的项目。他还想要把一些内部软件打包卖服务，尽管这些服务还是跑在一个大型主机上。CTO 还真信这一套。这里的关键问题是，做这些事情到底有没有 ROI （投资回报）？

如果 ROI 没法预先知道，那么如何有效地平衡按需招人和浪费资源呢？答案是注重“打造用于概念验证的原型产品 (POCs)”。用最小的投入来试水，管用就多招人，不管用就不招人。

如果 ROI 能够预先知道，那么答案就是一个简单的算术题。比如 HipChat 每个人每月收 $5, 然后 Uber 有 6 万全职员工和合同工，那么一个月的服务需要花 30 万，而招一个工程师去拿开源的 Mattermost 来魔改的话，每个月只需要付 3 万。那么"自己造轮子"省钱能省到大概是原来的五分之一到十分之一。

也有造了很多轮子，同时又发展得特别好的公司，在其中强力的管理和工程文化起到了很重要的作用，他们推崇简单至上和技术责任感。如果外部现成的轮子功能专一、方案成熟，他们会拿来即用；如果外部现成的轮子什么都做、复杂不可控，他们会自己造轮子。我记得当初 Uber 没有第一时间采用 Cassandra 的一个重大原因就是公司里面没有 Apache Cassandra 的内部人士，技术不可控。

简单至上四字箴言与注重细节并不冲突。比如你可以先选择昂贵笨重的来自微软、SAP 甚至甲骨文的 ERP，然后在跟你业务结合紧密不得不做特殊处理的地方，自己写一些服务，但是要保证服务短小精悍易于维护。而那些新一代的创业公司做 ERP 的时候不注重细节，连最重要的“审计”功能，比如会计里面的复式记账，都做不好，是他们失败的重要原因。

当你知道你应该去哪里时，去那里已经太晚；如果你总是坚持原来的道路，你将错过通往未来的路。

查尔斯·汉迪用他去达维酒吧的路做了一个类比。在距离达维酒吧还有半英里时，向右转并上山。然而，当他意识到自己走错了路时，他已经到达了达维酒吧。

增长曲线通常呈“S”形，我们称之为S曲线或 sigmoid 曲线。为了保持整体增长率高，你必须在投资时间和资源之前发展你的第二条S曲线，以免为时已晚。

英特尔的CPU、Netflix的视频流、任天堂的游戏、微软的云计算都是推动第二曲线业务的优秀例子。

如何找到并抓住第二曲线需要远见和执行力。你必须输入更多信息并不断整理，以识别最佳机会。然后，一旦识别出机会，你需要一个可靠的团队来打这场战斗，并弄清楚它是否真的有效。

让你成功的因素可能不会让你再次成功。增长总是有一个限制。第二曲线理论帮助我们反思为什么以及如何拥抱变化，过上更繁荣的生活。

当你知道该往哪走的时候，往往已经太迟了；如果你总是坚持最初的道路，你会错失通向未来的道路。

查尔斯·汉迪是通过"戴维酒吧"类比的：在通往"戴维酒吧"的路上，距离它还有半英里的时候向右转上山。然而，当他意识到走错路的时候，他已经到了"戴维酒吧"。

增长曲线通常是 S 形的，我们称之为 S 曲线。为了让增长率能够一直高涨，你必须在还来得及的时候，投入时间和资源，发展出第二条 S 曲线。

英特尔的 CPU，奈飞的视频流，任天堂的游戏，微软的云，都是这种第二曲线驱动的业务的绝佳例子。

怎样才能发现和把握第二曲线呢？你得输入更多信息，辨别好坏，甄别机会。然后一旦机会出现，有一个强有力的团队打硬仗，才能回答是否真的找到了第二曲线。

过去让你成功的原因也许不会让你在将来再次成功，增长总是有极限。第二曲线理论帮助我们反思为什么以及如何拥抱变化过更好的人生。

Facebook 的增长 VP Alex Schultz 曾经跟 Mark Zuckerberg 讨论为什么他们会成功。答案不是因为他们绝顶聪明，也不是因为他们经验丰富，而是因为他们非常努力，执行力超强。与执行力比起来，增长反而是可有可无的。因为道理大家都懂，差别就是人有没有快速执行。

执行是一件很难的事情，增长执行失败有十大原因。

1. 没有从注重留存开始。没有留存的增长就像是麦田的火环，总会被烧完。增长没有留存就没有 PMF。达到PMF的标志是 cohort analysis 的留存率曲线最后是平的。

2. 认为产品就是一切。基于这个错误的观念，==人们会错误地倾向于“做更多”的产品，而不是把现有的产品“做更好”。而增长是一个“做更好”的过程。== builder 喜欢造新东西，但是你作为领导要确保他们能够至少一部分地为结果负责。

3. 想要找到银弹。好的产品是花时间花精力在细节上打磨出来的，不是变戏法变出来的。好点子是点子多的副产品，你没法控制找到好点子的结果，但是你构建一个能够让更多好点子冒出来的流程。

4. 不够专注。见人就砍，而不是先砍死一个再砍一个。怎样突破这里的门槛效应？记住两点1）大多数的公司的主要规模来自于单一渠道2）规模化就那几种方法，选一个。

5. 数据不够，分析不够。这里的难点是很难量化数据分析的产出，所以你要坚信这件事情是非常有价值的，它能够让你做正确的选择。

6. 实验不够，远远不够。Hubspot 半年跑了上千个实验。

7. 不问为什么。一个实验结束效果不好就换下一个，没有问为什么。

8. 有了成效不加注 （double down）。如果你发现某个渠道效果非常好，还没有用到尽头，要继续投入。Zynga 发现一个游戏中的虚拟礼物非常挣钱病毒营销效果非常好，就立马把这个功能加到所有游戏中。

9. 资源投入不够。增长需要专门的组来做。

10. 没法拥抱变化。公司的增长通常会经历三个阶段：Traction, transition, growth 一个阶段的原因不会帮助你在下一个阶段成功。

问题：对于 Hubspot 的 freemium 和流程全自动 (touchless) 的软件生意，如何在 VC-backed 的情况下用最少的时间获得最高的增长？

解决方案：四合模型，造就公司成长有四个相关元素：产品、市场、渠道、模式。作者认为这四个因素是联动的，必须要相互配合。

PMF：产品与市场要匹配。世界上有两种公司：顺风公司和逆风公司，区别是 PMF。所谓找到了 PMF，就是指你的产品有一群人随着时间迁移反复使用，反复使用产生的利润足够支撑你继续增长；就是指你的产品有粘住的用户，使得你的留存率曲线虽然随着时间掉下来，但是最后趋势还是平的。

PCF：产品与渠道要匹配。产品本身的属性决定用什么渠道推广好。简单普世的产品对应大众便宜的渠道，复杂晦涩的产品对应领域特殊的渠道。

CMF: 获客与商业模式要匹配。在ARPU ↔ CAC光谱上，高 ARPU 对应高 CVC；低 ARPU 对应低 CVC。怕的是， ARPU 设的太高低 CAC 的用户用不起，ARPU 设的太低挣不到足够的钱支撑高 CAC。

MMF：商业模式和市场要匹配。我们的目标是 ARPU × 市场上的所有消费者 × 你能够拿下的消费者的比例 >= 一亿美元，那么如果这个式子算出来不对，那么要相应地改变你的商业模式扩大你的收费，或者面向跟多更广的用户群体。

使用这个增长模型有几个要注意的点：

1. 使用的前提是目标 VC-backed 的一亿美元生意
2. 你如果想要改变一个元素，就得相应地调整其他地方
3. 元素本身也在不断变化
4. 一次最好不要改变太多的元素，你不熟悉相关领域的知识，可能会处理不了