DTR工作法

*该方法学自某次培训

完成一件事,不论是接受方,还是授予方,都应该明确完成该事情的三件基本信息:交付物、完成时间、资源,即DTR(Delivery,Time,Resource)。

DTR

  • 交付物需要注意的是必须“可观测”,可以是文档,某件任务物品,或者某种可以看到的变化,心里变化,或者意向是不能作为交付物的。
  • 时间可以是周期,也可以是Deadline,或者两着混合来用。
  • 资源更好理解了,个人认为需要注意的是有哪些资源是不能用,但是对任务完成却很重要的。

比如:2018/10/30前,制作一份新部署好的会议室系统介绍报告PPT。按DTR简单拆分后如下。

D T R
会议室系统介绍报告PPT 2018/10/30前 1. 会议室系统项目 2. 规划书系统施工报告 3. 项目交付报告

子交付物

可以作为一个项目来做的事情,一般中间会有多个阶段,可以以“子交付物”来进行划分。而子交付一般以最终交付倒退出来

比如,上面的会议室系统介绍报告PPT,经过倒退,可以得出需要以下子交付物。

项目规划书,系统施工报告,部署结果报告 > 系统功能和使用说明书 > 系统测试结果 > 会议室系统介绍

子交付物的特点

  • 线性顺序,子交付物不可缺失,否则后面的交付物无法正常出现,比如如果没有系统部署结果报告,就无法出整个系统的功能和使用说明书(现有的成品系统除外),没有说明书,有没有做详细的测试并出测试结果。这也是为什么习惯性用倒退的方式来确认子交付物
  • 可观测,同样是交付物,自然需要满足交付物的基本特点。

工作任务

列出了子交付物,接下来就是需要规划工作任务并获得子交付了,工作任务有些可以同时进行,有些是有先后顺序的。心里有数可以跨子交付物执行任务。

给报告PPT规划工作任务后是下面这样的

有序任务 1,2,3,…
串接任务 ……

变数处理

规划好任务正常应该是着手开始工作了,但是如果要比较顺利的完成所有工作,还需要列一个变数清单,并列出对应的处理方案,这样才不不容易出现“明明是小事,干起来这么累”的感觉。按一个个任务,尽快能的列出可能会遇上的变数,并给出能够任务进行下去的应对方案。

这是一个看起来简单,但是却异常麻烦的事情,稍微大一点的公司都会碰到部门沟通协调的问题,每个人都有自己的立场,要是碰上这类问题造成的变数,只能是尽可能的换位思考并给出处理方案了,至于换位思考,只能是靠自己练习了。

变数 处理方案
联系不上人 找Manager或同事; 找其他可以给你资料的人
没有项目部署的相关文档资料 确认实施该项目,按正规流程是否需要制作相关文档资料; 联系负责人,或者找领导联系对方Manager,要求编写相关资料
需专业人处理的事情,对方拒绝合作,或者拖着不给结果 工作范围内的合理的需求,向对方Manager 提交正式的服务请求; 工作范围外的需求,自行卖萌或者找人卖萌。。。

如果是交给别人处理的项目,最起码要给到最上面的DTR,需要自己个人处理的小项目,按这个方案理清,可以随时知道自己需要做些什么,尤其是那种时间长,但是事情并不多的事情,如果不列出来,可能做着做着中间就给忘了。不论大项目还是小项目,按这个方案使用合适的工具,是不是最优的方案,但起码不会出错。

One thought on “DTR工作法”

Leave a Reply

Your email address will not be published. Required fields are marked *