第八章 软件项目团队管理

大家好，又见面了，我是你们的朋友全栈君。

本章内容提纲

8.1 软件项目团队管理概述
8.2 项目组织的规划
8.3 团队人员获取
8.4 团队建设和日常管理
8.5 沟通管理
8.6 软件专业人员的非技术素养

8.1 软件项目团队管理概述

• 什么是软件项目团队？

    软件项目团队是由软件项目的不同干系人所组成的，具有共同目标、紧密协作的集体。

• 软件项目团队包括所有项目干系人：项目发起人、资助者、项目组（开发团队）、供应商、客户等。

• 有时，软件项目团队特指项目组（开发团队）。

软件项目团队的特点           

• 与一般的人力资源相比，软件项目团队的特点是：

临时性；
团队成员的不稳定性；
年轻化程度较高；
是高度集中的知识型团队；
成员的业绩不易量化考核。

什么是软件项目团队管理

• 美国的项目管理协会（PMI）的《项目管理知识体系指南》（PMBOK）对“项目人力资源管理”有如下定义：

• 为最有效地使用项目参与人员而执行的各项过程。包括针对项目的各利益相关方展开的有效规划、合理配置、积极开发、准确评估和适当激励等方面的管理工作。

• 软件项目团队管理的定义：

软件项目团队管理就是采用科学的方法，对项目组织结构和项目全体参与人员进行管理，在项目团队中开展一系列科学规划、开发培训、合理调配、适当激励等方面的管理工作，使项目组织各方面的主观能动性得到充分发挥，同时促进高效的团队协作，以利于实现项目的目标。

软件项目的人力资源特征

人既是最大的成本又是最重要的资源

• 人力成本：尽量使人力资源投入最小

• 人力资源：尽量发挥资源的价值，使人力资源的产出最大

软件项目团队管理的主要内容

• 项目组织的规划

    确定项目中的角色、职责和组织结构。

• 团队人员获取

    获得项目所需的人力资源（个人或集体）。

• 团队建设

    提高团队成员个人为项目做出贡献的能力；提高团队作为集体发挥作用的能力。

• 团队日常工作管理

    跟踪团队成员工作绩效，解决问题和冲突，协调变更事宜。

• 沟通管理

    对在项目干系人之间传递项目信息的内容、方法和过程进行综合管理。保证项目干系人及时得到所需的项目信息。

团队协作的重要性

• 良好的团队协作可发挥出集体的力量。

“Linus法则”：只要眼球足够多，所有臭虫都好捉。
               —— Eric Steven Raymond
                    《大教堂与市集》

类比：蚁群觅食。众多蚂蚁各自分散地寻找食物，找到后用一种非常高效的、可扩展的通信机制互相通信。
蚁群觅食
    

• Linux的开发充分利用了全世界开发者的集体智慧，使得系统中的缺陷被迅速修复，而Linus通过在Internet上频繁地发布Linux版本来不断地向开发者反馈其开发成果。

• 在软件的高层设计中，在产品和项目的许多决策中，发挥集体智慧都是极为重要的，一个人往往按照其习惯的和擅长的思维方式和解决问题的方式，在一条路径上探索。而许多人在一个问题空间里进行探索，其效能远远超过单个人。

• Raymond说：Linus最重要的贡献不是创建了Linux内核本身，而是开创了Linux的开发模式。

• Linus说：我基本上是一个很懒惰的人，喜欢从实际上是别人做的事情上获得荣誉。

• 诸葛亮，智慧的代名词，治国能力极强，“鞠躬尽瘁，死而后已”。

• 但他事无巨细，都要亲自参与才放心。这样做不仅使自己过于劳累，也不利于人才的培养。他去世后蜀国人才凋零，很快就灭亡了。

• 一个企业或组织要想持续健康发展，不能只靠个别人鞠躬尽瘁，而要发挥集体的力量。

8.2 项目组织的规划

通过项目组织的规划，确定项目团队的角色，明确汇报关系（组织结构），分配人员职责，制定人员配置管理计划。
8.2.1 项目团队角色
8.2.2 项目的组织结构
8.2.3 项目人员职责分配
8.2.4 人员配置管理计划

8.2.1 项目团队角色

• 项目团队中的不同角色要形成一种相互配合、相互制约的关系，共同促进项目目标的实现。

• 软件项目团队中常见的角色包括：项目经理、系统分析人员、架构师、开发人员、测试人员、质量保证人员、项目管理和支持人员、市场人员、用户支持人员等。

• 不同类型的软件项目所包含的角色是有区别的。

• 例如：微软的一个软件产品项目团队通常由一个“产品单元经理”（Product Unit Manager）领导，包含有不同的角色。

微软的项目团队角色

• 产品管理人员

  获取和定义用户需求，市场分析和研究，产品推销和公共关系。

• 后勤管理人员

  对项目所需的设备、材料、软件工具等资源进行管理，保证项目能够平稳地进展。

• 注意：各种角色的地位是平等的，从而形成一个检查和平衡机制。

• 在小型项目中，可以简化团队的组成，也就是说，可以把一些角色组合在一起。

微软项目团队构成

• Windows2000 Team

内部IT        50
市场人员      100
文档人员      100
本地化人员    110
培训人员      115
程序经理      450
技术支持人员  600
技术传播人员  1120
开发人员      900
测试人员      1800
合计          5345

• Web Matrix Team

