深度工作笔记

房间里的大象 Elephant in the room

P1

管理类的书籍提出的理论有个通病，总是存在不证自明的前提和不言而喻的边界。这些因素往往被忽略，可能是因为显而易见的浅显。

作为一个严谨的杠精，我们不能接受任何未经审查其前提的思想，无论他它起来是多么理所当然。

P2

如何有效使用每一点脑力？

让你的头脑成为透镜，汇聚专注之光。让你的灵魂完全投入到头脑中的主导之物上，尽情吸收思想。

这个观点，不管是从透镜的光学理论，还是从时间管理的理论上看，都是那么无可争辩，那么理所当然。

《深度工作》这本书，一方面从理论上证明了深度工作方法的价值、稀缺性和重要意义，另一方面从实践上给出了具体的深度工作的哲学供读者选择，也给出来实现深度工作的路径和方法。

这本书论证严谨，滴水不漏，让我这样的杠精也无处下嘴。

P3

看了这本书以后，以及看书的过程中，我一直思考这么个问题，我们不想专注的深度工作吗？

我们的产品经理，一直都希望能静下心来，专注的写一写产品文档，认真的思考产品的逻辑。

每一个开发工作师，都不希望不断的被打扰，不希望无休止的处理线上问题，都希望能深度工作，专注的写代码。

QA测试工程师也不例外，除了刚入职没多久的时候可以专注的写用例、作测试，稍微资深一些后都是要处理大量琐碎的事情。

总起来说，不是我们不想专注的深度工作，而是做不到。

P4

浮浅工作界定难

浮浅工作是需要尽量的减少的，特点是价值不高，而且容易复制。

书中还提到另一类工作，就是杰克·多西做的工作，即不是深度工作，价值也不低。

在我们的日常工作实践中，常会遇到两个问题：

1. 工作价值高低的判断，缺少清晰的判断标准进行识别和界定。说实话，我们一般是自动过滤掉价值低的工作的，除非判断失误。潜台词也就是说，既然干了，那就是价值不会低了。
2. 可能跟工作性质有关，研发类的工作很难出现重复的事情。不管是写代码，还是别的什么工作，第一次做完，再一次做的时候，一般会写代码处理，或者重构，或者找工具了。

有个段子就说，某个工程师工作了十年，都没有写一万行代码。问他原因，他说在写在九千多行的时候，学会了写for循环。在产研领域，简单重复，容易复制的工作不太容易存在。

最小阻力原则

在本书中，最小阻力原则（The Principle of Least Resistance）基本上是以一个贬义词出现的。在要求不明确，缺乏度量的情况下，大部分人会倾向于采用当下最简单易行的行为，妨碍了保持专注的深度工作。

不管是KPI、OKR，还是携程重视测量的DMAIC方法论，都有个潜台词，就是说度量的成本并不高。或者，退几步说，度量是可能的。

我们这里所说的度量，是指可以用于发工资的考核依据的度量。那种代码行数、git提交次数、单元测试覆盖率等等，不能作为发工资依据的度量，不在讨论范围内。

如果度量是可能的，或者说直接量的测量成本不高，那么工资将计件发放，或者该工作将由市场采购完成。发放计时工资，即以代理量测量为依据发放工资，这本身就证明了度量的困难。这是一个争议话题，不展开讨论。

不管是采用信客原则相信工程师的工作，还是实践经验表明，最小阻力线就是一种自然现象，可以假定是当前给定条件下的最优解。

妨害深度工作的因素

妨害深度工作的因素并不总是那么显而易见。这个问题就是房间里的大象，我们不能不正视这个问题。

P5

结合日常工作，改善团队的深度工作水平，可能需要从如下三方面着手：

1. 总结能使工作聚焦的方式方法，并在团队中大力推广这些方法。
2. 不断总结检讨，为团队各位成员的深度工作创造必要的条件。
3. 为团队深度工作的开展提供必要的制度化保障。

P6

不管是系统的架构设计，还是日常的工作，分离关注点都是有效聚焦的好方法，一个关注点一个关注点的各个击破，而不是眉毛胡子一把抓。当然，如何很好的分离关注点，是一个值得研究的问题。我们的同学遇到的问题，往往并不是不知道需要分离关注点，而是不知道怎么分离关注点比较好。

我们有些开发工作和文档作业，在某种意义上说有重复，但又不是可以复制的工作。这种情况，深度工作投入聚焦到一个标杆工作，打个样儿出来。后面类似的工作有所参照，为大幅度提高效率。

