程序员工作效率是由编程能力决定的吗？答案是“未必”。

程序员是一个忙碌的职业，与这个职业联系在一起的词儿，通常是忙碌、加班、熬夜、过劳、亚健康……当忙碌成为了主旋律，“高效”一词就自然浮出了水面。

可是，程序员工作效率是由编程能力决定的吗？答案是“未必”。

这些年，我一直在研究一件事儿：为什么那些大师级程序员，可以兼顾 N 倍于一般人的工作，还有条不紊？他们究竟用了什么工作法？根据我的观察与总结，他们往往绕不开下面四个工作原则。

以终为始

任务分解

沟通反馈

自动化一切

下面，就给大家先介绍前两个工作原则。

以终为始DoD

DoD（Definition of Done，完成的定义），从名字便不难看出，它就是为了解决软件开发中常见的“完成”问题而生的。DoD 本身并不复杂，它就是告诉我们怎样算是完成了，尽量减少因为歧义造成的各种浪费。

既然 DoD 是一个弥补理解差异的做法，那么它就应该在人与人的协同工作中起作用。其中，最常见的做法是在团队中确定好 DoD。比如：

特性开发完成，表示开发人员经过了需求澄清、功能设计、编写代码、单元测试，通过了测试人员的验收，确保代码处于一个可部署的状态，相关文档已经编写完毕。

开发完成，表示开发人员编写好功能代码，编写好单元测试代码，编写好集成测试代码，测试可以通过，代码通过了代码风格检查、测试覆盖率检查。

大家都是聪明人，一旦 DoD 确定好了，谁该做什么事就一目了然了。

DoD 是一个清单，清单是一个个的检查项，用来检查我们的工作完成情况。DoD 的检查项，就是我们开发产品所需的一系列有价值的活动。比如：编写代码、编写测试代码、通过测试人员验收等。

DoD 是团队成员间彼此汇报的一种机制。别把“汇报”想复杂了，最简单的汇报就是说一句“这个功能做完了”。当我们有了 DoD，做事便只有两种状态，即“做完”和“没做完”，根本没有 80% 做完的说法。

DoD 的检查项应该是实际可检查的：你说代码写好了，代码在哪里；你说测试覆盖率达标了，怎么看到；你说你功能做好了，演示一下。

在前面的讨论中，我们所说的 DoD 只是从个人层面入手。在团队层面，我们也可以定义 DoD，比如：

某个功能的 DoD，比如：这个功能特性已经开发完成，经过产品负责人的验收，处于可部署的状态。

一个迭代的 DoD，比如：这个迭代规划的所有功能已经完成。

一次发布的 DoD，比如，整个软件处于可发布状态，上线计划已经明确。

精益创业：验证产品特性的思考框架

精益创业提出“开发（build）-测量（measure）-认知（learn）”这样一个反馈循环和最小可行产品的概念。

当你有了一个新的想法（idea）时，就把想法开发成产品（code）投入市场，然后，收集数据（data）获取反馈，看看前面的想法是不是靠谱。无非得到两种结果：好想法继续加强、不靠谱的想法丢掉算了。不管是哪种结果，你都会产生新的想法，再进入到下一个循环里。在这个反馈循环中，你所获得的认知是最重要的，因为它是经过验证的。

我们能够接触到的大多数产品都可以放在这个框架内思考。当产品经理要做一个新产品或是产品的一个新特性，我们就可以用精益创业的这几个概念来检验一下产品经理是否想清楚。

比如，你要做这个产品特性，你要验证的东西是什么呢？他要验证的目标是否有数据可以度量呢？要解决的这个问题是不是当前最重要的事情，是否还有其他更重要的问题呢？如果这些问题得到肯定的答复，那么验证这个目标是否有更简单的解决方案，是不是一定要通过开发一个产品特性来实现。

任务分解马斯克的任务分解

特斯拉的创始人伊隆·马斯克（Elon Musk）同时还创建了太空探索公司 SpaceX。SpaceX 有一个目标是，送 100 万人上火星。美国政府曾经算过一笔账，把一个人送上火星，以现有技术是可行的，但需花费 100 亿美金。如果送 100 万人上火星就要 1 万万亿，这笔钱相当于美国 500 年的 GDP，贵到连美国政府都无法负担。

马斯克怎么解决这个问题呢？他的第一步是准备把人均费用降到 50 万美元，相当于一个人在地球上房子的钱。把原来的 100 亿降到 50 万，降低 2 万倍即可。

当然，降低 2 万倍依然是一个听起来很遥远的目标。关注点来了，马斯克的第二步是，把 2 万分解成“20×10×100”，这是一道简单的数学题，也是马斯克三个重点努力的方向。

“20”：现在的火星飞船一次只能坐 5 个人，马斯克打算把火箭造大一点，一次坐 100 人，这样，就等于把成本降低 20 倍。如果你关注新闻的话，SpaceX 确实在进行这方面的尝试。

“10”：马斯克认为自己是私营公司，效率高，成本可以降到 1/10。事实上，SpaceX 的成本目前已经降到了同行的 1/5。

最后的 100 是什么呢？就是回收可重复使用的火箭。如果这个目标能实现，发射火箭的成本就只有燃料成本，这也就是我们频频看到 SpaceX 试飞火箭新闻的原因。

这么算下来，你是不是觉得马斯克的目标不像最开始听到那样不靠谱了呢？正是通过将宏大目标进行任务分解，马斯克才能将一个看似不着边际的目标向前推进。

微操作

在ThoughtWorks 工作时，我的 Sponsor 是 ThoughtWorks 现任 CEO 郭晓（Sponsor，类似于工厂里师傅带徒弟的关系），他也是写代码出身的。他和我讲过他和 Wiki 的发明者 Ward Cunningham 一起结对编程的场景。

Ward 每天拿到一个需求，并不急于写代码，而是和郭晓一起做任务分解，分解到每个任务都很清晰之后，一个个任务完成就好了。当时郭晓虽然觉得工作很紧张，但思路却非常清晰。有时，他也很奇怪，因为在开始工作之前，他会觉得那个问题非常难以解决，结果一路分解下来，每一步都是清晰的，也没遇到什么困难就完成了。

任务分解是个好习惯，但想要掌握好它，大量的练习是必须的。我自己也着实花不少时间进行练习。随着我的练习增多，我越发理解任务分解的关键在于“小”。小到什么程度呢？有时甚至可以小到你认为这件事不值得成为一件独立的事，比如，升级一个依赖的版本，做一次变量改名。这样做好处就是，它保证了我可以随时停下来。

我曾读到过一个关于著名高尔夫球手“老虎”伍兹的故事。高尔夫球手在打球的时候，可能会受到一些外界干扰，一般情况下还好，如果他已经开始挥杆，这时候受到了干扰，一般选手肯定是继续把杆挥下去，但通常结果是打得不理想。而伍兹遇到这种情况，他会停下来，重新做挥杆的动作，保证了每一杆的标准。

伍兹能停下来，固然是经过了大量的练习，但还有一个关键在于，对于别人而言，挥杆击球是一个动作，必须一气呵成，而对伍兹来说，这个动作是由若干小动作组成，他只不过是刚好完成了某个小动作，而没有做下一个小动作而已。换句话说，大家同样都是完成一个原子操作，只不过，伍兹的原子操作比其他人的原子操作小得多。

一个经过分解后的任务，需要关注的内容是有限的，我们就可以针对这个任务，把方方面面的细节想得更加清晰。很多人写代码之所以漏洞百出，一个重要的原因就是任务粒度太大。