极客时间已完结课程限时免费阅读

03 | DoD的价值：你完成了工作，为什么他们还不满意？

03 | DoD的价值：你完成了工作，为什么他们还不满意？-极客时间

03 | DoD的价值：你完成了工作，为什么他们还不满意？

2018-12-31 郑晔 来自北京
《10x程序员工作法》
课程介绍

讲述：郑晔

时长10:32大小9.65M

你好，我是郑晔。
在开始今天的讨论之前，我们先来看一个小故事。小李是一个程序员，有一天，项目经理老张来到他身边，和他商量一个功能特性的进度：
老张：这有一个任务需要完成，你看一下。
小李：这个不难，两天就能做完，两天以后就能上线。
两天以后，老张又来到小李的身边验收工作：
老张：怎么样，做完了吗？今天能上线吗？
小李：我的代码写完了。
老张：测试人员测过了吗？
小李：还没有。
老张：那今天能测完吗？
小李：那我就不知道了。
老张：什么？我可是答应了业务的人，今天一定要上线的！
很明显，老张有些愤怒，而小李也有些委屈。于是，老张、小李和测试人员一起度过了一个不眠之夜。
听完这个故事，你有什么感想呢？先不急，我们继续看后面的故事。
又过了几天，老张又来找小李，给小李安排一个很简单的功能。在小李看来，一天就能搞定，而按照老张给出的时间表，小李有两天时间处理这个功能。小李心中暗喜：看来我可以“偷得浮生一日闲”了。
两天以后，老张又来检查工作。
老张：这个功能开发完了吗？
小李：写完了，你看我给你演示一下。
小李熟练地演示了这个新写好的功能，这次老张很满意：
老张：做得不错。单元测试都写了吧？
小李：啊？还要写单元测试吗？
老张：要不为啥给你两天的时间？
怎么会这样？小李心里很委屈，自己明明已经很好地完成了工作，老张是不是故意在找自己的麻烦呢？
好，故事讲完了。是不是有些似曾相识的感觉呢？为什么小李辛辛苦苦地工作，老张却总能挑出毛病来呢？老张是不是来挑刺的呢？其实，老张才没那么闲，小李的委屈主要是因为他和老张对于“完成”有着不一样的理解。换句话说，他们之间存在一个理解的鸿沟。

理解的鸿沟

在这个模块里，我们讨论的主题是“以终为始”。那我们第一个问题就是，“终”到底是什么？在前面这个例子里，“终”就是“完成”，可是，小李认为他的活已经做完了，老张却认为他没做完。
怎么会这样？二人之所以有分歧，归根结底，就在于二人对“完成”的定义理解的不同。
在第一个故事里，作为项目经理，老张认为“完成”应该是“上线运行”，而程序员小李则认为“完成”是“功能代码编写完毕”。这中间存在的理解偏差，包括了测试人员的测试工作，可能还包括了运维人员的上线工作。
在第二个故事里，老张给了小李两天时间。小李认为这两天都是编写功能代码的，而老张想的是，小李应该自己写好功能代码和单元测试，可能还包括了功能测试，这中间的差异是测试代码的工作量。
因为双方的理解不一致，所以无论怎样努力，小李都不可能达成项目经理老张的要求，正所谓“南辕北辙”。
那该怎么办呢？小李会说，我又不是老张肚子里的蛔虫，怎么才能和他达成一致呢？答案很简单，既然双方的理解有差异，那就把这个差异弥合上，后面的问题便也不是问题了。
弥合差异的方式有很多，有一个最佳实践，它的名字叫 DoD（Definition of Done，完成的定义），从这个概念的名字便不难看出，它就是为了解决软件开发中常见的“完成”问题而生的。

完成的定义

