18 篇博文 含有标签「management」

普通人在生活和工作中做决策机会并不多，也很难有机会练习和提高自己的决策水平。大多数人的决策靠直觉，而理性的决策靠流程。《决断力》一书提出了理性决策的四步流程 —— 为了提高做出最佳决策的概率，我们需要 1.拓宽选项、2. 用事实检测假设、3. 跳出自己看自己、4. 为错误决定做准备。

1.拓宽选项​

人们误以为做选择就好像考试做选择题，从三五个选项里选一个那么简单，然而世界之大，选项又何止三五？例如，一家广告设计公司在工作中会同时开展多个设计方案，并在每一轮的反馈中将有用的元素组合为最终的设计成果。这样不仅使工作效率变得更高，还也节省了决策的耗时成本。除此之外，还可以参考他人面对类似状况时做的选择的基础比率。沃尔玛的创始人 Sam Walton，就在职业生涯中一直密切关注着竞争对手的动向，从而适时调整决策。作为决策者，应要在创造更多选项和参考他人的选择中，找到最佳方案。

2. 用事实检测假设​

如果说实践是检验真理的唯一标准，那么做最终决策前的实验，也能相对准确地预估出想法能否奏效。很多公司已经从仅仅通过面试来雇佣员工，发展到要求他们通过短时间的试用期，正是为了避免面试的局限性，从而增加决策的准确性。我朋友买房前去房子里试着住了一个晚上，发现能够听到火车的鸣笛，从而花小的成本避免了大的失误。

3. 跳出自己看自己​

当决策者过于沉浸于自己的观点时，往往会忽略外部视角。所以，想要判断决策的可能结果应该去调查决策所基于的客观情况。可以考虑从更远的时间和空间的维度来衡量选项，比如安迪格鲁夫假装自己是新的 CEO 从大门进来然后砍掉内存条业务；李开复假设明天有两份报纸头条报道自己的两个选择——有情但不公正、公正但无情，继而作为领导者选择了要公正；杰夫贝索斯假设自己 80 岁回头看自己，运用"遗憾最小化框架"。

4. 为错误决定做准备​

对于决策的结果，你应该考虑到最好和最坏的两种结果，以便了解自己所处的位置。如果情况接近最糟糕的结果，你也能及时地做出反应。除此之外，还可以建立一种能使你意识到自己行为的信号，从而削弱行为的惯性，及时地纠正决策。值得注意的是，为了提高做决策的速度，贝索斯认为，决策与决策之间生而不平等，绝对不要一碗水端平 —— 可逆的决策用轻量级的决策过程。

研究表明：有导师的人表现更好，在事业上进步更快，甚至连在工作和生活中，获得的满足感也更多。而导师也会从中受益，在教人的同时自己也会有收获。尽管有那么多的好处 —— 76%的职场人士认为导师对成长很重要 —— 但超过54%的人没有这种关系。

这里问题往往是人们不知道如何找到导师，如何建立关系。以下九个步骤可以帮到你。

1. 明确自己的目标和具体需求​

拿出笔和纸，写下你的职业目标。确保这些目标是 SMART 的。然后，列出实现这些目标的最大障碍。这些具体的需求将帮助你决定应该寻找什么样的导师。也许你需要发展新的技能，也许你需要扩大在某一特定领域的人脉，也许你需要建立进行艰难谈判的自信心。在了解你想成为什么样的人，以及成为这样的人的差距和机会在哪里之后，你就能确定导师如何才能真正帮助你。

2. 写出你理想中的导师的 "工作要求"​

在知道你的目标以及你需要怎么来实现这些目标之后，思考一下导师如何帮助你。描述出能够帮助你抓住最大机会/驾驭挑战的导师类型。具体地说，也许你需要导师帮助你完成一个项目，或者为你介绍特定行业内某一层次的人，或者指导你度过艰难的谈判。在你的工作要求中，一定要包括"为什么"－－就像公司希望潜在的应聘者了解他们公司的大方向一样，解释一下为什么指导你将会有更大的收获。当你与潜在的导师联系时，告诉他们你的工作要求，这样他们就会知道你为什么要找导师，从而更愿意提供帮助（第四和第五点中会提到）。

