03 | DoD的价值:你完成了工作,为什么他们还不满意?
郑晔
该思维导图由 AI 生成,仅供参考
你好,我是郑晔。
在开始今天的讨论之前,我们先来看一个小故事。小李是一个程序员,有一天,项目经理老张来到他身边,和他商量一个功能特性的进度:
老张:这有一个任务需要完成,你看一下。
小李:这个不难,两天就能做完,两天以后就能上线。
两天以后,老张又来到小李的身边验收工作:
老张:怎么样,做完了吗?今天能上线吗?
小李:我的代码写完了。
老张:测试人员测过了吗?
小李:还没有。
老张:那今天能测完吗?
小李:那我就不知道了。
老张:什么?我可是答应了业务的人,今天一定要上线的!
很明显,老张有些愤怒,而小李也有些委屈。于是,老张、小李和测试人员一起度过了一个不眠之夜。
听完这个故事,你有什么感想呢?先不急,我们继续看后面的故事。
又过了几天,老张又来找小李,给小李安排一个很简单的功能。在小李看来,一天就能搞定,而按照老张给出的时间表,小李有两天时间处理这个功能。小李心中暗喜:看来我可以“偷得浮生一日闲”了。
两天以后,老张又来检查工作。
老张:这个功能开发完了吗?
小李:写完了,你看我给你演示一下。
小李熟练地演示了这个新写好的功能,这次老张很满意:
老张:做得不错。单元测试都写了吧?
小李:啊?还要写单元测试吗?
老张:要不为啥给你两天的时间?
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
DoD:消除理解差异,提升工作效率 在软件开发中,理解差异常导致工作不一致。本文介绍了DoD(Definition of Done,完成的定义)的概念和作用。通过制定DoD清单,团队可以明确工作完成的标准,减少理解偏差带来的浪费。DoD的检查项应该是实际可检查的,同时也是团队成员间彼此汇报的一种机制。在团队层面,也可以定义功能、迭代和发布的DoD,以确保整个软件开发过程的顺利进行。DoD 是一个思维模式,是一种尽可能消除不确定性,达成共识的方式。通过本文的介绍,读者可以了解DoD的概念和实际应用,以提高团队协作效率和工作质量。 DoD 可以灵活应用在不同的协作场景中,甚至生活场景,弥合人与人理解之间的差异,更好地协作与沟通。在做任何事之前,先定义完成的标准,这是本文最值得读者记住的一点。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《10x 程序员工作法》,新⼈⾸单¥68
《10x 程序员工作法》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(81)
- 最新
- 精选
- 技术修行者看这篇文章的时候,我一直在想着小兔子和大灰狼的故事。 小白兔在森林里散步,遇到大灰狼迎面走过来,上来"啪啪"给了小白兔两个大耳贴 子,说"我让你不戴帽子"。小白兔很委屈的撤了。 第二天,她戴着帽子蹦蹦跳跳的走出家门,又遇到大灰狼,他走上来"啪啪"又给了小白兔两个大嘴巴,说"我让你戴帽子。" 兔兔郁闷了,思量了许久,最终决定去找森林之王老虎投诉。说明了情况后,老虎说"好了,我 知道了,这件事我会处理的,要相信组织哦"。 当天,老虎就找来自己的哥们儿大灰狼。"你这样做不妥啊,让老子我很难办嘛。" 说罢抹了抹桌上飘落的烟灰:"你看这样行不行哈?" 你可以说,兔兔过来,给我找块儿肉去!她找来肥的,你说你要瘦的。她找来瘦的,你说你要肥的。这样不就可以揍她了嘛。" "当然,你也可以这样说。兔兔过来,给我找个女人去。她找来丰满的,你说你喜 欢苗条的。她找来苗条的,你说你喜欢丰满的。可以揍她揍的有理有力有节"。大灰狼频频点头,拍手称快,对老虎的崇敬再次冲向新的颠峰。 不料以上指导工作,被正在窗外给老虎家除草的小白兔听到了,心里这个恨啊。 次日,小白兔又出门了,怎么那么巧,迎面走来的还是大灰狼。大灰狼说:"兔兔,过来,给我找块儿肉去。" 兔兔说:"那,你是要肥的,还是要瘦的呢?" 大灰狼听罢,心里一沉,又一喜,心说,幸好还有B方案。 他又说:"兔兔,麻利儿给我找个女人来。" 兔兔问:"那,你是喜欢丰满的,还是喜欢苗条的呢?" 大灰狼沉默了2秒钟,抬手更狠的给了兔兔两个大耳帖子。 "靠,我让你不戴帽子。"
作者回复: 还真是一个好比喻
2020-03-14560 - javaadu之前就接过产品的类似这种需求:在某个全量表里加个字段。我接过来之后问了一个问题:业务方在什么场景下怎么用这个数据,产品经理语塞,最后这个需求转换成了一个数据分析产品的雏形,而我也用另一种临时的解决方案帮业务解决了问题。感受就是:产品当了传话筒,自己就必须搞清楚业务方要的到底是什么,也就是文中老师说的DoD
作者回复: 你的产品经理在你升级之后暴露了 :)
2020-03-01228 - 雍公司有各种checklist,类似于DoD,举例开发过程自检就有41项,开发人员真要check完,至少要花半天时间,大多时候开发都是复制以前的,然后“偷得浮生半日闲”了,项目组成员一多,全部复核一遍基本不可能,如何确定真正落实checklist就成个问题了,老师有没有什么好的建议?
作者回复: 我很好奇,四十多项都检查什么,是否可以分享一下?
2018-12-31915 - 尚逸文老大让我这两天去熟悉一个框架,今天聊起来问我这个框架是什么,我笼统说了一遍在这个框架里数据的走向,老大表示要明白这个框架从底层究竟干了什么。惭愧,没学明白。看来我们对熟悉(这件事的DoD)的定义不同。 然后下班他把这个课程推给了我(捂脸
作者回复: 欢迎加入!你老大对你很好。
2020-03-0929 - escrayDoD 是思维模式,其实也是一种沟通的方式吧。 感觉有时候不光是定义完成的标准,而且需要明确重要概念的定义,比如说完成标准中的那些检查项。 在 Scrum 中也强调 DoD,而且是要在团队中达成共识。一般情况下,和直接领导达成 DoD 的共识应该并不困难。 一方面可以要求领导能够提供或者一起讨论,得出准确的 DoD,另一方面可能也需要适度的揣摩,站在对方的立场上考虑一下可能存在的要求。工作中,难免会遇见领导或者客户无法给出准确定义和描述的时候,而且很可能并没有那么多沟通的机会。 文中列举的老张和小李的段子,其实双方都有责任。老张应该讲清楚 DoD,而小李也应该向上管理(沟通)问明白。 留言中的例子,老板说弄一下考勤,那么单纯的导出考勤记录明显不能满足老板的要求,简单的做一下统计,是应有之意。而如果做的太多,花费过多的时间和精力,似乎也没有什么必要。喜欢揣摩上意的非技术人员也不少。 还有那个总是被大灰狼扇耳光的小兔子,该跳槽了。
作者回复: 这个总结很到位。
2020-05-3128 - 陈斯佳定义DoD清单,可以参考使用SMART原则,也就是Specific(具体),Measurable(可衡量),Attainable(可达到),相关性(Relevant),有明确截止日期(Time-based)
作者回复: 很好的补充,但 SMART 原则一般是用来定义目标的,DoD 定义的是过程。
2019-07-097 - pyhhou老师想请教一下,现在我在一家小公司里工作,人很少,没有项目经理,直接听老板讲需求,老板不怎么懂技术,没有什么技术基础,对一个项目需要的时间以及技术流程不太清晰,加上我也是刚从学校里出来可以说没啥经验,他问我多久能完成我也是迷迷糊糊的给不出一个大概的时间,老板需求也会时常变化即便是经常开会说想法讨论方案,没有严格的DoD,可能就像您说的完成功能代码就算完成,因此我们的产品老是出问题,想请问下在这种环境下如何更好的使用DoD呢,或者说是更好的提升工作效率,和上级沟通呢?是不是只要是时间足够就尽量把自己的DoD定严一些,或者是根据时间来定DoD?谢谢老师
作者回复: 遇到一个不懂技术的老板是一件让人头疼的事。你可能需要拉着老板一起坐下来,先分析问题在哪里,再来谈如何改进。后面会讲到复盘与回顾,到时候,你可以尝试一下。
2018-12-315 - Stephen之前给自己估工作量的时候,往往直线思维。去想每个功能大概花多长时间,没有去考虑联调和最终测试的时间,到最后慌的不得了。这也是自己没有和自己做好DOD的情况
作者回复: 少算了一个大模块的任务是一个大坑。
2021-05-204 - 小小杨领导经常交代一些事 只是说要做好 没有说做到什么程度.开始按自己想象做 结果非常不好.反复返工.后来自己站在领导角度思考最终要什么结果,做到什么程度.有了结果做前先做确认,效果有显著提高,效率也高了,由于经常沟通默契也高了,达成一致很关键
作者回复: 学有所成
2021-03-243 - 小川老师,那应该按照什么标准来定义 DOD 呢。
作者回复: 共识,团队的标准,如果团队里的人没有想法,就来参考我的文章,讨论出一个标准。
2020-07-233
收起评论