程序经理      2
开发组长      1
开发人员      7
测试组长      1
测试人员      13
合计          24

• 要明确定义角色的职责和能力要求。

• 项目经理是整个团队的核心角色，对项目的成败起着关键作用。

项目经理的责任

• 制定开发计划

  制定正确计划的前提是理解用户需求，理解项目目标。有全局观和系统观。

• 组织实施

  组建项目团队，为项目团队成员分配任务，有效调动每个人的能力。

• 项目控制

  监控项目的运行，积极预防问题的发生，纠正偏差。

项目经理的权利

• 组织领导要赋予项目经理足够的权利。

• 决策权：对项目事务有决策权。

• 项目资源的分配：对划拨给项目的资源（如人员和设备），项目经理有权决定具体的使用。

• 适当的财务权。项目经历要有适当的支配项目经费的权利，这样有利于控制成本，提高团队工作积极性。

项目经理的能力要求

• 管理能力

项目团队的组织、沟通、协调，充分发挥每个成员的能力和集体智慧。
项目团队与外部组织的沟通和协调。
很好的口才和写作能力。

• 技术能力。项目计划、人员的使用、技术评审等均需要一定的技术能力。

• 管理能力和技术能力哪个更重要？

• 视具体项目特征而定。

• 商业头脑。

  理解产品需求，市场策略，盈利模式、企业战略。

• 其他

  责任心、热情、抗压能力等。

8.2.2 项目的组织结构

• 项目的组织结构确定了团队成员（部门）之间的汇报关系。

• 项目的组织结构是项目团队所有成员为了进行分工协作，而在职务范围、权力和责任方面所形成的结构体系。

组织结构的本质是团队成员的分工协作关系；
组织结构的内涵是人们在职、责、权方面的结构体系，所以组织结构又称为权责结构。

• 项目的组织结构主要包括以下内容：

职能结构：为完成项目目标所需的各项业务工作及其比例和关系。
层次结构：管理层次（上下级）的构成，又称为组织的纵向结构。
部门结构：各管理部门的构成，又称为组织的横向结构。
职权结构：各层次、各部门在权力和责任方面的分工及相互关系。

• 没有什么好的或坏的组织结构，只有适合或不适合的组织结构。要根据具体的企业情况和项目情况来设计项目组织结构。

本小节的主要内容：
1.项目组织结构的类型
2.项目组织结构图
3.项目小组结构
4.有关项目组织人员规模的讨论

项目组织结构的类型

• 项目组织结构的类型与企业整体的组织结构有密切关系。

• 常见的项目组织结构有三种类型：

职能型
项目型
矩阵型

职能型组织结构的特点

• 职能部门是按照专业职能和业务来划分，例如研发部门、销售部门、财务部门等，研发部门又可进一步细分（如硬件、软件等）。

• 项目可以由一个或多个职能部门承担，项目成员分别受他所在的职能部门的经理管辖。

• 虽然也可能有项目经理，但其权利非常有限，通常只负责各部门间的沟通、协调、和监督作用，对项目成员没有完全的领导权。

职能型组织结构

职能型项目组织结构的优点

• 以职能部门作为承担项目任务的主体，可以充分发挥职能部门的专业优势和资源集中优势，有利于保障项目需要资源的供给和项目可交付成果的质量。

• 职能部门内部的技术专家可以同时被该部门承担的不同项目所使用，节约人力，减少了资源的浪费。

• 同一职能部门内部的专业人员便于相互交流、相互支援，对创造性地解决技术问题很有帮助。

• 当有项目成员调离项目或离开公司，所属职能部门可以增派人员，保持项目的技术连续性。

• 项目成员可以将完成项目和完成本部门的职能工作融为一体，可以减少因项目的临时性给项目成员带来的不确定性。

• 这种组织结构适用于主要由一个部门完成的项目或技术比较成熟的项目。

职能型项目组织结构的缺点

• 不能完全做到以项目目标作为驱动力和导向。职能部门往往集中精力于对本部门有益的工作上，而项目和客户的利益可能得不到优先考虑。

• 决策过程要经过多个管理层，过程繁琐，因此对客户和市场的需求反应迟钝而且容易失真。

• 当项目需要由多个部门共同完成时，权力分割不利于各职能部门之间的沟通交流、资源调配、团结协作。

• 项目成员在行政上仍隶属于各职能部门的领导，项目经理对项目成员没有完全的领导权。

项目型组织结构

• 项目型组织结构中的部门完全是按照项目需要进行设置的，是一种单目标的垂直组织方式。存在一个项目就有一个项目部门。

• 项目经理具有高度独立性、对项目享有完全的领导权。

• 完成每个项目目标所需的全部资源完全划分给该项目，完全为该项目服务。

项目型组织结构的优点

• 项目经理对项目可以全权负责，可以根据项目需要随意调动项目组织的内部资源或者外部资源。

• 项目型组织的目标单一，完全以项目为中心安排工作，能够对客户的要求做出及时响应，有利于项目的顺利完成。

• 项目成员有项目所需的技能，专属于本项目，不需要与其他项目共享关键人员。

• 组织结构简单，项目成员直接属于同一个部门，彼此之间的沟通交流简洁、快速，提高了沟通效率，同时也加快了决策速度。

项目型组织结构的缺点