DoD 这个概念本身并不复杂，它就是告诉我们怎样算是完成了，尽量减少因为理解偏差造成的各种浪费。具体怎么做呢？就是团队在开始工作前，先制定 DoD。以前面的场景为例，团队可以规定：
特性开发完成，表示开发人员经过了需求澄清、功能设计、编写代码、单元测试，通过了测试人员的验收，确保代码处于一个可部署的状态，相关文档已经编写完毕。
开发完成，表示开发人员编写好功能代码，编写好单元测试代码，编写好集成测试代码，测试可以通过，代码通过了代码风格检查、测试覆盖率检查。
大家都是聪明人，一旦 DoD 确定好了，谁该做什么事就一目了然了。这个时候，如果小李说“我已经开发完了”，却只是写好了功能代码，那就别怪老张手下无情了。
好了，你已经知道 DoD 是什么了，它简单到让人一目了然，相信你很快就能知道该怎样把它用到你的工作里。不过，我们不仅要知道怎么用，还要知道怎样让 DoD 更好地发挥作用。
DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。DoD 的检查项，就是我们开发产品所需的一系列有价值的活动。比如：编写代码、编写测试代码、通过测试人员验收等。什么样的活动是有价值的，也许每个团队的认识是不同的。但如果你的团队认为除了功能代码，其他都没价值，也许这是个信号，说明你的团队整体上是缺乏职业素养的，在这样的团队工作，前景并不乐观。
DoD 的检查项应该是实际可检查的。你说代码写好了，代码在哪里；你说测试覆盖率达标了，怎么看到；你说你功能做好了，演示一下。
DoD 是团队成员间彼此汇报的一种机制。别把“汇报”想复杂了，最简单的汇报就是说一句“这个功能做完了”。当我们有了 DoD，做事只有两种状态，即“做完”和“没做完”。在团队协作中，我们经常会听到有人说“这个事做完了 80%”，对不起，那叫没做完，根本没有 80% 做完的说法。
在前面的讨论中，我们所说的 DoD 只是从个人层面入手。在团队层面，我们也可以定义 DoD。
某个功能的 DoD，比如：这个功能特性已经开发完成，经过产品负责人的验收，处于一个可部署的状态。
一个迭代的 DoD，比如：这个迭代规划的所有功能已经完成。
一次发布的 DoD，比如：整个软件处于可发布的状态，上线计划已经明确。

站在 DoD 的肩膀上

至此，我们只是从软件开发团队内部协作的角度来谈 DoD。但实际上，它不仅局限在团队内部协作上，如果你可以放开思路，会发现 DoD 的思维在工作中用途非常广泛。比如，当我们需要和其他团队合作开发一个接口时，我们都知道第一步就是要把接口定义下来。
那么，怎样才算定义完成？很多团队认为落在字面上就够了。但是有了 DoD 的思维，我们定义接口，就会去明确定义可检查的检查项。那么在定义接口这件事上，什么才是“可检查”的呢？我们可以参照一个可运行的接口来进行评估。只要检查：
服务方提供的接口是不是和这个可运行的接口返回值是一样的；
调用方是否可以和这个可运行的接口配合使用。
谁错了，谁改去。你可能会问，应该参照哪些可运行的接口呢？这不难解决，现在模拟服务器的框架到处都是。如果你不介意的话，我的 Moco 就是这样一个开源项目，你可以看一下。
在协作中一旦确立好 DoD，我们甚至可以通过流程把它固化下来，从而更高效高质地完成工作。当然，我们在工作生活中难免会有一些临时的工作，它们没有复杂到需要一个流程，但是也可以用 DoD 思维来高效地解决。比如：
经常会有人过来，让我帮忙做些事。运用 DoD 的思维，我首先会问他我具体要做哪些事，确认好细节（相当于定义好“检查项”），然后我就知道，这个忙我能帮到什么程度。
我请别人帮忙的时候，也会很清楚告诉他，哪些事是需要他做的，尽量减少不必要的误解。
DoD 是一个思维模式，是一种尽可能消除不确定性，达成共识的方式。我们本着“以终为始”的方式做事情，DoD 让我们能够在一开始就把“终”清晰地定义出来。
人与人协作中，经常会出现各种问题，根本原因就是，有太多因为理解差异造成的误解，进而浪费了大量的时间，而 DoD 就是一种将容易产生歧义的理念落到实处的方法。

总结时刻

好，我们来总结一下今天学到的内容。首先，你应该知道，人与人协作，总会有这样或那样的理解差异。开始协作之前，我们最好先同步一下彼此的理解，确保之后不会因为理解不一致，而让协作方措手不及。
怎样解决大家的理解偏差呢，我介绍了 DoD（完成的定义），它是行业中的一种最佳实践，能够在团队内部很好地同步大家对“完成”的理解。好的 DoD 是一个可以检查的清单，可以确保你不遗漏任何事情。
如果深入领会 DoD，你会发现 DoD 可以灵活应用在不同的协作场景中。比如应用于个人工作、团队工作，甚至跨团队工作。当然，你也可以将它灵活地运用于各种生活场景，弥合人与人理解之间的差异，更好地协作与沟通。
如果今天的内容你只能记住一件事，那请记住：在做任何事之前，先定义完成的标准。
最后，我想请你回想一下，你在工作或生活中，是否发生过因为双方理解差异导致的问题或不快呢？有了 DoD 的概念以后，你是不是有了一些新的想法呢？欢迎在留言区留言。
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 59

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
02 | 以终为始：如何让你的努力不白费？
下一篇
04 | 接到需求任务，你要先做哪件事？
unpreview
 写留言