3. 通过你的二度关系寻找导师​

导师可以来自任何地方。他们可以是来自你LinkedIn人脉，专业领域的人脉，也可以是你在会议上认识的人。重要的是，虽然人们肯定很忙，但被邀请成为导师是一种巨大的赞美。人们可能会说不，但这依然是一种积极的交流，你要勇于去尝试，去提出请求，即使你认为对方不可能腾出时间给你。答不答应就让他们自己来判断。

4. 提出要求（并保持请求简单）​

第一次、第二次，甚至第三次请别人做导师时可能会让你有点尴尬。你很可能也从来没被邀请过做别人的导师，也没有教过别人如何为自己提出这个请求。拥抱这种不舒适的感觉。询问并没有什么坏处，但要慢慢来。邀请别人进行第一次对话来了解他们的工作和兴趣。一旦你们对对方有了更多的了解，如果有一致的意见，那么就可以提出更多的请求，请求对方做你的导师。反之，如果用长长的邮件去请求不一个不认识的人做导师，那就不太容易被接受。

5. 进行第一次谈话​

你与潜在导师的第一次谈话有两个目标。首先，你要确定这个人是否是你正确的导师人选。然后，搞清楚他们是否对指导你保持开放态度。你如何进行对话将取决于你自己，但总的来说，你会想做以下几件事:

• 让对方感到轻松。去一个对他们来说方便的地方，准备好咖啡（或茶），使会议没有压力。

• 花时间去了解对方。最好让导师多讲话，而你的讲话时间少于30%。

• 一开始就请求对方给你一些小的帮助也是可以的。事实上，它甚至可能会帮助你建立关系。

• 提出一个明确的请求："我很喜欢这次谈话。如果一个月内我在目标上取得一些进展，能不能再跟你跟进？"

• 表示感谢，然后再次通过邮件跟进，再次表示感谢。

6. 从简开始​

对于你的下一次会面，要在上次见面的基础上进行跟进，并保持简单。一旦对方确认会与你再次见面，就发送一封邮件提出议程，并暗示要建立长期关系。一个例子是"在我们下次聊天时，我希望我们能快速回顾一下上次的话题，然后我想进一步扩展这个话题。我会准备好一些具体的问题，我觉得你可以帮我回答。"

7. 确立一个结构化责任的过程，并签订导师协议​

在你们进行了一两次简单的谈话之后，试着提出一个更正式的要求：这个人愿意在接下来的六个月里，每月和你一起坐下来谈一次，直到你实现目标或解决问题为止吗？如果愿意，那么可以考虑写一份简单的单页文件，列出你们要在这六个月里完成的任务。虽然这可能看起来有点小题大做，但它将使你和你的导师更加清楚地知道目标是什么。它还将帮助你为每次会议确定明确的会议内容。你可以建议说："我真的很感谢你的时间和帮助，我很想确保自己能充分利用时间。我在想，我可以准备一份简单的文件，把我的目标、我对你的承诺，以及我希望在未来三个月内实现哪些阶段性的目标分享给你。我想这将有助于让我担起责任，有准备地来参加我们的谈话。你同意吗？"

8. 持续跟进并道谢​

每次见面后，你一定要发一封感谢信。除此之外，当你的导师关系结束后，你应该继续说谢谢。我曾经有一个被指导者在我们合作两年后给我发过电子邮件。这让我高兴不已。作为回报，我帮她建立一些新的有趣的联系，而她也是如此。所以请记住，请人帮忙是可以的，但一定要确保表示适当的感谢!

9. 选用合适的工具​

