28 篇博文 含有标签「management」

1. 构建并交付产品
2. 找到产品市场契合
3. 尽可能快速且持续地增长用户，以实现市场领导地位和可防御的护城河
4. 建立一个能够独立于创始人运营的高管团队和组织
5. 进行首次公开募股，成为一家持久的上市公司

想象你正处于最危险的伊拉克战场上，作为一个决定着战士生死的指挥官，你将如何领导你的团队？在 Extreme Ownership 一书中，曾任海豹突击队特遣部队队长的作者们将分享他们在战场上的观察与经验，为其他同样追求着成功的团队提供借鉴。

敢于为失败负责​

作者之一的 Jocko Willink 曾在友军混战、士兵丧生的重大事故之后，一人扛下所有责任，却仍能保住工作。这是因为他的上司深谙一个道理：优秀的领导者从不推卸责任。反之，他们会主动寻求批评，并详细记录改进方法。领导者如果推卸责任，下属便会有样学样。

理解任务的重要性​

战场上，当Willink被指挥官告知自己的精锐部队将与新建的伊拉克军队并肩作战时，他暗自怀疑该军队的能力和忠诚以及命令的正确性。但后来他渐渐了解到这一举措能使美军顺利撤出伊拉克。于是他将本次任务及其目的传达给部队，而后圆满完成了任务。

领导者应该充分了解每一次行动的重要性，并在执行任务前传达给所有团队成员。当对接到的命令有所质疑时，先不要贸然宣扬，而是应该沉着三思。或者，你可以尝试从上级那里寻求解释。

积极与盟友合作​

“掩护和移动”是海豹突击队的最基本策略之一，它意味着有时候你需要寻找与盟友合作。本书的另一作者 Leif Babin，曾因为没有使用这一策略，而将团队置于本可避免的极端险境之中。领导者需要将目光放长远，从组织内部的其他团队获取战略支持而非一味与它们对抗。

明确优先级以提高效率​

拉马迪战场上，Babin 曾面对队伍深陷敌军内部，没有后援，且一个队员负伤并暴露，出口还放置着炸弹的极端危险。但他在依次明确了确保安全、接近伤员与清点人数三大要务并逐一完成后，最终得以带领团队顺利脱离险境。

战场上往往形势复杂，领导者必须保持冷静，寻找最佳解决方案。因此，“按优先级排序并执行”这一原则极为关键。领导者应首先找出优先级最高的事物并专注解决，再依次将注意力转移至下一个优先级。

提前识别和规避风险​

在进行一次营救任务之前，Babin 充分考虑到了炸药埋伏、持枪守卫等各种情况，最终得以顺利行动，成功规避了风险。

制定全面计划有助于提前识别和降低风险，提高成功几率。除此之外，领导者还应及时让成员知晓相关应急计划。在可控风险上集中注意的同时，也需意识到仍存在部分无法规避的风险。

团队合作非常重要。即使是像图灵那样的天才，也需要他人的帮助才能破解 Enigma。那么一个团队能够取得成功的关键因素是什么呢？人们自然而然地相信是成员个体的能力和水平，然而事实可能会让你大跌眼镜。

在 The Culture Code 这本书的开头，作者描述了一场发生在幼儿园小朋友、商学院学生和律师之间的有趣比赛：参赛者需要使用生的意大利面，胶带，绳子和棉花糖搭建尽可能高的结构。这场比赛最终以幼儿园小朋友的胜利结束。为什么看起来明明能力最弱的一方却能够打败其他对手取得胜利呢？在回顾比赛时，我们发现，商学院的学生通常会先分析问题，讨论正确的策略然后默默建立一种等级；而幼儿园的小朋友只是开始着手去做以及尝试不同的方式。

好的团队文化更注重团队之间的交流而非个体的技能。这样的团队文化会最大程度地促进整体的发挥。要营造一个好的团队文化从而促进整体表现，有以下三个技能。

1. 营造安全的工作环境​

人们在熟悉的环境中更容易发挥自己的全部才能，所以营造一个安全的环境十分重要。而团队里的安全感来源于团队内部的彼此熟悉和彼此联系。如果你想要打造一个安全的工作环境，学会倾听并让他人知道是非常必要的。当人们知道自己所说的话被人听见和关注，他们会觉得安心。你可以在倾听的同时适当提供一些反馈，既能增强互动性也能让人感到被需要。

2. 敢于暴露弱点，增强团队信任​

虽然这听起来可能有悖常理，但展示弱点确实有助于提高团队表现水平。我们往往在环境中观察周围人的行为方式，并模仿学习。向团队成员承认自己的弱点和错误，表明了他们也可以这么做。这样一来，有助于增强团队之间的内部信任。

