互联网团队协作:可交付【连载二】

互联网团队协作:可交付【连载二】

XGiFtXGiFt
这里是互联网团队协作连载的第二篇--可交付,没有看过第一篇可以先去看看 互联网团队协作:可执行【连载一】

这篇既然是继承上一篇文章的,讲的是一个任务可以被执行的时候,执行完成后成功交付的问题,有些同学可能会觉得奇怪,已经做完了怎么会存在交付的问题?我这篇文文章说的可交付是指按照既定计划按时按量按质的完成成功交付。这种不可交付在工作中还是经常出现的,最常见的签收快递的一种情况:

你买了一部手机要求先验货,保证手机的型号正确并没有损坏再签收,而快递员却认为你要先签收才能拆快递。这个时候一般是收货人会做妥协,因为极端情况比较少见,但也有不少因此退货的情况,在我看来这两种情况都是不可交付的表现。

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

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

第二篇仓促得很,有问题大家还可以私信!

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

文章被以下专栏收录
还没有评论
推荐阅读