为了能够更高效地践行上述步骤，我给自己专门做了一套工具关系io - 端到端加密的个人 CRM，免费开放注册，现已开源，欢迎 star。

当你滔滔不绝时，很难察觉自己已经过度热情。你可能根本没意识到对方只是在礼貌性地回应，或暗示要离开。

跟别人说话分三个阶段。在第一个阶段，你的目标很明确，有针对性，言简意赅。 但随后你会无意识地发现，你越说越觉得轻松。 对你来说是如此美妙，缓解了紧张的情绪，但对对方来说就没那么有趣了。这就是第二个阶段----当你觉得说话感觉很好的时候，你根本没有注意到对方没有在听。

在第三阶段，你已经对自己讲的内容失去控制，并开始意识到你可能需要把对方拉回来。 这时候你的独白被伪装成了对话，你不自觉地感觉到对方有点烦躁，你猜会发生什么？

不幸的是，人们这时候的通常做法是说更多话来获取对方的注意力，而不是想办法让对方说话并倾听来获取对方的注意力。

为什么会出现这种情况呢？首先，原因很简单，人都有一种渴望被倾听的欲望。但其次，在谈论自己的过程中会释放出多巴胺，也就是快感荷尔蒙。 话多的人之所以会一直讲话，其中一个原因就是因为他们会对这种快感上瘾。

有一个方法，它对我有帮助，也许对你也有帮助。它被称为红绿灯法则。它在与大多数人交谈时有效，尤其是A型性格（Type A personalities）的人，他们的耐心往往比较差。

在谈话的前20秒，你是绿灯：只要你的发言与谈话内容相关，并是为对方服务的，你的听众就会喜欢你。除非你是一个极有天赋的演讲者，否则每次谈话时间超过大约半分钟就会被认为无聊且话多。所以，在接下来的20秒内，灯会变成黄色--现在，对方开始失去兴趣，或认为你太啰嗦。到了40秒大关，你的变成了红灯。偶尔你会想闯红灯继续聊天，但绝大多数的时候，你最好停下来，否则就有危险了。

红绿灯法只是阻止你说话太多的第一步。了解你说这么多话的根本动机也很重要。说更多话是不是只是为了让你感觉良好？说更多话是不是为了解释你的想法？还是因为你经常要听别人说话，当你找到一个说话机会时你就拼命宣泄？

不管是什么原因，说太多话通常会导致谈话中断，并可能导致你们轮流各说各的，而不是进行对话。 这对推动对话和你们的关系都没有效果。

有些人说话太多的原因之一是他们想向对方展示自己有多聪明，而往往他们内心深处其实并不觉得如此。如果这种情况，你要知道继续说下去只会让对方对你的印象大打折扣。

当然，有些人说得太多只是 "可能对时间的流逝没有感觉"。如果是这种情况，解决的方法不是去审视自己的内心，而是要培养自己对20秒和40秒有多长的感觉。比如说，在打电话时用手表计时。你会慢慢养成习惯，当你的交通灯还是绿色，或者至少是黄色的时候，你就会停下来。

最后，请记住，如果你不把对方纳入到谈话中，哪怕是20秒的谈话也会让人觉得很反感。为了避免这种情况，你可以提出问题，尝试着在对方说话的基础上说话，并想方设法让对方参与到对话中来。这样你就能得到真正的对话，而不是无效对话。

上桌玩牌要有足够的筹码 —— 招聘足够数量的高水平人才，这些人才要足够重视质量、足够聪明。你要向她们反复强调公司重视质量的文化，形成正式的惯例检验大块工作，该修的修。

战术上，有这样一条最佳实践 —— 降低做正确事情的难度。Stripe 技术团队做出了各种各样的取舍，以便能够保证任何工程师都能够改进系统的任何部分。鼓励责任感（ownership）。