同时，对自己缺点的展示也是在表达对合作的期待。当你表示出对他人帮助的依赖时，他们也能坦然地承认自己也需要帮助。长此以往，每个人都知道不应该独自承担一切，团队中会自然形成团结氛围。

3. 树立共同目标并不断加深印象​

坚定追求共同目标是团队表现良好的关键。一个团队的共同目标是指激励团队成员行为的信仰和价值观。这个共同目标能够明确团队的自我定位，并将之传达给外界。心理学教授Gabriele Oettingen通过几项研究证明，沟通共同目标有助于团结成员，并使目标更容易实现。

为了让成员加深印象，重复是不可或缺的。为了更清楚的表达，重复十遍百遍也无妨。你可以在例会上反复传达公司宗旨，也可以将目标制作成简洁而朗朗上口的流行语。

只过“第一天“ = 不增长就会死​

亚马逊 CEO 杰夫贝索斯所在的工作楼叫做“第一天”。这么多年来，无论他搬去哪个其他的楼，他都会带着这个同样的名字。所以，他对这个词非常有发言权。

有人问，什么是“第二天”呢？第二天是停滞、然后是无关、然后是令人窒息的痛苦的衰退，然后是死亡。

这也是为什么贝索斯认为，每一天都应该是第一天，不增长就会死。那么如何防止“第二天呢”？有四个基础

真正地痴迷客户​

商业策略千万条，问什么偏偏要挑“痴迷客户”呢？好处有很多，最大的好处是：**客户们总是总是不满意，即便他们嘴上说满意。客户们总是不知道：他们实际上想要更好。而你想要对客户好，就得以他们的名义，来创造产品和服务。**比如 Prime 服务并不是客户问亚马逊做的，但是结果却证明，这的确是他们想要的东西。

保持“第一天”要有耐心，你需要大量试验、接受失败。种下种子、长出树苗需要时间，但是一旦看到了用户开心的点，就加倍下注 (double down).

反抗代理​

当公司越来越大的时候，很多时候我们做事情会倾向于依赖代理或者中介。这种依赖的形式千变万化，令人防不胜防，非常的“第二天”。举两个例子：

1. 依赖流程作为结果的代理。好的流程服务你，让你更好的服务客户。你千万不要服务流程，为什么呢？当你服务流程，你会只管把流程做对，不管结果好坏。遇到失败，只有生涩的领导说”我们遵循了流程“，而老道的领导会说”我们找到了一个改进流程的机会“。要反复问自己，是流程拥有我们，还是我们拥有流程。

2. 依赖市场调研和客户调查作为客户的代理。当你发明与设计产品的时候，依赖调研是危险的，“满意度从47%增长到55%”是一句晦涩的话，容易产生误导。

   1. 好的投资者和设计师深入地理解客户，他们花费大量的精力开发直觉，他们研究大量的奇妙案例 (anecdotes)，而不是研究调研得到的平均数据。他们活着就是为了设计。
   2. 贝索斯不反对公测和调查，它们帮你找到盲点，但是作为产品和服务的提供者，你必须源于客户高于客户，你有你的愿景和独特的价值。卓越的客户体验始于内心、直觉、好奇、玩耍、勇气和品味。而这些是用户调查无法替你提供的。

拥抱外部趋势​

天下大势，顺之者昌，逆之者亡。这些趋势不难被发现，但是很奇怪的是，大公司很难拥抱这些趋势。现在就有一个这样的趋势：机器学习与人工智能。

在过去几十年中，大量的任务可以由精准的规则和算法来解决；接下来，有了机器学习，我们可以去解决那些无法由精准规则描述的任务。

很多机器学习的东西发生在底层，肉眼不可见的地方，但是你至少可以用 API 非常简单地调用他们。

高速度决策​

“第二天”的公司做高质量的决策，但是他们的决策速度非常缓慢。为了保持“第一天”的能量和活力，你必须做出“高质量而且高速度”的决策。这不仅是因为在商业世界，“快速”很重要，还有一个原因是，拥有一个“高速度决策”的氛围会更有趣。

如何实现高速度决策？贝索斯没有完整的答案，但是有如下思索：

1. 决策与决策之间生而不平等，绝对不要一碗水端平。可逆的决策用轻量级的决策过程。

2. 大多数的决策可以在你拥有 70% 信息的时候做出。等到 90% 的时候可能就太迟了。而且，无论是上面的哪种情况，你都得快速识别和应对坏决策。当你应对能力很强的时候，犯错很便宜、而慢速很贵。

