项目管理之任务分配

一个项目需求确定了（需求这个东西永远没有确定的哪一天，时时刻刻都是在变化,但是经理认为确定了那就是确定了:P），然后项目经理给了一份需求文档就算真是开始开发了。大致用了一天的时间数据库就由一个开发人员设计了出来（其实对于这个速度我还是比较“惊讶”的，一天就把数据库设计出来，可见数据库中丢字段、字段设计不合理等等问题一定在后面等着我们），数据库经过大家统一“审查”过一遍之后没有什么异议（时间这么紧没有认真的去研究怎么会有异议呢？也只有到真正开发的时候才能发现问题），然后项目经理就开始分配任务准备进行开发了，但是这个分配任务也是大有学问的，笔者今天要谈的不是前期需求也不是数据库设计而是关于项目开发过程中对项目经理分配任务的感触。

充分了解业务

好像“业务”这个词是开发过程中提到的最多的一个词汇了，但是依然很多的团队在没有搞清楚业务的时候已经开始动手码代码了（后果不堪设想啊）。这里要说的是分配任务一定是在充分了解业务的基础之上，最尴尬的事情就是一项任务或者是一个技术难点要么没人做，要么多个人同时都在做。没人做的结果是最后整个团队抓瞎，多个人同时做的后果就是浪费了人力资源。所以说分配任务之前一定要充分的了解业务，然后将业务合理分解，最后才是将任务分配下去，最后的最后才是动手码代码。项目经理直接和业务需求打交道，而且负责团队中资源的调配，所以说分配任务这项工作一般情况下是项目经理的职责。也就是说项目经理能不能充分的了解业务决定了任务分配的是否合理。

最大限度的并行

团队开发的最大优势就是将大伙的力量集中起来，所谓的“集中力量干大事”就是这个道理。但是前提是将任务合理分配，不能说A童鞋的任务要依赖B同学的任务，最尴尬的局面莫过于在B童鞋做完之前A是不能开始动手的。要是这样的话合作开发就没有什么意义了，原本是一个多线程同时进行的工作由于任务分配的不合理，于是就不得不变成分时复用的情况。这就要求项目经理对整个项目有一个宏观的把控，先干什么后干什么，什么是根本什么是枝叶，这些都是需要项目经理非常清楚的。把这些搞清楚了再去分配任务就不会出现有的人忙死有的人闲死的情况。最好的办法就是将整个项目的流程制成甘特图之类的进度计划，先后主次一目了然。归根到底一句话，分时复用不可取，保证并行才是王道。

分配任务的方式

分配任务一般是两种方式，按照任务类型分配、按照业务分配

按照类别：

好处是某人固定负责这一类的工作，由于是一类固定的工作所以熟练度肯定越来越高，于是干活的速度也会越来越快。缺点是这个人只负责自己这一块儿的东西不能保证一个业务流程整体逻辑上的正确性

按照业务：

好处是某个业务中的逻辑性能够得到有效保证。缺点是但是由于一个人往往要负责多个技术难点所以开发效率自然就会相应的慢一些。

两种方式各有利弊具体采用哪种方式（或两种方式相结合）需要根据具体的项目来看，如果项目或者某个模块儿对业务逻辑要求比较高那么最好将任务分配给个人；如果项目中对业务逻辑没有过多的要求而是各个技术独立分明则最好将一类的技术配给一个或几个人。

知己知彼

分配任务之前项目经理不单单需要对项目的业务进行了解，还要对自己的组员有一个充分的认识，一定要给自己的组员分配他最擅长的模块，尽量保证每个人都做自己最擅长的地方（虽然这种可能性很少）只有这样整个项目的进度以及工程的质量才能有所保证。有些组员想挑战一些新的技术，或者想尝试不同层次的开发，这其实没有问题的。从项目经理的角度来说锻炼自己的组员更没有问题的，但是贸然把一个组员不熟悉的东西交给他这是对项目不负责任的表现。其实锻炼组员可以采用经验共享的方式，通过共享让一个人的经验变成多个人的经验，最终的效果就是组员中每个人都是万金油，遇到什么样的问题都可以解决。