有专门的内部工具检查国际化的水平，很无聊，但是得花时间做。要注意，这又回到了公司的文化问题，当一个做这件事情的 IC 说：“我上周花了一些时间做 i18n ” 的时候，他应该会默认，领导层足够重视这件事情，以至于会回答说：“当然你花了时间做了这件事情，棒棒哒。”

“开个工单给相应的组，会有相应的人来处理” 是个好实践，但是如果你能够推动这个系统更快更好地把这个工单修掉，你就更能够激励人去开工单。

公司会给专门的途径，比如邮件组的别名，来上报产品的质量 bug。有专门的组来 triage 这些任务，或者把任务分配到合适的组来修，有专门的惯例告诉整个公司质量 bug 的修复速率。

在做重大 API 变化之前，既要做内部测试，也要做外部测试。经常问一下“谁有一个真真正正的 Stripe 账号在手头？能不能更新到 beta 版本试一下？” 人们需要专门抽出时间来做这件事情，并且详尽地记录下来形成文档 —— 想象一下，你有一群挑三拣四的客户，虽然你很可能无法像用户那样深入地、广泛地使用自家的产品，但是这样做已经比瞎猜要好很多了。

发现“一块支付代码 5 年没有碰过了，不知道它是怎么工作的，竟然没有测试”，这种情况虽然很少见，但是对于工程团队来说，是宝贵的财富。

以上所有都不是什么高科技，也都不是能够保证质量的充分条件。Stripe 从来都不会满足当下的质量水平，不会被动地说说“我们的标准很高”，而是保持“主动地一直在去做”。

Facebook 产品设计副总监 Julie Zhuo 在 The Making of a Manager一书中，根据自己首次担任经理的经验，为那些想要成为优秀管理者的人们提供了一些切实可行的建议。

注重提高团队整体产出而非日常活动​

Julie刚成为Facebook的设计总监时，与普通管理者一样，认为其工作就是召开会议，了解工作进度，并给出反馈。此后近十年，她逐渐明白，管理者应使团队实现更好的产出，以及关注合作效率等更广泛的问题。优秀的管理者不应局限于日常活动，而是带领团队追求卓越的成果与进步。

安迪格鲁夫给管理者的第一课就讲到，一个经理的产出 = 在他影响之下自己组 + 相邻组的产出。

提出反馈时就事论事，并引入多方观点以供参考​

给成员提出反馈是管理者工作必不可少的一环。而这极具挑战性，因为批评有时会伤害别人的感情。为此，Julie提出了两种方法。其一是针对刚完成的任务及时进行反馈，无论电邮还是面谈，都确保对事不对人。其二是引入多个视角，使团队成员也了解到除你以外的其他人的观点，这些看法往往客观且独具价值。

召开会议时有明确目标和预期结果​

会议往往给人以冗长多余、官僚做派的印象，在其目的不明确时更甚。为保证效率，需安排流程，更需明确预期结果。预期结果可以是信息展示和共享或是做出某个决策。其中，后者更为复杂，需要所有被该决策直接影响的人员参与。管理者应确保相关信息能被完整客观地呈现，以及每个人的观点都被倾听与尊重。

为招聘决策提前做规划​

招聘是经理的一大重要职责。这并非是简单的尽快找人填补空缺，完全不考虑候选人的技能与经验，而是需要提前做规划。每年年初，Julie 都会分析并列出需要招聘的职位。她总结了以下几个问题，供那些想要自己制定招聘计划的管理者考虑。

• 考虑到团队的首要任务和预算，你能够实际雇佣多少新员工？
• 现有团队更需要哪些技能？有哪些已经充分具备？
• 新员工需要多少年的相关工作经验？
• 哪些个性或特质能加强现有团队的多样性？

想象你正处于最危险的伊拉克战场上，作为一个决定着战士生死的指挥官，你将如何领导你的团队？在 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。快节奏与慢节奏、高质量与低质量差别，通常是指数级别的，因为 —— 通常，快会让你更快更多，差会让你更差更少。