• 不同的项目组织，资源不能共享，即使某个项目的专用资源闲置，通常也无法应用于另一个同时进行的项目，人员、设施、设备可能会重复配置，造成一定程度的资源浪费，成本较高。

• 公司里各个独立的项目型组织处于相对封闭的环境之中，公司的宏观政策、方针很难做到完全、真正的贯彻实施，可能会影响公司的长远发展。

• 在项目完成以后，项目型组织的使命即完成，项目成员有可能闲置甚至被解雇，对项目成员来说，缺乏一种事业上的连续性和安全感。

• 公司承担的项目之间处于一种条块分割状态，项目之间缺乏信息交流的机会。

• 没有强大的职能群体，技术支持困难，也阻碍了公司能力的持续提高。

矩阵型组织结构

• 同时具有职能型组织结构和项目型组织结构的特征，试图把两者的优点结合起来。

• 根据项目的需要，从不同的职能部门中选择合适的人员组成一个临时项目组织，由项目经理领导，他对项目的成功负有全部责任。

• 项目经理的职权由总经理直接授予。拥有一定的组织地位和权力。

• 职能部门有责任向项目提供最好的技术支持。

• 矩阵型组织结构的性质有强弱之分，这取决于项目经理对所拥有的职能资源的影响力。

• 当项目经理比职能经理对职能资源的使用有更大影响力时，矩阵结构才是强有力的。此时项目经理有能力提供技术指导、委派职责，对项目成员的工作成效有很大影响。

• 如果职能经理比项目经理更有影响力，那么矩阵结构就是软弱的。

矩阵型组织结构的优点

• 专职的项目经理负责整个项目，以项目为中心，能迅速解决问题。

• 公司的多个项目可以共享各个职能部门的技术骨干和其他资源，节约成本。

• 既有利于项目目标的实现，也有利于公司宏观目标方针的贯彻。

• 项目成员在事业稳定性上的顾虑减少了。

矩阵型组织结构的缺点

• 容易引起职能经理和项目经理权力的冲突。

• 资源共享也能引起项目之间的冲突。

• 项目成员（处在矩阵行和列的交织处）有多头领导。他们的任用、升迁、解雇的权力仍由职能部门经理把持，而职能部门经理对他们的绩效考核又必须通过项目经理才能完成。当职能部门经理和项目经理的命令相冲突时，可能会出现无所适从的情况。

使用矩阵型组织结构的注意事项

• 横向的项目组织与纵向的职能部门各自负责的工作和管理内容要明确，否则容易造成责任不清、双重指挥的混乱局面。因此矩阵型组织良好运作的关键是这两类部门的协调。

• 由于项目经理和职能经理都有各自的权力和责任，他们必须站在项目大局的高度进行良好的沟通和协调。避免出现以下情况：项目经理只考虑什么对自己的项目有利（而不关心其他任何方面），职能经理则认为自己的部门比任何项目都重要。

• 由于项目成员往往来自不同的职能部门，其工作目标和工作方法可能有所差异，在项目初期的磨合阶段可能会产生矛盾。要求项目经理及时识别矛盾，并控制和疏导由此产生的对抗。

• 由于项目成员从属于某个职能部门，项目经理必须解决好以下问题：

如何才能激励成员为项目工作，并保证对项目忠诚？
当项目指令和规则与部门政策相冲突，尤其是当成员感到自己的职能部门上司可能会对自己不满时，如何说服他按项目的要求做？

组织结构类型的选择

• 没有一种组织结构类型是万能的。要根据项目的实际要求和项目所处的企业环境进行选择。

• 大多数现代组织会在不同层次上用到所有这些结构，形成一种复合型组织结构。例如，基本属于职能型结构的公司，也可能会建立项目型的团队来开发重要的项目，这样的项目型团队具有项目型组织结构的许多特征，它可以从不同职能部门调来全职工作人员，可以制定自己的一套办事程序，甚至可以不按照标准和正规的请示报告系统来开展工作。

项目组织结构的设计

• 选择了项目组织结构的类型，只是在宏观上确定了项目组织结构的性质。

• 在此基础上，还要设计项目组织的各组成部分及其报告关系、责任关系。设计结果通常用项目组织结构图表示。

• 对于大型项目，可以分层次进行设计，即先考虑整体的组织结构，再逐层细化。

项目整体组织结构（举例）

箭头线表示管理流

开发组组织结构（举例）

项目支持组组织结构（举例）

项目小组结构

• 在大型软件项目中，通常根据软件的功能模块将从事开发的人员划分为若干小组(Team)，每个小组负责一个功能模块的开发。

• 小组的组织结构对小组的工作效率和工作质量有很大影响。

• 项目小组的人员要“少而精”。人数太多的小组会产生较大的沟通开销和沟通问题，影响工作效率和软件质量。

项目小组结构的类型

• 小组的结构形式可分为三类：

1.民主分散型（Democratic Decentralized, DD）。小组没有固定的领导，而是根据不同的任务来指定临时的任务协调员。决策由小组通过协商来共同制定，小组成员之间的通信是水平的。
2.控制集中型（Controlled Centralized, CC）。顶层的问题解决和小组内部协调由小组领导负责。小组领导和小组成员之间的交流是垂直的。
3.控制分散型（Controlled Decentralized, CD）。小组有一个固定的领导，来协调不同的任务。还设有若干二级管理者，负责子任务的完成。问题的解决仍然是集体行为，但解决方案的实现由小组领导划分给不同的成员或成员组。个人和成员组内部的交流是水平的，同时也存在沿着控制层次的垂直交流方式。

