【团队管理】IT项目团队管理.doc

公路养护管理系统项目团队管理 引言 如果在IT项目实施中选出最难解决的几个问题，那么管理问题一定名列前茅。在管理问题中，团队管理又是其中的难点。一个项目管理的好坏，很大程度就体现在团队的建设和管理上。团队管理涉及到管理学、心理学和哲学等诸多方面内容，具体实施起来还容易产生许多误区，因此，对项目主管的综合素质要求颇高。笔者进入项目管理领域的时间尚短，最近读了一些书籍，结合自己的一些经验，汇成一些心得体会，愿与朋友们共同提高。 　一、什么是团队管理？ 　　团队是由员工和管理层组成的一个利益共同体。团队成员拥有互补的知识和技能，他们协同工作，解决问题，实现共同的目标。 举个简单的例子：如果有一车沙从大厦顶上倒下来，对地面的冲击是不太大的，如果把一整车已凝固成整块的混凝土从大厦上倒下来，其结果就大不一样。团队管理就是把一车散沙变成已凝固成整块的混凝土，将一个个独立团队成员变成一个坚强有力的团体，从而能够顺利完成项目的既定目标。 　　沙土需要搭配石头、钢筋和水泥等才能形成混凝土，在团队建设中同样如此。每个成员的知识结构、技术技能、工作经验和年龄性别按比例的配置，达到合理的互补，决定了这个团队的基本要素。 　　有了沙土等基本要素，是否就一定是混凝土呢？没有水，没有搅拌，就还不行。混凝土中的水就是一种良好的团队氛围，团结信任积极向上的工作气氛。具备了这种气氛，意味着项目成功了一半。 项目主管在团队管理中相当于搅拌机的作用，组织会议、讨论、学习、攻关和休闲等活动，与成员之间形成良好的沟通，最终能形成明智的决策。 二、建立团队 职责和角色不清楚往往是造成软件项目团队管理混乱的一个重要原因，一个好的软件团队必须根据团队规模的不同和项目本身的特点对项目成员的角色和岗位进行明确的划分，这样团队中的每个成员才可能有清晰的责任和目标。 团队建设有四个因素，分别是： 管理因素：是“方向”。管理不善，则团队会迷失方向； 技术因素：是“根本”。没有技术实力，则有想法都不能实现； 人力因素：是“基础”。没有合适的人员共同参与，则工作无法顺利开展； 体系因素：是“保障”。没有有效的体系执行，很难保证工作的效率和质量。 根据几种因素，我们设计了几种方案： 人员 项目管理 用户需求 软件需求 架构 设计 开发 测试 维护 配置管理 5 方案1 负责人 P P P P P P 项目开发 P P P P P 方案2 项目负责 P P P P P 开发负责 P P P P P P P 设计开发 P P P P P 5-12 方案3 项目经理 P P 设计负责 P P P P 设计开发 P P P P P 测试 P P P 12 方案4 项目经理 P P 需求 P P P 架构 P P P 设计开发 P P P 测试 P P P 配置 P 软件开发不管采用哪种生命周期模型和开发方法论，整个过程都会包含需求，设计，开发，测试，配置管理等各项活动。而这些活动会对应到项目中的不同角色，项目中进行岗位划分后每个岗位成员可以兼职多个角色。形成相关的角色岗位矩阵。 　　方案一:项目负责人总览全局 　　对于小作坊的软件开发团队，可以由一个项目负责人总览全局。项目负责人承担从用户需求-软件需求-总体设计的所有工作。同时还需要做到整个团队进度规划，质量保证，配置管理和沟通协调等相关工作。所以小型项目团队对项目负责人的业务，技术和沟通管理等技能都要求较高，项目负责人是项目中的总体方案确认者和架构师。项目负责人能力和技能往往决定了整个软件项目的成败。 　　我们这里指的小型团队并不是只一个人单打独斗的项目，所以项目负责人最好不要介入到模块设计和编码活动中，而是应该把重点放在进度的控制和质量的保证上面。由于项目负责人一般有较强的技术能力，所以项目负责人可以承担项目中要使用的一些新技术的研究，项目中一些疑难问题的解决等相关工作。项目负责人还应该有计划的设计开发人员的代码进行Review，对发现的规范性，性能，复用差等问题跟项目成员确认，并写入到项目开发规范中。 　　方案二:项目负责人和开发负责人分离 　　在这种方案下项目负责人和开发负责人在软件需求和架构上的工作是重叠的。这两个岗位的人员共同来确认项目的总体方案和架构。项目负责人的重点在项目管理和与客户交流沟通上，只有确认清楚第一手的用户需求，才能开发出用户满意度高的软件。对于很多小型项目往往是用户需求都没有搞清楚就开工，项目成员完全凭借着自己的感觉在做系统，过程中又不注意与用户及时反馈和迭代，导致开发出完全不能使用的系统；开发负责人的重点是对整个开发过程负责，包括对项目经理确认的进度目标进行任务的进一步分解，安排后续的增量和迭代计划。方案二的重点是第一次解放项目经理，架构的核心移动到了开发负责人，而项目经理仅仅