项目管理-任务分解

一、为什么要任务分解

　　1、情景

　　在做项目过程中，经常出现下面几种情况：

　　（1）研发说：“由于我当初写开发方案时没想到这个地方这么复杂（或者这里隐藏了很多需要开发的需求），所以想要延长开发时间”。

　　（2）项目上线后或者提测后发现，研发有些功能或逻辑没有实现，研发会说：“我开发的时候没有注意到”。

 

　　2、根本原因

　　上述这些研发的说辞看似解释了这些情况的原因，其实这只是借口，并不是问题的根本原因。

　　对于上述两种情况，研发没有想到某些地方存在复杂逻辑以及没有注意到隐藏需求。其根本原因是：

　　（1）在需求评审和分析时，没有仔细分析和拆解各个需求任务的逻辑和功能；

　　（2）在写开发方案时，比较粗糙和偷懒，没有把所有需求任务分解到最小粒度。

　　总结上述两个根本原因，就是在需求分析和编写开发方案时没有做好任务分解。

　　3、任务分解的重要性

　　要想避免由于没有做好任务分解，而导致项目进度或者项目质量的问题。首先研发需要重视任务分解的重要性。虽然产品经理已经把整个项目的目标和需求描写清楚了，但是距离研发立马上手编写代码还需要两个重要的关键步骤，就是需求分析和编写开发方案。

　　研发的需求分析，主要是以下工作：

　　（1）了解和掌握项目中的业务逻辑和业务流程，检查逻辑是否自洽；

　　（2）研究项目的开发可行性；

　　（3）将项目拆解模块（这个阶段不分解到最小粒度），主要是对项目的业务框架有基本的了解，以及对项目的体量和复杂度有大概的了解；

　　（4）将本次项目的重点和难点部分标记出来，可能时复杂逻辑、或性能要求、或公共组件和方法等（在编写开发方案和开发时需要重点考虑）。

 

　　编写开发方案应该要有以下几个步骤：

　　（1）根据需求文档，分解项目任务。

　　分解任务是一个综合步骤，具体怎么分解，下面会讲到。

　　分解任务时，一定要将任务一层一层分解，直到分解不下去。最终的最小粒度任务是可以交给任何一个开发人员，简单解释就可与让该开发人员明白具体要做什么。

　　这一步，需要产出一个任务列表（树状结构）。

　　（2）根据第一步产出的任务列表，对项目进行框架设计。比如，某个业务逻辑的实现可以参考哪个设计模式、哪些方法可以抽象成公共方法、哪个业务方法需要使用分布式事务或者消息队列。

　　 这一步主要是开发人员对整个项目的代码框架进行设计，设计后会得到一个新的任务列表（同样是最小粒度）。这里可以对重点部分和难点部分进行着重设计。

　　（3）根据任务列表，进行排期和分配任务。

 

　　通过分解任务和得到的任务列表，对我们有什么作用：

　　（1）可以准确且清晰地定义项目的范围；

　　（2）方便给开发人员分配任务，以及后续寻找负责人；

　　（3）可以提高估算开发时长的准确度；

　　（4）方便排出各个任务的优先级；

　　（5）有利于明确项目的影响范围，最大程度地降低风险。

 

二、怎么任务分解

　　每个研发都有自己分解任务的方法，但是都需要遵循以下分解原则：

　　（1）分解任务一定要以结果为导向，切不可为了分解而分解。我们分解任务是为了高效地做项目，使项目的最终交付结果符合预期。如果一个小项目，它已经很明确清晰地显示了各个子任务，那大可不必花时间和精力去做分解。

　　（2）分解任务要像剥洋葱那样，一层一层地往下分解。切不可跳过中间层级，像切洋葱那样一步就分解到最小单元。

　　（3）分解任务一定要分解到最小粒度，分解到不能再细分为止。

　　（4）从上向下分解，一般是分解某个任务或者功能的组成元素，这样也符合面向对象的编程范式-组合原则。在最下层可以描述最小任务的具体。

　　（5）要遵循 MECE 原则。

  　　　　a、相互独立，在同一层级上的任务有明确区分、不可重叠；

 　　　　 b、完全穷尽，不遗漏，尽可能穷尽所有的小任务。

 

　　分解完成后会得到一个项目任务的树状图，然后根据这个树状图进行代码框架设计。设计后根据树状图就可以产出一个项目任务列表，这个列表只是表格形式的任务分解树状图，只是它会有更详细的信息，比如每个任务的开发时长、负责人等。