不同小组结构的比较

• 集中式的小组结构有权威指导和统一管理，能以较快的速度完成任务，适用于处理简单问题。分散式的小组结构能够激发人员的创造力和集体智慧，产生更多、更好的解决方案，因此更适合于解决困难的问题。

• 民主分散型（DD）的小组容易产生更高的士气和工作满意度，因此适用于那种生存期较长的小组。

• 民主分散型的结构内部通信路径较多，通信开销也较大。但适用于解决那种可模块化程度较低的问题，因为解决这样的问题需要大量的通信和交互。

小组结构

• 如果需解决的问题可以被高度模块化，控制集中型（CC）和控制分散型（CD）小组结构则比较适合。

• 有经验表明，CC和CD型小组产生的软件缺陷比DD型小组少。

• 选择小组结构时，主要应考虑以下因素：

需解决问题的难度。
软件的规模（用代码行或功能点度量）。
小组存在的时间（小组生命周期）。
问题可被分解和模块化的程度。
对系统的质量和可靠性的要求。
系统交付日期的紧迫性。
项目所需要的交流的频繁程度。

小组结构举例-主程序员小组

• 最早的小组结构形式是CC型，其代表是 “主程序员小组”（chief programmer team），最早由IBM公司于20世纪70年代初期开始采用。

• 主程序员小组的核心是一个具有丰富经验的工程师（主程序员），他负责计划、协调和审查小组的所有技术活动。程序员（通常2到5人）负责分析和开发任务。一个后备程序员支持主程序员的工作，并在必要时可替换主程序员的工作。

• 可能还会有若干技术专家、书写员及文档管理员来支持主程序员。

• 文档管理员可以为多个小组服务，他的工作包括：维护和控制所有软件配置项，收集和整理相关数据，分类和索引可复用软件构件，支持小组的研究和评估工作等。

小组结构举例：微软开发小组

• 在微软，一个稍大一些的产品部门，分成几个功能块组（Feature Team）。每个功能块组一般负责一个具体的功能模块，并由10到50人组成。根据功能模块的大小，功能块组可能被分成若干子功能块小组。最后每个功能块小组一般不超过10人，其中至少会有一个程序经理（Program Manager），几个开发人员和几个测试人员。

• 程序经理全权负责功能模块的完成。对功能进行定义、规划和设计；进行各种决策，掌握进度；协调开发和测试人员的工作并跟踪错误；协调本开发小组和外部其他部门（市场、用户支持等）的工作。

• 程序经理是管理者和协调者，不直接参与编程和测试。不同于其他软件公司的开发小组“技术负责人”。

有关项目组织结构和人员规模的讨论

• 项目组织中人员的沟通开销会随着人员数量的增加而增加。

• 假设项目中每个人员都可以和其他任何人员通信，那么通信路径数会随着人员数的增加而呈指数增加。

沟通路径

• 沟通开销也与项目组织结构有关。项目组织结构通常限制了人员之间的通信路径（例如一个人员或部门主要和有汇报关系/责任关系的人员或部门通信，控制集中型小组内部的通信路径少于民主分散型）。

• 由于不同人员/小组负责开发不同的软件模块，软件模块设计的弱耦合性也可有效减少不同人员或小组之间的通信。

开源项目的典型通信机制

• 世界各地的代码贡献者和测试者把他们的代码和缺陷报告通过Internet传送给项目核心组，项目核心组通过频繁地在Internet上发布新版本而对他们提供反馈，而代码贡献者或测试者之间几乎不需要通信。

8.2 项目组织的规划

8.2.1 项目团队角色
8.2.2 项目的组织结构
8.2.3 项目人员职责分配
8.2.4 人员配置管理计划

8.2.3 项目人员职责分配

• 为项目组织中的部门或个人分配职责，避免因责任不清而造成工作互相推诿，责任互相推卸的现象。

• 责任分配矩阵（Responsibility Assignment Matrix, RAM）是用来对项目团队成员进行分工，明确其角色与职责的有效工具 。

责任分配矩阵举例

RAM还可以用于更详细地定义团队成员与任务间的关系。

项目人员职责分配

• 对于很小的项目，可以通过RAM把职责直接分配给个人；对于较大的项目，RAM可以划分出多个层级，先把职责分配给子团队或部门，然后再继续细分。

• 如果需要详细描述角色的职责，也可使用文字叙述的方式，包括角色的职责、授权、能力和资格等信息。这样的文件可以称为岗位描述、角色-职责-授权表格等，对将来的项目有很好的参考价值。

8.2.4 人员配置管理计划

• 人员配置管理计划描述何时以何种方式满足项目的人力资源需求。

• 在项目期间，人员配置管理计划可能会不断进行更新，以指导项目的人员招募和团队建设工作。

• 根据具体项目的需要，人员配置管理计划可以是详细的或宽泛的，内容也有所区别，但一般应考虑以下内容。

人员配置管理计划的内容

• 项目团队组建的相关问题。例如，人力资源来自于组织内部还是外部？团队成员需要同地办公还是远距离分散办公？组织的人力资源部门可以为项目管理团队提供多大程度的支持？

• 时间表。说明项目对每个或每组团队成员工作时间的安排，以及招募活动何时开始。资源直方图是一种常用的人力资源图表工具。

