浅谈任务分解

 

本系列文章由ex_net（张建波）编写，转载请注明出处。

http://blog.csdn.net/ex_net/article/details/8741982

作者：张建波 邮箱： [e-mail] 电话：[phone] 欢迎来电交流！

 

在谈任务分解之前，我们先看一段摘要。

任务分解法（Work Breakdown Structure）
         WBS is also known as work breakdown system. it is a map of the project that identifies the products and work elements involved in a project.WBS is an outline of the project with different levels of details,it defines the relationship of the final deliverable to its subdeliverables,and in return, their work packages.
WBS helps to assume project managers that all the work are identified and established.

-----摘自百度百科

 

         作为一个管理者，拿到一个具体项目（Project）的时候，应当关上门静静的思考：如何完成这个任务（Task），为完成这个项目需要做哪些任务，为了完成这些任务又需要些什么资源？当这一系列都理顺了，那么就开始排排工期了。哪些事情先做、哪些事情后做。完成每1件事情的时间限。

       

 

      上图是我和我的团队使用一个项目管理软件。该软件是开源的。感兴趣的朋友可以从http://www.dotproject.net/ 这里下载到。采用PHP+MySQL。大概半个小时就可以装好了。

 

      在一个项目里，通常情况下时间限是已知的，都是由项目本身的工期决定的。因此我们在拆解任务的时候要尽量的做到“任务目标明确、任务内容清晰、任务执行权限合理”。只有这样的话，才能保证每一个任务的执行者，可以很快的理解任务、很快的去执行完成。

这是我们团队正在研发的一款产品，上图是dotProject对任务的管理界面。

 

在实际的管理工作中，很多朋友可能和我存在一样的困惑。

任务分大了，半天做不完，或者对“过程”失控；

任务分小了，感觉又是拖拉机工程，每个人都是一堆任务，看着任务单首先把人吓个半死；

 

最近，静下心来仔细思考后，得出这么一个结论：任务分解不合理、归根结底是“任人唯亲”造成。

在过去的时间里，我在任务分解的时候总是遵循这么几个流程：

   （1）手上有多少人？

  （2）他们能干什么？

   （3）开始安排任务。。。。。

  （4）安排不下去的，就先摆着。。。。。

 

仔细回头一看，难免就会发现问题。在分解任务的时候，过多的考虑了人的因素，尤其是自己人的因素了。这样分解出的任务是否还是“合理”的呢？

经过最近1~2年的项目管理的实际情况来看。任务分解坚决不能“因人而分”。

 

       作为项目管理者的我们，应该把目光放远，心胸打开。在分解任务的时候，要“因事而分”。因为需要做个事情，才会分解出对应的任务。那么在任务分解的时候应当按照下面的流程进行：

（1）目前项目的需求

（2）确定出关键任务节点

（3）梳理出完成这些关键任务节点需要进行哪些子任务

（4）形成完整的任务清单，采用1,2,3,4，，，，列出所有的任务

（5）从团队内部“招标”可以完成这些任务的队人；

（6）如果团队内部成员无法满足需要的情况下，从“世界”去“招标”更多的队员来参与。