互联网团队协做：可交付【连载二】

这里是互联网团队协做连载的第二篇--可交付，没有看过第一篇能够先去看看 互联网团队协做：可执行【连载一】。
这篇既然是继承上一篇文章的，讲的是一个任务能够被执行的时候，执行完成后成功交付的问题，有些同窗可能会以为奇怪，已经作完了怎么会存在交付的问题？我这篇文文章说的可交付是指按照既定计划按时按量按质的完成成功交付。这种不可交付在工做中仍是常常出现的，最多见的签收快递的一种状况：

你买了一部手机要求先验货，保证手机的型号正确并无损坏再签收，而快递员却认为你要先签收才能拆快递。这个时候通常是收货人会作妥协，由于极端状况比较少见，但也有很多所以退货的状况，在我看来这两种状况都是不可交付的表现。

在工做中不可交付的状况更加频繁，一方面是工做中的成果交付行为更频繁，另外一方面与公司对工做成果交付的规范不一致，有时候甚至会存在不少的我的因素致使交付问题。可交付的意义在于保证任务按照预期进行，不偏离最初的目标。要作到可交付的难度还要大于可执行，由于自己要作可交付就必定要在很高的程度作到可执行，一个没法执行的任务交付无从谈起。

作到可交付能够从几个地方着手，一是规范交付产物，包括交付形式，交付时间，交付标准。这里要考虑到上下游的流程，对交付物的格式作必定的限制。好比产品经理用的mac,交付的需求文档是Pages格式，开发使用的word，这样就不太好，这种交付就须要反复沟通。交付标准上就要看具体的工做了，从产品经理的角度来讲，若是其余同事反馈一个需求竟不能说明需求背景也没法说明提出需求的具体缘由的话，我会建议他再思考一下，提交这个需求能解决什么问题，能不能达到他想要的效果？二是养成交付成果的员工要对下游工做对接人责任心，这一点比第一点还重要，若是你们都只是搞定本身的工做，想尽办法交付本身的任务，无论给别人挖了多大坑，这样的交付毫无心义。

第二篇仓促得很，有问题你们能够私信,也可添加微信wz11-h！

预告：互联网团队协做：可追溯【连载三】