一、场景描述
郑晔在文中描述了这样一种现象，相信有开发经历的人多少有同感：
两天以后，老张又来到小李的身边验收工作：
两天以后，老张又来检查工作。
小李熟练地演示了这个新写好的功能，这次老张很满意：
很明显，老张有些愤怒，貌似总在挑刺，而小李也没有偷懒、有些委屈。于是，老张、小李和测试人员一起度过了一个不眠之夜。
二、理解的代沟
根据上面的场景，我画了两幅小李和老张的思考图，看下两者的代沟在哪儿，如下图所示。
很显然两者对完成的定义各不相同。对开发人员小李来说，完成容易理解为编码完成；而不去考虑代码测试和线上测试；对技术主管老张来说，完成的理解可能会更多一些，包括编码，测试，代码规范，审查，上线等等，有些老张脑子里的东西更多，比如下图所示：
为什么会有上面的差异？从立场来看，小李汇报的对象只有老张，而老张要协作的对象可能有产品经理、老板、总监、小李们。小李是从个人层面，关注的是一个点，老张是从团队层面，关注的是一个面。
各自定义差可能反应了一个信号，就是团队成员整体上缺乏职业素养，那么这个团队就危险了。从小李的角度无论怎么努力，都不可能满足老张的需求，从老张的角度总觉得小李偷懒，导致团队之间老是摩擦、挑刺，最后小李干的不爽了，老张也觉得小李孺子不可教，最后事没有做好，人跑了。
接下来就要回到作者提出的DoD概念(完成的定义)，从这个概念的名字便不难看出，它就是为了解决软件开发中常见的“完成”问题而生的。
三、完成的定义
这里的DoD在郑晔看来包含三个层次的含义：
- DoD 是一个清单，清单是由一个个的检查项组成的。
- DoD 的检查项应该是实际可检查的。
- DoD 是团队成员间彼此汇报的一种机制。
借助这三个含义，我模拟登录功能列了表格：
以上是站在测试用例的角度来写，一个简单的登录就可以包含18个开发功能点，做好登录并没有那么简单，这也就难怪小李和老张总是意见不一致。如果摊开这份清单用来验收登录功能的完整性，我相信小李和老张彼此都不会有什么意见。
但是这里有一个问题，就是老张根本不会去做这份清单！小李也没有这种意识，那谁来拟定？也许你会说引入中间层，就是测试人员来拟定，假设你们团队没有测试人员呢？
事情总是没有表面看起来的那么简单。这里再设计一份简化的验收清单
如此简化的功能也能多少避免小李和老张的鸿沟了吧？那么又回到前面的问题，谁来制作这份清单？
我个人的意见是小李来做，因为小李的势能没有老张高，那就多增加自己的动能了，显示自己做事的能力，同时也做一个同事眼中的好伙伴，领导眼中的好同事。等小李变成老李了，遇到小张也是小张来做这事。
四、DoD是一种思维方式
郑晔在最后又补充道：
这里的DoD看起来很完美，定义了验收清单，罗列了一系列验收项目，并固化成文档。但是，过程中有几个焦油坑需要去思考：
- 如何才能符合“可验收”？
- 彼此都无法想到的风险如何管理？
也许这需要团队的磨合了，从老张角度如果这事不会死人，其实没有必要去咄咄逼人，大不了后续进行迭代改进，否则逼得紧其实只会引起反弹，养成小李习惯性的逃避责任，形成团队推卸责任的文化就得不偿失了。
当我们有了DoD的思维方式，后面的事情也许会变得简单很多，郑晔举了个小例子让人折服：
五、总结
人与人的协作，总会存在理解上的偏差，如何去解决信息不同步的问题呢？DoD是一种最佳实践，它是包含了检查项的验收清单，而如何做到“可检查”需要双方重点沟通。DoD从大了看是一种思维模式，是一种尽可能消除不确定性，达成共识的方式。
借用郑晔的一句话：“如果今天的内容你只能记住一件事，那请记住：在做任何事之前，先定义完成的标准。”