资源直方图

• 成员遣散安排。确定团队成员的遣散方法和时间。在最佳时机把团队成员撤离项目，可节约成本，而且如果把成员平滑过渡到其他项目中去，可提高士气。

• 培训需求。如果预期分派的项目成员不具备所需的技能，则可以制定相应的培训计划。

• 表彰和奖励。用明确的奖励标准和有计划的奖励系统来促进所期望的员工行为。

• 合规性。人力资源的使用要符合相关的政府规定和其他既定的人力资源政策。

8.3 团队人员获取

根据项目团队的角色和职责、项目组织结构图和人员配置管理计划，获取完成项目工作所需的人力资源。
本节内容提要：
8.3.1 获取团队人员的方法
8.3.2 虚拟团队

8.3.1 获取团队人员的方法

• 预分派

  在某些情况下，一些成员已预先分派到项目中工作，例如在竞标过程中承诺分配特定人员到项目中，或项目的成功依赖于特定人员的专有技能。

• 谈判

  大多数人员的获取需要经过谈判。例如项目经理需要与职能部门经理或其他部门负责人谈判，以获得所需要的人员。
  在谈判时，项目的影响力会起作用。

• 招募

  当企业缺少完成项目所需的内部人才时，就需要从外部获得所需服务，包括招聘和分包。

在获取和任用项目团队人员时，除考虑人员的专业技能外，最好能结合人员的性格特征和兴趣，做到“知人善任”。

获取团队人员后的成果

• 项目人员分派到位

• 明确人力资源可利用情况

  人力资源可利用情况记录了项目团队成员在项目上可工作的时间。明确了项目团队成员在时间安排上的冲突，包括休假时间和承诺给其他项目的时间。

• 更新后的人员配置管理计划

  实际的项目人员分配很少能够完全符合最初的人员配置管理计划，因此需要对其进行变更。

8.3.2 虚拟团队

• 虚拟团队为项目团队人员的招募提供了新的可能性。虚拟团队是指拥有共同目标，但工作地点分散，在工作过程中很少或完全不面对面交流的一组人员。

• 电子通信设施的完善（电子邮件、即时通信、视频会议等）使虚拟团队成为可能。

虚拟团对的好处

• 可以组建在同一组织工作，但工作地点十分分散的团队。

• 雇用方式更为灵活，可以为项目团队增加特殊技能和专业知识，即使项目人员不在同一地理区域。

• 可以纳入在家办公的员工。不仅节省了工作空间和设备的费用，而且可能提高工作效率。

• 可以安排不同时区的人员的任务分工来减少任务的持续时间。

• 可以把行动不便的人纳入项目团队。

虚拟团对的约束

• 分配给虚拟团队员工的任务需求要十分明确。

• 协调分散的员工也许很难，特别是跨国和跨时区的情况。

• 计算工作量和付费也许需要按件计算，而不是按工时计算。

• 远程或者素不相识的协作者之间也许缺乏信任感。

8.4 团队建设和日常管理

• 项目团队建设是指提高团队成员的技能，以加强他们完成项目活动的能力；提高团队成员的信任感和凝聚力，以促进团队协作。

• 项目团队日常管理是通过观察团队的行为、管理冲突、解决问题，以及评估团队成员的绩效，来促进项目的进展。

• 团队建设和日常管理涉及到人际关系和人的情感、动机等因素，所以不仅需要制度上的保障，还需要项目管理者的“情商”，进行“人性化管理”。

8.4.1 培训

• 通过对团队成员的培训，可以提高项目团队的综合素质、工作技能和技术水平。同时有助于提高项目成员的工作满意度，降低项目人员的流动比例和人力资源管理成本。

• 针对项目的一次性和约束性（主要是时间和成本的制约）的特点，对于团队成员的培训主要采取短期性的、片段式的、针对性强、见效快的培训。

• 培训方式主要有两种：

岗前培训：对团队成员进行一些常识性的岗位知识和项目管理知识的培训；
岗上培训：主要根据开发人员的工作特点，针对操作中可能出现的实际问题，进行特别的培训，多偏重于专门技术和特殊技能的培训。

• 培训的方法有多种，例如课堂培训、在线培训，指导和辅导等。

8.4.2 人员激励

• 激励就是通过一定的引导行为来激发团队成员的工作动机和工作热情。

激励要因人而异。常见的激励方式有：

• 薪酬激励：必须让薪酬与绩效挂钩。

• 机会激励：获得机会实现职业发展。让员工有平等的机会参加学习、培训、从事有挑战性的工作和获得升迁等。

• 环境激励：企业内部良好的工作环境和氛围。例如管理层对工作人员的支持和关注，宽松和富有建设性的技术创新氛围等。

团队人员的激励

• 情感激励：员工需要被认同、被尊重、被关心。

• 有关激励的理论研究有很多，例如马斯洛的需要层次理论，海兹伯格的激励理论，麦格雷戈的X-理论、Y-理论，超Y理论，Z理论，期望理论等。

马斯洛的需要层次理论

• 人类的需要是分层次的（见下图）。人们的行为受到这一系列需要的引导和刺激。

• 在软件企业中，知识型员工普遍追求高层次的需要，企业管理者不能只停留在满足员工低层次的需要上。例如：

• 知识型员工的自尊心强，不要在公开场合批评和贬低员工的工作。

