*该方法学自某次培训
完成一件事，不论是接受方，还是授予方，都应该明确完成该事情的三件基本信息：交付物、完成时间、资源，即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，需要自己个人处理的小项目，按这个方案理清，可以随时知道自己需要做些什么，尤其是那种时间长，但是事情并不多的事情，如果不列出来，可能做着做着中间就给忘了。不论大项目还是小项目，按这个方案使用合适的工具，可能不是最优的方案，但起码不会出错。