我们有的工程师，由于工作原因，处理某类工作比较多，比较娴熟，可以顺势聚焦，让他主要负责些类的问题。问题总是涌向解决的出口，这也是最小阻力原则。当然，如果出于某种均衡的考虑，比如希望每个人的工作都有备份，适当做些分散，也没有毛病。

P7

把工作任务做成了一个优先级加权的任务队列，只在TOP1的工作上投入深度工作，非常有助于聚焦工作。

但是这个方法有几个难点：

1. 这种优先级加权的方法，运用之妙存乎一心，很难教人，很难授人以渔。
2. 优先级加权的方法之所以难以操作，很关键的是优先级不断在调整，令人目不暇接。
3. 在定级上，很容易唯上，老板说了很重要就很重要。也容易就近，最近提出的任务给的定级偏高。等等问题。那么如何让事情有自己的青红皂白、是非曲直，就比较难。优先级如何能在衡量标准上清晰、稳定，任务能够自我表达优先级，是个难题。

P8

在日常工作中，我们需要认真研究如何优先团队任务的分派工作，为各位同学能够深度工作创造必要的条件。

我的体会是给高阶工程师分派简单的活，以期把简单的工作做出深度。给低阶工程师分派大块的话，以使其可以专注的在某件事情上。比如：

1. 长于沟通，能够识别、分析产品本质需求的工程师多分派散碎需求。因为这类需求的时间会大量用在需求的沟通和反复上。
2. 有些工作的产出难以度量，有度量黑洞，不容易监控。这样的工作尽量分派给有自我实现素质的工程师，他们的成就感不是Leader给予的，而是自我识别、自我实现的。
3. 浮浅工作单项价值不高，有大量重复内容，但是又不能完全屏蔽掉。我们可以分派专门的资源，投入深度工作，用于开发、或选项高效处理浮浅工作的工具装备。

P9

制度化能够保障深度工作的流程、规范等，如：

1. 优化线上问题处理流程，制度化的减少处理浮浅工作。如果线上问题是BUG，那应该强化QA手段，降低线上BUG的级别，副作用小或没有副作用的BUG修改纳入日常的开发流程。如果线上问题不是BUG，那研发投入资源的实质意义就不大，纳入日常的产品需求流程，可以大量减少浮浅工作的处理。
2. 评审的流程强调文档的完备、设计的严谨，问题尽量前置，把更多的资源聚焦在文档的纸上作业，进行深度工作。
3. 冗长的会议占了浮浅工作很大的部分。尽量制度化的会前会磋商，准备可供表决的草案，以提高会议沟通的效率。

未尽话题

• 科学不讲故事，哲学也不讲故事。
• 成功人物的过往不足为凭，他的故事（历史）未必真，真也会有求证悖论。任何答案的正确性，都会在求证后失效。

形而上学的静态前提：

1. 职业活动范畴不变
2. 个人的认知能力不变

自我控制的边界：

1. 在社会化生产条件下，无干扰状态不取决于自我
2. 无干扰与自我专注没有必然的因果关系

• 机器和外包。君子不器，任何历史的发生，都会历史的消亡。
• 玛雅人的工匠精神。冯玉祥逼宫的时候，大内侍卫一个白鹤亮翅还没有展开，就被列兵一枪打死了。
• 企者不立，跨者不行，抗击打能力来源于厚积薄发的战略纵深

形而上学批判：

1. 冥想无禅机
2. 浪漫主义不能救中国。远避乡村。
3. 倒退没有出路。拒绝使用电脑

• 放下屠刀立地成佛，戒烟不需要意志力。
• 人民体育和金牌体育
• 稍遂其意
• 工作计划。逼水之法，取而不空，注而不溢

工程视角的深度工作，怎么做？

引申观点：

• 在社会化生产中，写代码再快，也不如砍需求快。
• 问题会涌向解决的出口。熵增是自然现象，收敛是人的规律。不顺势聚焦，就无法保障专注。
• 有意识的为自己、为团队拿出来一段不被打扰的美好时光。
• 分离关注点是聚焦的有效方法。
• 标杆垛角一本万利
• 自动化边界，高管边界

引伸：

• 掐尖咬西瓜：优先级加权的任务队列，养寇自重
• 授权和监管：下沉低优先级任务。度量黑洞。企业无界论和分隔、监管、采购。
• 专注能力和机动：由高级别工程师负责浮浅工作的机动和穿插，由低级别工程师负责深度工作。
• 装备现代化：装备高效处理低优先级任务的现代化工具是高优先级任务。现代化。杰森·本。

技术垄断（Technopoly）的政治正确

• 自由开发的精神
• 系统重构中对新技术、新版本的追求
• 数理实验传统的科学
• 携程的测量方法论