精选留言(80)

  • David Mao
    2019-01-01
    职场新人估计都会遇到文中所描述的场景，上下级没有做好DoD的沟通，其实这是上下级都需要的职场素养。 1.上级交代任务时把完成的指标和工作的边界讲清楚，下级根据要求去做。 2.反过来，下级应不断提高技能，能自己定义DoD, 请上级check, 毕竟上级不希望每次沟通都占用较多时间。
    108
  • 技术修行者
    2020-03-14
    看这篇文章的时候，我一直在想着小兔子和大灰狼的故事。 小白兔在森林里散步，遇到大灰狼迎面走过来，上来"啪啪"给了小白兔两个大耳贴 子，说"我让你不戴帽子"。小白兔很委屈的撤了。 第二天，她戴着帽子蹦蹦跳跳的走出家门，又遇到大灰狼，他走上来"啪啪"又给了小白兔两个大嘴巴，说"我让你戴帽子。" 兔兔郁闷了，思量了许久，最终决定去找森林之王老虎投诉。说明了情况后，老虎说"好了，我 知道了，这件事我会处理的，要相信组织哦"。 当天，老虎就找来自己的哥们儿大灰狼。"你这样做不妥啊，让老子我很难办嘛。" 说罢抹了抹桌上飘落的烟灰："你看这样行不行哈？" 你可以说，兔兔过来，给我找块儿肉去！她找来肥的，你说你要瘦的。她找来瘦的，你说你要肥的。这样不就可以揍她了嘛。" "当然，你也可以这样说。兔兔过来，给我找个女人去。她找来丰满的，你说你喜 欢苗条的。她找来苗条的，你说你喜欢丰满的。可以揍她揍的有理有力有节"。大灰狼频频点头，拍手称快，对老虎的崇敬再次冲向新的颠峰。 不料以上指导工作，被正在窗外给老虎家除草的小白兔听到了，心里这个恨啊。 次日，小白兔又出门了，怎么那么巧，迎面走来的还是大灰狼。大灰狼说："兔兔，过来，给我找块儿肉去。" 兔兔说："那，你是要肥的，还是要瘦的呢？" 大灰狼听罢，心里一沉，又一喜，心说，幸好还有B方案。 他又说："兔兔，麻利儿给我找个女人来。" 兔兔问："那，你是喜欢丰满的，还是喜欢苗条的呢？" 大灰狼沉默了2秒钟，抬手更狠的给了兔兔两个大耳帖子。 "靠，我让你不戴帽子。"
    展开

    作者回复: 还真是一个好比喻

    共 3 条评论
    50
  • javaadu
    2020-03-01
    之前就接过产品的类似这种需求：在某个全量表里加个字段。我接过来之后问了一个问题：业务方在什么场景下怎么用这个数据，产品经理语塞，最后这个需求转换成了一个数据分析产品的雏形，而我也用另一种临时的解决方案帮业务解决了问题。感受就是：产品当了传话筒，自己就必须搞清楚业务方要的到底是什么，也就是文中老师说的DoD

    作者回复: 你的产品经理在你升级之后暴露了 :)

    共 2 条评论
    25
  • Gojustforfun
    2018-12-31
    写的太好了，谢谢老师帮我捋清头脑中模糊不清的东西 前面那两个故事简直就是我和领导之间的情景再现，我的“完成”——实现功能，通过单元测试，他的“完成”——响应时间，系统吞吐，部署上线。 当你问他他的“完成”定义标准时，在得到解答后还会得到一个“这还用说的那么细吗，这不都应该知道的吗”排斥感，很反感这种感觉，每次问点啥后都有被鄙视被diss的感觉，不知该如何处理
    展开
    共 3 条评论
    16
  • 雍
    2018-12-31
    公司有各种checklist，类似于DoD，举例开发过程自检就有41项，开发人员真要check完，至少要花半天时间，大多时候开发都是复制以前的，然后“偷得浮生半日闲”了，项目组成员一多，全部复核一遍基本不可能，如何确定真正落实checklist就成个问题了，老师有没有什么好的建议?

    作者回复: 我很好奇，四十多项都检查什么，是否可以分享一下？

    共 8 条评论
    15
  • 喜悦
    2019-01-02
    今日概念： 1. DoD（Definition of Done）：DoD是一种思维模式，是一种尽可能消除不确定性，达成共识的方式； - DoD 是一个清单，清单是由一个个检查项组成的，用来检查我们的工作完成情况； - DoD 的检查项应该是实际可检查的； - DoD 是团队成员间彼此汇报的一种机制； 2. 任务开发只有两种状态：完成/未完成； 今日总结： 1. 使用DoD可以事先将需要做的事量化； 2. 一件事用了DoD之后，就确定了需要完成的具体事项，不会觉得自己有很多时间，提高效率； 3. 使用不同“粒度”定义DoD有助于换位思考，也可以加深对系统的理解； 使用DoD的例子 1. 做计划，比如制定年度计划；
    展开
    13
  • Demi
    2018-12-31
    我们在工作中，都不会去写单元测试，认为那是测试人员的事。也没有时间去写，写功能代码就已经要加班加点了。可能也是因为懒，公司没有强制写，只要代码能跑通，没有很大的BUG，就可以上线。我不知道其他公司是不是这样。我做Android开发3年了，待过两家公司。第一家创业干了四个月，公司倒闭了。然后目前这家公司呆了两年多了。老师您这么一分析，我得提高下职业素养了。
    共 6 条评论
    8
  • escray
    2020-05-31
    DoD 是思维模式，其实也是一种沟通的方式吧。 感觉有时候不光是定义完成的标准，而且需要明确重要概念的定义，比如说完成标准中的那些检查项。 在 Scrum 中也强调 DoD，而且是要在团队中达成共识。一般情况下，和直接领导达成 DoD 的共识应该并不困难。 一方面可以要求领导能够提供或者一起讨论，得出准确的 DoD，另一方面可能也需要适度的揣摩，站在对方的立场上考虑一下可能存在的要求。工作中，难免会遇见领导或者客户无法给出准确定义和描述的时候，而且很可能并没有那么多沟通的机会。 文中列举的老张和小李的段子，其实双方都有责任。老张应该讲清楚 DoD，而小李也应该向上管理（沟通）问明白。 留言中的例子，老板说弄一下考勤，那么单纯的导出考勤记录明显不能满足老板的要求，简单的做一下统计，是应有之意。而如果做的太多，花费过多的时间和精力，似乎也没有什么必要。喜欢揣摩上意的非技术人员也不少。 还有那个总是被大灰狼扇耳光的小兔子，该跳槽了。
    展开

    作者回复: 这个总结很到位。

    共 2 条评论
    7
  • 陈斯佳
    2019-07-09
    定义DoD清单，可以参考使用SMART原则，也就是Specific（具体），Measurable（可衡量），Attainable（可达到），相关性（Relevant），有明确截止日期（Time-based）

    作者回复: 很好的补充，但 SMART 原则一般是用来定义目标的，DoD 定义的是过程。

    7
  • 尚逸文
    2020-03-09
    老大让我这两天去熟悉一个框架，今天聊起来问我这个框架是什么，我笼统说了一遍在这个框架里数据的走向，老大表示要明白这个框架从底层究竟干了什么。惭愧，没学明白。看来我们对熟悉（这件事的DoD）的定义不同。 然后下班他把这个课程推给了我（捂脸

    作者回复: 欢迎加入！你老大对你很好。

    共 2 条评论
    6
  • 小伟
    2019-03-22
    在做任何事情之前，制定“可量化”的标准。
    6
  • Monday
    2018-12-31
    正在立2019的flag。刚好可以使用DoD
    6
  • pyhhou
    2018-12-31
    老师想请教一下，现在我在一家小公司里工作，人很少，没有项目经理，直接听老板讲需求，老板不怎么懂技术，没有什么技术基础，对一个项目需要的时间以及技术流程不太清晰，加上我也是刚从学校里出来可以说没啥经验，他问我多久能完成我也是迷迷糊糊的给不出一个大概的时间，老板需求也会时常变化即便是经常开会说想法讨论方案，没有严格的DoD，可能就像您说的完成功能代码就算完成，因此我们的产品老是出问题，想请问下在这种环境下如何更好的使用DoD呢，或者说是更好的提升工作效率，和上级沟通呢？是不是只要是时间足够就尽量把自己的DoD定严一些，或者是根据时间来定DoD？谢谢老师
    展开

    作者回复: 遇到一个不懂技术的老板是一件让人头疼的事。你可能需要拉着老板一起坐下来，先分析问题在哪里，再来谈如何改进。后面会讲到复盘与回顾，到时候，你可以尝试一下。

    5
  • 小小杨
    2021-03-24
    领导经常交代一些事 只是说要做好 没有说做到什么程度.开始按自己想象做 结果非常不好.反复返工.后来自己站在领导角度思考最终要什么结果，做到什么程度.有了结果做前先做确认，效果有显著提高，效率也高了，由于经常沟通默契也高了，达成一致很关键

    作者回复: 学有所成

    3
  • 小川
    2020-07-23
    老师，那应该按照什么标准来定义 DOD 呢。

    作者回复: 共识，团队的标准，如果团队里的人没有想法，就来参考我的文章，讨论出一个标准。

    3
  • 墨灵
    2020-03-29
    这段时间尝试实践以终为始的工作方式，效率确实比以前都有所提升了，产出的质量也有所提升。

    作者回复: 恭喜你的进步！

    3
  • 木子輕颺
    2019-01-19
    最近两周在开发一个功能模块，当时刚好错过 DoD 这篇文章，那时草率的觉得完成任务的周期，当然了我是按照开发人员的角度来自我定义完成的，就是开发完成，自测完成。 现在功能模块正式上线，超过当时预期的两倍。其实这里面的问题让我思考很多，如何正确评估一个任务的工作量？对一个完全陌生的功能，需要陌生的组件呢？ 现在重新回头看 DoD 觉得提前定义好概念，明确边界真的很重要。避免造成不必要的误解，最主要的可以缓解压力，免得高估自己。 当我开始下一项任务时，一定要对它拆开了看，明确每一个想当然的概念，把东西打散了拆开了看。然后再制定计划表。
    展开

    作者回复: 任务分解是下一个模块的重点，我们一起继续加油！

    3
  • 北天魔狼
    2018-12-31
    偶像，醒醐灌顶啊。一开始就要确定完成的定义。

    编辑回复: 😊加油！

    3
  • 奇小易
    2021-07-17
    # Why 工作中常见的例子，特性开发和功能开发，领导所理解的完成和员工所理解的完成不一致。这就是导致了自己明明完成了工作，领导却还是不满意的原因。 # What 人与人之间进行协作一起完成某件事时，必定存在理解上的差异，导致最终完成的结果无法让大家都满意。要让大家的理解达成一致，解决的方式可以使用业界的一种最佳实践。 DoD，完成的定义。就是一起协作完成某件事之前，先定义好这件事情完成的标准。 例如：功能开发的完成定义，完成功能代码、单元测试、集成测试，测试可以通过，代码通过了代码风格检查、测试覆盖率检查。 想要更好的发挥DoD的作用，需要三个 - DoD是一个清单，清单是由一个个检查项组成的，用来检查我们的工作完成情况。 - DoD的检查项，是实际可检查的。可以通过某种手段检查是否完成。例如：功能做完了，通过演示功能来检查； - DoD是团队成员间彼此汇报的一种机制。有了DoD之后，做事的状态就只有完成和未完成。（有什么价值吗？） # How 在团队层面也可以定义DoD，例如：某个功能的DoD，这个功能特性已经开发完成，经过产品负责人的验收，处于一个可部署的状态。 跨团队层面的DoD，例如：接口完成的定义。 工作生活层面的DoD，例如：帮忙买手机的定义。仅帮忙确定手机款式。 DoD是一种思考方式，让协作的双方尽可能达到共识的一种方式。
    展开

    作者回复: 学会，用起来！

    2
  • Stephen
    2021-05-20
    之前给自己估工作量的时候，往往直线思维。去想每个功能大概花多长时间，没有去考虑联调和最终测试的时间，到最后慌的不得了。这也是自己没有和自己做好DOD的情况

    作者回复: 少算了一个大模块的任务是一个大坑。

    2