软件项目人力资源管理概述.pptVIP

第八章 软件项目人力资源管理;本章内容提要;第一节 项目人力资源管理概述;任命项目经理;项目人力资源管理的基本内容： 项目经理的确定 项目组织形式的确定 项目人员的获得与配备 项目团队建设 沟通管理;软件项目人力资源管理特性;人力成本：尽量使人力资源投入最小 人力资本：尽量发挥资本的价值，使人力资源的产出最大;本章内容提要;第二节 项目组织形式的确定;职能型组织结构;职能型组织结构的优点;当有项目成员调离项目或离开公司，所属职能部门可以增派人员，保持项目的技术连续性。 项目成员可以将完成项目和完成本部门的职能工作融为一体，可以减少因项目的临时性给项目成员带来的不确定性。;客户利益和职能部门的利益常常发生冲突，职能部门会为本部门的利益而忽视客户的需求。 当项目需要多个职能部门共同完成，或者一个职能部门内部有多个项目需要完成时，资源的平衡就会出现问题。 当项目需要由多个部门共同完成时，权力分割不利于各职能部门之间的沟通交流、团结协作。 项目成员在行政上仍隶属于各职能部门的领导，项目经理对项目成员没有完全的领导权。;项目型组织结构;项目型组织结构;项目经理对项目可以全权负责，可以根据项目需要随意调动项目组织的内部资源或者外部资源。 项目型组织的目标单一，完全以项目为中心安排工作，能够对客户的要求做出及时响应，有利于项目的顺利完成。 项目经理对项目成员有完全的领导权，项目成员只对项目经理负责，避免了职能型项目组织结构下项目成员处于多重领导、无所适从的局面，项目经理是项目的真正、唯一的领导者。;组织结构简单，项目成员直接属于同一个部门，彼此之间的沟通交流简洁、快速，提高了沟通效率，同时也加快了决策速度。;项目型组织结构的缺点;公司承担的项目之间处于一种条块分割状态，项目之间缺乏信息交流。;矩阵型组织结构;弱矩阵型组织结构;强矩阵型组织结构;矩阵型组织结构的优点;矩阵型组织结构的缺点;小组结构;2. 控制分散型（Controlled Decentralized, CD）。小组有一个固定的领导，来协调不同的任务。还设有若干二级管理者，负责子任务的完成。问题的解决仍然是集体行为，但解决方案的实现有小组领导划分给不同的成员或成员组。个人和成员组内部的交流是水平的，同时也存在沿着控制层次的垂直交流方式。 3. 控制集中型（Controlled Centralized, CC）。顶层的问题解决和小组内部协调由小组领导负责。小组领导和小组成员之间的交流是垂直的。;选择小组结构时，主要应考虑以下因素： 需解决问题的难度。 程序的规模（用代码行或功能点度量）。 小组存在的时间（小组生命周期）。 问题可已被分解和模块化的程度。 对系统的质量和可靠性的要求。 系统交付日期的紧迫性。 项目所需要的交流的频繁程度。;小组结构;如果需解决的问题可以被高度模块化，控制集中型（CC）和控制分散型（CD）小组结构则比较适合。 有经验表明，CC和CD型小组产生的软件缺陷比DD型小组少。 ;最早的小组结构形式是CC型，其代表是由Harlan Mills提出的“主程序员小组”（chief programmer team）。 主程序员小组的核心是一个具有丰富经验的工程师（主程序员），他负责计划、协调和审查小组的所有技术活动。技术成员（通常2到5人）负责分析和开发任务。一个后备工程师支持主程序员的工作，并在必要时可替换主程序员的工作。;可能还会有若干技术专家、书写员及文档管理员来支持主程序员。 文档管理员可以为多个小组服务，他的工作包括：维护和控制所有软件配置项，收集和整理相关数据，分类和索引可复用软件构件，支持小组的研究和评估工作等。;本章内容提要;第三节 项目团队的建设;项目团队人员的配备;责任分配矩阵;责任分配矩阵;团队成员管理计划;团队成员的培训;培训方式主要有两种： 岗前培训：对团队成员进行一些常识性的岗位知识和项目管理知识的培训； 岗上培训：主要根据开发人员的工作特点，针对操作中可能出现的实际问题，进行特别的培训，多偏重于专门技术和特殊技能的培训。;冲突管理;妥协（Compromising）：双方协商并且都做出一定程度的让步，寻找一种能使双方都可接受的方法。 求同存异（Smoothing）：双方都关注他们同意的观点，而避免冲突的观点。 撤退（Withdrawal）：把眼前的问题搁置起来，等以后再解决。 强迫（Forcing）：采用一方的观点，否定另一方的观点。一般不推荐这种方法。;团队成员的绩效评估;团队人员的激励;案例：IBM的人力资源管理绝招; IBM的薪资管理非常独特和有效，并能通过薪资管理达到奖励进步、督促平庸的作为，IBM将这种管理已经发展成为了高绩效文化（High Performance Culture） 。 2.薪资与职务重要性、难度相称