• 软件开发人员是追求自我实现的群体，企业管理者可以帮助他们制定职业生涯规划，尽力提供培训、工作锻炼的机会来帮助员工实现其职业发展需要。

Z 理论

• Z理论是威廉.大内于1981年在《Z理论》一书中提出的，其基本思想是：企业经营管理者与员工的目标是一致的，二者的积极性可以融合在一起。Z理论的主要观点包括

（1）企业对员工实行长期或终身雇用制度，使员工与企业同甘苦共命运，并对员工实行定期考核和逐步提级晋升制度，使员工积极关心企业的利益和企业的发展。
（2）企业经营者不单要让员工完成生产任务，而且要注意员工培训，使他们成为多专多能的人才。
（3）管理过程既要运用统计报表、数据信息等鲜明的控制手段，而且要注意对人的经验和潜在能力进行诱导。
（4）企业决策采取集体研究和个人负责的方式，由员工提出建议，集思广益，由领导者做出决策并承担责任。
（5）上下级关系融洽，管理者对职工要处处关心，让职工多参与管理。

8.4.3 增强团队凝聚力的措施

• 通过一些措施加强团队的实际存在感。例如定期召开会议（包括项目启动会，项目评审会等）；可创建一个团队空间，在其中可以张贴项目组织结构图，项目进度图表等，大家可以一起工作和讨论问题。

• 可以组织一些正式或非正式的团队建设活动，增进团队成员的友谊，确立良好人际关系。

8.4.4 绩效评估

• 绩效评估就是工作行为的测量过程，即用过去制定的标准来比较工作绩效的记录及将绩效评估结果反馈给职工的过程。

• 绩效评估的根本目的是发现问题，完善工作，并使员工更好地发展。

• 按照目的划分，绩效评估的类型有：奖金分配评估，提薪评估，业绩评估，人事评估，职务评估，晋升评估。

• 绩效评估程序：

    （1）建立业绩考核体系。
    （2）将业绩期望告知员工。
    （3）测量实际业绩。
    （4）比较实际业绩和考核标准。
    （5）进行矫正。

8.4.5 冲突管理

• 项目的高压环境、责任模糊、技术上的不同观点等都可能引起团队成员之间的冲突。

• 如果适当管理，冲突的解决会带来益处，有助于提高创造力和做出好的决定，相反则会带来负面影响。

• 要管理冲突，应回答下面几个问题：

为什么会产生冲突？
该怎样处理冲突？
能否预测和防范冲突？

冲突的诱发因素

• 冲突的诱发因素有很多，常见的有：项目管理方式方法、技术见解、人力资源分配、成本估计、进度规划等。

• 各种原因的冲突在项目的不同阶段，其表现强度是不同的。例如技术冲突和管理方式方法冲突在项目后期的表现强度较弱，而在项目的中期则相对较强。

冲突的主要处理方式

• 1.问题解决（Problem Solving）：也称为“正视”（Confrontation）。双方一起积极地定义问题，收集问题信息，开发并且分析解决方案，直到最后选择一个最合适的方法来解决问题。这是冲突管理中最有效、最可取的一种方法。

• 妥协（Compromising）：双方协商并且都做出一定程度的让步，寻找一种能使双方都可接受的方法。

• 求同存异（Smoothing）：双方都关注他们同意的观点，而避免冲突的观点。

• 撤退（Withdrawal）：把眼前的问题搁置起来，等以后再解决。

• 强迫（Forcing）：采用一方的观点，否定另一方的观点。属于“赢-输”式的处理方式，除非有特殊情况，一般不推荐这种方法。

• 采用哪种处理方式视冲突的具体情况（为什么冲突？与谁冲突？）而定。

冲突管理的规划

• 在项目初期就应该对冲突管理进行计划，分析在项目的各阶段会出现哪些冲突，该怎样避免，怎样处理。

• 不适合在整个企业层次上建立冲突管理的政策和程序。因为每个项目产生冲突的情况和解决冲突的方法都有特殊性。

案例：IBM的团队建设绝招

• IBM有一个让所有员工坚信不疑的游戏规则：干得好加薪是必然的。为了使每位员工的独特个性及潜力得到足够尊重，IBM一直致力于工资与福利制度的完善，并形成了许多值得我们参考的特色。

1.激励文化
    薪水是企业管人的一个有效硬件，直接影响到员工的工作情绪。 IBM的薪资管理非常独特和有效，能通过薪资管理达到奖励进步、督促平庸的效果，IBM将这种管理已经发展成为了高绩效文化。
2.薪资与职务重要性、难度相称
       每年年初，IBM的员工特别关心自己的工资卡，自己去年工作干的好坏可以通过工资涨幅体现得有零有整。IBM的薪金构成很复杂，但里面不会有学历工资和工龄工资。
        IBM员工的薪金和其岗位、职务重要性、工作难度、工作表现和工作业绩有直接关系，工作时间长短和学历高低与薪金没有必然联系。在IBM，你的学历是一块很好的敲门砖，但绝不会是你获得更好待遇的凭证。
       在IBM，每一个员工工资的涨幅会有一个关键的参考指标，这就是个人业务承诺（Personal Business Commitments, PBC）。只要你是IBM的员工，就会有个人业务承诺（每年一次），制定承诺计划是一个互动的过程。从总裁开始，写下PBC，然后层层沟通和传达。某层员工会根据上