3. 使用“==我不赞同，但是承诺好好执行 disagree and commit== ”的管理风格。这样会省出大量扯皮的时间。

   1. 在没人知道结果的时候问一句，“我知道我们有分歧，但是你是否愿陪我意赌一把？不赞同，但是承诺好好执行？”你得到的答案很可能是，“没问题”。
   2. 不赞同的一方并不是因为不关心而 commit，而是因为发自内心的真诚的不赞同，这样能够让对方审视你的“不赞同”，却仍然因为你的 commit 而快速行动。

4. 尽早发现不合 (misalignment)，并立即上报升级 (escalate)。有时候组与组之间的目标是冲突的，平级之间扯皮是无法解决的，这会浪费大量时间，消耗大量能量，这个时候上报会让决策更加快速和轻松。

在一个充满诱惑的世界中，保持专注的能力是实现目标的关键。《钩子》的畅销书作者尼尔·埃亚尔在他的新书《不被干扰》中揭示了他对抗干扰的方法。

为什么我们如此容易分心？有时可能有外部原因。然而，在大多数情况下，干扰的根源在于内部。我们分心是因为我们想逃避不适。为了避免干扰，我们需要从内部解决问题。

识别内部触发因素并战胜它们​

下次你感到想要分心时，试着记录你的感受和触发因素。这就是你首先识别内部触发因素的方法。然后你可以通过让任务变得更有趣来尝试避免这些触发因素。

在工作前为自己规划优质时间​

制定计划可以防止你分心，因为你会清楚自己到底在追求什么。然而，工作安排并不是开始的最佳地方。相反，首先为自己和你的关系制定计划，然后你就不会在工作中途逃避到你的爱好中。

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

办公室干扰，例如邮件通知，是典型的外部触发因素。让他人知道你需要完全专注于手头的任务，因此他们不应该打扰你。此外，学习更有效地整理你的邮件，确保每天只有少数几封邮件需要你关注。除了邮件，工作场所还有其他形式的干扰。学会以最不干扰的方式组织它们。

利用契约来防止干扰​

你必须意识到，你与干扰之间的斗争不是一天的战斗。也许你可以尝试一个应用程序来阻止你访问干扰内容。或者找一个学习伙伴一起专注。对未达成目标施加罚款也听起来很实用，作者对此进行了验证。

促进功能性工作文化​

功能失调的工作文化是无尽干扰的开始，在这种文化中，员工负担过重，甚至被要求在下班后回复邮件。雇主应该创建一个平台，使员工能够安全地反馈，而不必担心被解雇。一步一步，公司可以朝着功能性工作文化迈进。

保持专注的能力是你实现自我的关键。在一个容易注意力分散的世界中，这种能力变得空前重要。 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。快节奏与慢节奏、高质量与低质量差别，通常是指数级别的，因为 —— 通常，快会让你更快更多，差会让你更差更少。

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

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

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

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

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

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

动机和激励是绩效管理的核心。没有激励，员工没有动机把事情做好，所有的反馈和培训都是白费力气。

领导对员工的尊重与员工的激励程度正相关​

冒犯行为会直接打击员工的动机和绩效，所以经理需要遏制冒犯行为，可以这样做：

1. 自己作出表率，上行下效。
2. 维护员工的自尊。公开表扬，私下批评。
3. 雇佣尊重人的员工，不姑息坏行为。遇到问题反馈要及时。

激励主要来自两个方面：外在和内在​

1. 外在的奖励——金钱 （升职加薪奖金）

   1. 这种奖励不一定会提高员工的绩效。
   2. 通常效果短暂。
   3. 整个团队的工作很难分清楚贡献的多寡，奖励多少才算合适对每个人来讲标准都不一样。==实际上，大多数员工的主要关注点在于公平，作出金钱奖励的时候一定要注意公平性和一致性(consistency)。==

2. 内在的奖励——满足感（成就感、控制感、被感激感、智力上的提升、技能提高、自治、达成挑战）

   1. 一定要注意，==这种奖励要注意因人而异==。

怎么做到给人以内在奖励呢？​

1. 认可他的工作。“认可的关键在于让人感受到他的与众不同”。每个人得到同样的东西，每个人就不会有与众不同感。

   1. 每个人对认可的来源的重视程度不同。来自同事？在同事面前公开表扬他。来自客户？发一张客户的感谢信。来自专业？发专业奖项。来自老板？1:1 的时候生动地描述他对团队的重要性。
   2. 按照性格认可。内向外向？公开私下？如果不清楚，可以直接问对方。
   3. ==认可的频率要高，至少两周一次。==
   4. 手写的奖励成本低但是效果奇佳。

2. 提供决策权

   1. 人们喜欢拥有感和控制感

3. 提供挑战

   1. 挑战难度越高，完成的成就感就越高。
   2. 提供做没做过的事情的机会，帮助人开发新技能。要注意，前提是他们有相关的天赋和技能，而不是完全从零开始。