*该方法学自某次培训

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

• 交付物需要注意的是必须“可观测”，可以是文档，某件任务物品，或者某种可以看到的变化，心里变化，或者意向是不能作为交付物的。
• 时间可以是周期，也可以是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，需要自己个人处理的小项目，按这个方案理清，可以随时知道自己需要做些什么，尤其是那种时间长，但是事情并不多的事情，如果不列出来，可能做着做着中间就给忘了。不论大项目还是小项目，按这个方案使用合适的工具，是不是最优的方案，但起码不会出错。