项目管理中的角色分工，项目经理如何给不同角色分配任务

(一)项目任务一般都怎么分配

比如：一个WEB开发项目。是按照MVC分层开发的原则去分配任务。就是一些人专门最View。一些人专门做Model。一些人专门做Contorl。这么分配。

或者是按照功能模块分配。一部分人做特定的功能。
一般都怎么选择的。
还有没有别的分配任务的方法。
都有哪些利弊。
问题补充：
欢迎大家多参与讨论.
本来是个讨论贴.
管理员非给我分到问答来了.
个人的观点.除非是比较小的项目.
一般情况下都是按照功能模块划分比较好.
MVC用来后期维护很好.在开发方面没什么长处?

我们之前的分法：
1.搭建基础架构，制定规范。
2.根据模块划分责任人。
但这样做法，也有弊端，每个人的编码规范，和页面规范执行的结果不完全相通。

如果人员足够，时间足够。最好的是：
横向按模块划分责任人。
同时纵向按照层来划分。这样接口可以定义的更明确。


（二）项目中的角色

部门经理 - DM - DepartmentManager
协调部门内和企业内的资源分配，协调各部门的沟通，并承上启下地为部门的整体业绩负责

项目经理 - PM - ProjectManager
协调项目内的资源分配，如日常沟通，进度管理等，为项目负责

产品经理 - PM - ProductManager
调研客户需求，进行需求分析，形成MRD文档，对产品规划，根据市场需求和分享规划产品发展路线，设计产品商业和服务模式，并定义相关功能模块 

技术经理 - TM - TechnicalManager
协调项目内的技术活动，推动主要技术决策，技术的可行性研究，评价、确认并文档化软件架构等

产品经理 vs 项目经理
产品经理是做正确的事，其所设计的产品是否符合需求，是否能给公司带来利润；
项目经理是正确的做事，在时间，成本和资源约束的条件下完成目标；

开发

项目组长 - PL - ProjectLeader
协调小组成员分工，指导、分配、落实小组成员工作，发挥团队职能优势，不断提高小组成员工作效率，优化工作流程，推进项目研发进度

系统架构师 - SA - SystemArchitect
主要负责大系统项目的架构设计

业务架构师 vs 技术架构师
业务架构师负责IT蓝图规划、统筹、协调多个产品线；
技术架构师是选型、抽象、提炼、封装公共组件，如缓存、消息中间件、服务框架、工作流等。让项目团队只关注业务代码的实现
软件工程师 - SE -SoftwareEngineer
编写代码，同时编写项目文档，如需求，详细设计，架构设计，用户手册，开发计划等；

程序员 - PG - Programmer：编写代码，实现功能；
测试

软件质量保证 - QA - Quality Assurance
创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷

软件测试工程师 - STE - Software Testing Engineer
主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象

QA vs STE
QA关注整个软件过程，保证过程和体系；
STE关注最终质量，采用设计、执行用例等方法去发现错误；

小结

通过理解并定位这些角色，我们可以更好的进行职能划分；
知道做什么，然后把事情做好；
然后再以管理者的角度优化整个流程与体系


（三）项目管理中的任务分配


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

充分了解业务

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

最大限度的并行

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

分配任务的方式

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

按照类别：

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

按照业务：

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

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

知己知彼

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


（四）如何让分配的任务高质量完成


在新项目中担任组长，项目刚刚启动的时候，前几个迭代组内完成任务质量不高，也会出现一些延期的情况。

对项目的情况进行分析，发现有几个共同的特征。

1，组员对分配的任务了解不够，表现在需求会上分配到某个任务，有不懂的地方但是没有问清楚，被动接受。代码开发完成，开始测试的时候，测试人员发现实现的功能和需求不一致，导致返工。这个占大多数。

2，对需求有一定了解，会后没有构思自己的思路。拿到需求直接开发，自己功能开发完成，测试也没有问题，但是整体测试的时候，发现对其他功能有影响。

3，工作态度不端正，工作过程中玩手机，四处游荡等导致工作任务不能及时完成。

解决方法：告知项目经理后实施的

正对第一种和第二种问题，要求在开发前给出一个设计方案，这个方案根据任务的难易程度，可以选择粗略的和详细的。详细的设计文档要评审和记录。必要时协助提供思路和方法。

第三种问题，通过单独谈话说明问题的严重性，并给出适当的警告。

实施后第一个迭代，效果不错。但是自己的任务加重了，主要是需要帮助其他同事理清思路，需要一些时间。

协助的工作需要保持一段时间帮助组员养成好的开发习惯。希望组员能够快速成长，自己也能轻松一些。

具体是否有效还要看后面的任务质量。多多总结


（五）项目经理如何分配工作


分配工作是项目经理的重要的工作之一，那如何分配工作效果比较好呢？下面就结合自己的经验分享下：

大概有如下几种方式：

1. 大包大揽型：

   但凡是项目经理，在技术和经验上都往往比团队成员强一些、多一些，因此有些项目经理就将大部分难活、累活分给自己。自己承担很大的压力。

   优点：团队压力小，较好保证进度和质量

   缺点：未必team买账，有些人希望挑战一点的任务。 自己太累，缺少经理处理项目管理中沟通、计划等工作。

   适用：适用团队成员确实比较junior，难活累活分下去，最后team压力大，还完成不好，或者返工或者自己再来收尾。避免浪费成本和时间。

2. 独裁型：

    无需跟team商量，自己将任务分配给认为最合适的人，大家就领任务干活就行了。

    优点：效率高，分工明确

    缺点：未必能人尽其能发挥某些个人的长处，可能忽略一些边界任务 - 毕竟人多眼多，容易想的更全面

   适用：适合对从事的项目有充分的经验和把握，明确任务的划分和边界。对team各个人员的技能、兴趣较充分地掌握

3. 民主型：

    大家一起群策群力，一起商量一起讨论分工。

    优点：发挥每个人的力量，充分参与，让team有参与成就感，加深team building，相互了解，共享。

    缺点：也可能存在一起掰哧，一起捣糨糊，总之民主也有其缺点。

    适用：团队氛围比较好，不存在几个team或者个人有利益或者personal的冲突的环境下。 team成员比较喜欢分享和表达自己的意见。

项目经理在分配工作要重点考虑两个事情，一是事的因素，任务的轻重缓急、难易程度、需要的技能等， 二是人的因素，是否与个人兴趣结合，愿不愿意接受，是否具备技能和擅长的地方等。