级经理人的目标去计划自己的目标，然后让下一层员工去建立他们较小的目标，如此类推。这样可以很有效地把所有员工的注意力重新放到最重要的事上。而且使各部门和上下级之间的目标都是关联的，降低了部门的自我中心意识。
你和你的直属经理坐下来共同商讨这个计划怎么做才切合实际，几经修改，你和你的老板其实立下了一个一年期的军令状，老板非常清楚你一年的工作及重点，你自己对一年的工作也非常明白，剩下的就是执行。大家团结紧张、严肃活泼的干了一年，到了年终，直属经理会在你的军令状上打分，直属经理当然也有个人业务承诺计划，上头的经理会给他打分，大家谁也不特殊，都按这个规则走。IBM在奖励优秀员工时，是在履行自己所称的高绩效文化。
3.薪资充分反映员工的成绩
       个人业务承诺考核通常由直属上级负责对员工工作情况进行评定，上一级领导进行总的调整。每个员工都有进行年度总结，并与他的上级面对面讨论这个总结的权利。上级在评定时往往与做类似工作或工作内容相同的其他员工相比较，根据其成绩是否突出而定。评价大体上分10—20个项目进行。
       评价工作全部结束后，就在每个部门甚至全公司进行平衡，分成几个等级。例如，A等级的员工是大幅度定期晋升者，B等员工是既无功也无过者，C等员工是需要努力的，D等员工则是生病或因其他原因达不到标准的。
       从历史上看，65%—75%的IBM公司职工每年都能超额完成任务，只有5%~10%的员工不能完成定额。那些没有完成任务的人中只有少数人真正遇到麻烦，大多数人都能在下一年完成任务，并且干的不错。

• 简评

       激励在哪里都是需要的，激励的最佳力度取决于业绩与薪水之间的权衡。以业绩为基础的付酬方法的难点在于业绩的评估，其中的一个问题就是员工的行为一般不会完全转变成可以评估的业绩，而IBM的个人业务承诺（PBC）针对每个员工制定了单独的评估标准，很巧妙地解决了评估难的问题。同时，IBM不光注重自身的长远发展，同时又兼顾了员工的个人需求。

8.5 沟通管理

• 沟通是人与人之间的思想和信息的交换。沟通从一定意义上讲，就是管理的本质。据统计，项目经理80%以上的时间用于沟通管理。沟通失败是项目失败的重要原因。

• 沟通管理就是确定项目干系人的信息需要，并保证以合适的方式，把信息及时传递给他们。

• 沟通管理的基本原则是及时性、准确性、完整性、可理解性。

8.5.1 沟通需求分析

• 通过沟通需求分析可以明确各种项目干系人的信息需求。信息需求包括信息的类型和格式，以及该信息的价值。

• 为降低通信开销，应限制通信渠道。因此沟通需求分析需要依据项目组织结构图和项目团队成员的职责关系。

8.5.2 沟通方式

• 按传播媒介的方式可划分为书面沟通、口头沟通和电子媒介。

• 按组织系统可分为正式沟通和非正式沟通

• 按信息传播方向可分为上行沟通、下行沟通、平行沟通和越级沟通。

• 采用什么沟通方式取决于信息的内容、对信息需求的紧迫性以及项目环境等。

正式沟通

• 正式沟通是通过项目组织明文规定的渠道进行信息传递和交流的方式。

• 正式沟通的一种主要形式是“项目评审”。项目评审以会议的方式进行，用来检查项目当前的执行情况，并确定采取的管理措施。

• 项目评审可分为三种：定期评审、阶段评审和事件评审。

定期评审

• 1.定期评审：根据项目计划和跟踪采集的数据定期（例如每周）召开评审会议，对项目的执行状态进行评审，检查项目规模的变化、各项责任落实情况、项目进度是否得以保证、资源调配是否合理等等，对于出现的偏差制订纠正措施。

• 定期评审会议既是交流项目信息的方式，也是一个很好的激励方式。

阶段评审

• 2.阶段评审（里程碑评审）：在项目计划中规定的时间点（或里程碑处），对该阶段的任务完成情况和产品进行评审，目的是检查当前计划的执行情况，检查产品是否合格，对项目风险进行分析处理，并对下一阶段的项目计划进行必要的调整。

事件评审

• 3.事件评审：对项目进行过程中相关人员提交的事件报告（主要指对项目进度、成本、质量有影响的事件）进行评审，通过分析事件性质和影响范围，讨论事件处理方案，并判断是否影响项目计划，必要时采取纠正措施。

• 项目评审结束后，要产生一个评审报告，包括评审结果和所发现的问题。评审报告要及时发布。

非正式沟通

• 非正式沟通指在正式沟通渠道之外进行的信息传递和交流。它具有随意性和灵活性，并没有一个固定的模式或方法。例如聊天、非正式的面谈或聚会等。

• 软件项目团队中存在着大量非正式沟通。

• 非正式沟通补充了正式沟通的不足（正式沟通缺乏灵活性，且可能给项目人员带来压力），满足了项目人员的需要。

8.5.3 沟通管理计划

• 项目沟通计划确定项目相关人员的信息和沟通需求：谁需要什么信息，什么时候需要，怎样获得，选择的沟通方式，等等。

• 沟通计划是整个项目计划的一个附属部分，应在项目的前期阶段完成。在项目进行过程中，要根据沟通需求随时对其进行检查和修订，以保证它的持续有效性和适用性。

项目沟通计划的主要内容

• 项目干系人的沟通需求：他们需要什么信息，什么时候需要，这些信息对他们有什么价值。

• 沟通方式。描述传达信息所需的技术和方法。

• 人员联系方式。

• 工作汇报方式：明确表达项目组成员对项目经理或项目经理对上级和相关人员的工作汇报关系和汇报方式，明确汇报时间和汇报形式。

• 沟通时间安排。确定一些正式沟通的时间和频率。

• 沟通计划维护人：明确本计划在发生变化时，由谁进行修订，并对相关人员发送。

8.5.4 项目性能报告

• 项目性能报告一般应包括项目当前的范围、进度、费用和质量等方面的信息。许多项目还要求在性能报告中加入风险和采购信息。

• 及时发布项目性能报告可以使项目相关人员了解项目的当前状态、进展，以及下一步的工作计划。

• 项目评审报告就是一种很重要的性能报告，包括定期评审报告、事件评审报告和阶段（里程碑）评审报告。

• 项目周报模板

8.5.5 问题管理

• 项目团队成员在遇到问题时，不要总是一声不响、埋头苦干，而要及时与团队中相关人员交流。问题的及时解决可促进团队人员间的良好关系。

• 为了确保问题不被遗漏并及时得到解决，应创建一个问题跟踪列表（或使用变更控制工具来跟踪问题）。

问题跟踪列表

Open表示问题还没有解决；Resolved表示问题已解决，但还没有经过验证；已解决的问题经过相关人员验证后，状态称为Closed。

8.6 软件专业人员的非技术素养

8.6.1 团队意识

• 团队意识就是团队成员为了团队的整体利益和目标而相互合作、共同努力的意愿和作风。

• 团队意识具体表现在：

对团队的强烈归属感和一体感；
团队成员间的相互协作从而形成有机的整体；
对团队事务的尽心尽力和全方位投入；
使团队目标优先于个人目标；
愿意分享信息，理解别人的行为并产生适当的反馈；
当其他成员需要时给予帮助；
对别人的反馈作出积极地反应。

• 违反团队意识（团队精神）的常见做法：

不愿把自己的技术知识与别人分享，怕别人威胁自己的职位；
不喜欢与别人交流，不愿求助于别人，有问题后孤军奋战。

8.6.2 主人翁精神（Ownership）

• 主人翁精神是指对团体及其产品有一种“拥有”意识，因此主动关心团体的利益并愿意为之付出努力。

• 主人翁精神还表现在发挥主观能动性、敢于负责、勤于思考、勇于做出判断并表达自己的意见。

• 案例

• 当你加入一个产品开发团队以后，无论团队是只有一两个人，还是成百上千人，你都是产品的一个负责人（Owner），都要有这样一种精神和意识：“这是我的作品，我将制作它，我希望它能成功！”。

• 企业领导要有意识地通过各种方式培养员工的主人翁精神。如适当放权，配发股票等。

8.6.3 写和说的能力

• 写和说是人们向外界表达自己能力和才华的最重要途径。可是表达能力低下却是许多研发人员的通病。

• 要重视表达能力。“表达能力不重要，而技术才能才是最终要的”观念是错误的。

• 软件专业人员要不断与别人沟通。而且如果表达能力差，就无法胜任需求开发、系统设计、管理等高层次的工作。

• 怎样提高表达能力？“无他，唯手熟尔”。

• 珍惜每一次写文档、会议发言、作报告的机会，保证质量完成任务，通过多练逐步提高。

• 技术类的文档（包括开发文档、商务文档、产品说明书等）有四大要素：内容、逻辑、实证、措辞。

（1）内容充实，切忌空洞无物，大话、套话连篇。
（2）内容表述要逻辑清晰，容易理解。
（3）内容要有真凭实据，不能有虚构、夸张、造假成分。
（4）措辞追求“正确、准确、优美”。

• 当众发言（会议、演讲、报告、讲课等）要注意以下几点：

（1）事先做充分准备。多练几遍，熟悉内容，控制时间，避免在现场手忙脚乱。
（2）仪表整洁，精神抖擞。
（3）声音响亮。
（4）避免过分随意的口语和“口头禅”。

8.6.4 管理能力

• 管理能力是指带领团队完成目标的能力。

• 在企业里，不仅各级领导要会管理，而且还要让员工们懂得被管理（俗称洗脑）。

• 稳扎稳打的职业发展模式：先搞技术，拥有一技之长后再逐步转向管理。

• 做好管理工作，不仅要用脑，而且要用心，不仅要有智商（IQ），而且要有情商（EQ）。

• 怎样培养管理能力？  学习 + 实践

• 要学习本行业基础的管理知识

本门课程的知识；
能力成熟度模型（CMMI）；

• 从底层的管理者（如项目经理）做起，不断实践，积累经验，提高能力。

软件项目人员管理案例
圣人的话：
          在管理上，对于人力资源，要考虑：量材录用，帮助提高，绝不轻视弃置。

本章小结

理解软件项目人力资源管理的主要作用和主要内容。
理解项目组织结构的确定：项目组织类型及其特征、不同小组结构的特征。
理解项目团队的建设：人员配备、培训、绩效管理、激励。
理解项目沟通沟通方式、冲突管理，了解沟通计划。
了解软件专业人员要有哪些非技术素养。