软件项目管理思维导图模板_ProcessOn思维导图、流程图

第九章
软件项目的时间管理

软件项目时间管理概述

项目时间管理的内容

1.项目活动定义

2.活动排序

3.活动工期估算

4.安排进度表

5.进度控制与进度管理

项目时间管理的特点

1.进度管理是一个动态过程。一个大的软件项目需要一年，甚至需要几年时间。在这样长的时间里，工程建设环境在不断变化;另方面，实施进度和此在进度控制中要根据进度目标和实际进度，不断调整进度计划，并采取排除影响进度的障碍，确保进度目标的实现。

2.项目进度计划和控制是复杂的系统工程。进度计划按工程单位可分整个项目总进度计划单位工程进度计划、分部分项工程进度计划等;按生产要素可分为投资资计划、设备供应计划因此进度计划十分复杂。而进度控制更加复杂，它要管理整个计划系统，而绝不仅限于控制项目实施过程中的实施计划。

3.时间管理有明显的阶段性。由于各阶段工作内容不一，因而相应有不调内容。每一阶段进度完成后都要对照计划作出评价，并根据评价结果作出下一阶段的工作进度安排

4.时间管理风险性大。由于进度管理是一个不可逆转的工作，因而风险较大。在管理中既要沿用前人的管理理论知识，又要借鉴同类工程进度管理的经验和成果，还要根据本工程特点对进度进行创造性的科学管理。

进度计划图

甘特图

特点

1.甘特图用水平线段表示阶段任务
2.线段的起点和终点分别对应于任务的开始时间和结束时间
3.线段的长度表示完成任务所需要的时间

缺点

不能反映某一项任务的进度变化对整体项目的影响

网络图
可以弥补甘特图的不足

单代号网络图

双代号网络图（虚活动）

绘制网络图

三个步骤

1.项目分解

2.工作关系分析

3.编制网络图

编制网络图需要注意的问题

1.一个网络图只有一个开始点和一一个结束点。

2.网络图是有方向的，不应该出现循环回路。

3.一对节点不能同时出现两项活动。

4.网络图中不能出现无箭头箭线和双箭头箭线。

5.网络图中不能出现无节点的箭线

6.在同一个网络图中的所有节点，不能出现相同的编号。

项目进度估算

基于规模的进度估算

定额估算法

经验导出模型

网络计划技术

活动时间估计

关键路径

分析关键路径的方法

子主题

编制项目进度计划

补充方法

帕肯森定律

项目延期分析

关键链法

软件项目的成本管理

第二章
项目的生命期和管理过程

项目生命周期中的重要概念

检查点

在规定时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异调整。
常见的间隔是每周一次，项目经理需要召开例会并上交周报

里程碑

是项目中完成阶段性工作的标志

软件项目生命周期的划分

项目定义与可行性研究

需求分析：用户需求+系统需求

系统设计

软件实施

系统测试

项目管理的内容

一个项目的工作范围和TQC（时间，质量，成本）确定了项目的目标

人员

问题

过程

项目管理的过程

项目启动

项目计划

项目执行和控制

项目收尾

第三章
项目经理与项目组织

项目主要的利益相关主体

项目的业主

项目的客户

项目经理

项目的实施组织

项目团队

项目的其他相关利益主体

项目经理的责任和权利

项目经理的职责

确保项目目标实现

开发计划

组织实施

项目控制

项目经理的权力

生产指挥权

项目团队的组建权

财权

技术决策权

项目经理的能力

获得项目资源的能力

消除障碍和解决问题的能力

领导能力和权衡能力

沟通能力

管理时间的能力

灵敏性

项目组织类型

职能型组织

优点

1..在人员使用上具有较大的灵活性，节约人力，减少了资源的浪费。需要选择一个合适的职能部门负责该项目，可以从相关部门调配所需人员。这些人员可以被临时地调配给项目，当项目工作完成之后又可以回到职能部门做原来的工作。

2。技术专家可以同时被不同的项目所使用。职能部门的技术专家般具有较深的专业基础，可以同时为几个项目服务。

3.同部门的专业人员在-起易于交流知识和经验,这可使项目获得部门内所有的知识和技术支持，对创造性地解决项目的技术问题非常有利。

4.当有成员离开项目组时，职能部门可作为保持项目技术连续性的基础。同时，将项目作为部门的一部分，还有利于在过程、管理和政策等方面保持连续性。

5.职能部门可以为本部门的专业人员提供条正常的晋升途径。成功的项目虽然可以给参与者带来荣誉，但他们的专业发展和进步还需要有一个相对固定的职能部门作为基础。

缺点

1.这种组织结构使得客户不是活动和关心的焦点。职能部门有它自己的日常工作，项目及客户的利益往往得不到优先考虑。

2.这种结构导致没有-个人承担项目的全部责任。由于责任不明确，往往项目经理只负责项目的部分责任，这就容易造成协调的困难和混乱的局面。混乱的局面会使对客户要求的响应变得迟缓和艰难，因为在项目和客户之间存在着多个管理层次。

3.项目常常得不到很好的支持。项目中与职能部门利益直接有关的问题可能得到较好的处理，而那些超出其利益范围的问题则很有可能遭到冷落。

4。调配给项目的人员其积极性往往不是很高，也不把项目看成是他的主要工作，有些人甚至将项目任务当成是额外的负担。

5.技术复杂的项目通常需要多个职能部门的共同合作，但他们往往更注重本领城，而忽略整个项目的目标，并且跨部门的交流沟通也比较困难。

项目型组织

优点

1.项目经理有充分的权力调动项目内外部资源，对项目全权负责。

2.权力的集中使决策的速度可以加快，整个项目的目标单一，项目组能够对客户的需要做出更快的响应。在进度、成本和质量等方面的控制也较为灵活

3.这种结构有利于使命令协调致，每个成员只有-个领导，排除了多重领导的可能。

4.项目组内部的沟通更加顺畅、快捷。项目成员能够集中精力在完成项目的任务上，团队精神得以充分发挥。

缺点

1.由于不能完全利用资源，在项目与项目之间的资源共享方面会存在一些问题，可能在成本方面效率低下。

2.项目经理与项目成员之间有着很强的依赖关系，而与项目外的其他部门之间的沟通有困难。各项目之间知识和技能的交流程度很低，成员专心为自己的项目工作，这种结构没有职能部门那种让人们进行职业技能和知识交流的场所。

3.在相对封闭的项目环境中，容易造成对公司的规章制度执行得不一致。

4.项目成员缺乏归属感，没有职业生涯的规划。

矩阵型组织

优点

1.项目是工作的重点，项目经理负责管理整个项目，矩阵型组织具有项目型组织的长处。

2.可以有效地利用资面，项目可以分享各个部门的技术、人才和设备。当多个项目同时进行时，公司可以平衡资源以保证各个项目都能完成各自的进度、费用和质量要求。

3.这种结构更加注重客户的需求和促进项目成员之间的学习和知识交流。

缺点

1.矩阵型组织通常是多个或多重领导，存在双层或多层汇报关系。职能部门经理和项目经理之间可能出现争权夺利的现象，需要平衡权力。

2.多个项目在进度、费用和质量方面能够取得平衡，这既是矩阵型组织的优点也是它的缺点。资源在项目经理之间流动容易引起项目经理之间的争斗，每个项目经理都更关心自己项目的成功，而不是整个公司的目标。

3.许多因素使矩阵项目团队非常难以管理。团队成员觉得这样的团队是临时的，所以对团经理来说，主要的管理问题仍在于项目团队冲突的程度。

项目组织的设计

目标一致性原则

有效的管理层次和管理幅度原则

责任与权利对等原则

合理分工与密切协作原则

集权与分权相结合原则

环境适应性原则

第四章
人力资源管理与团队建设

项目人力资源管理概述

根据项目的目标，项目活动进展情况和外部环境变化，采取科学的方法，对项目团队成员的思想，心理和行为进行有效的管理，充分发挥他们的主观能动性。

项目人力资源管理的内容

项目组织规划

项目人员的获得与配备

项目组织成员的开发

项目团队建设

项目组织计划

角色和职责分配

职责分配矩阵RAM

构造项目组织结构图

编制人员配置管理计划

项目团队的特点

目的性

团队性

临时性

渐进性和灵活性

项目团队的团队精神应包括

高度的相互信任

强烈的相互依赖

统一的共同目标

全面的互助合作

关系平等与积极参与

自我激励和自我约束

项目团队发展成长的过程

形成阶段

震荡阶段

正规阶段

表现阶段

对项目成员配备工作的原则

人员的配备必须要为项目目标服务;

以岗定员”，保证人员配备的效率，充分利用人力资源，不能以人定岗;

,项目处于不同阶段，所需要的人力资源的种类、数量、质量是不同的, 要根据项目的需要加入或退出，以节约人力资源成本。

项目团队成员需要具备的特点

项目团队成员具有专业技术技能。尽管职能部门可以负责提供解决项目技术问题的资源，但团队中仍需要有在技术上胜任的人，而且需要确定项目可能需要哪些额外的技术知识。

项目团队的高级成员必须在政治上敏感。几乎所有具备-定规模和在一定程度上较复杂的项目，在完成过程中都会发生需要高级管理层支持解决的问题。能否得到这样的支持取决于项目经理在不去威胁、侮辱或惹恼职能部门中的重要人物的情况下推进工作的能力。为确保合作和支持，项目和职能部门之间、一个项目和其他项目之间权力的平衡十分重要。

项目团队成员需要很强的以问题为导向的意识。项目成员应关心解决项目产生的任何问题，而不能仅仅去关心那些与他们的专业或技术特长相关的问题。

项目团队成员需要有解决问题和决策的技能。项目中有待解决的问题，团队成员需要分辨出问题的本质是什么，对各种观点与建议进行评价，决定采用可能最有效的方法及如何执行。在项目团队中，当人们解决问题时，通常会发挥这种技能，但如果一些团队成员在这之前就具备这种技能会更有帮助。

项目团队成员需要很强的自信心。隐藏错误和失误的项目成员早晚要引发灾难。成员必须有足够的自信，能够立刻认识到自己的错误并且能够指出别人的错误所导致的问题。项目经理应该注意，“杀死送坏消息的人”会立刻中断负面信息的来源，其结果是违背了“永远不要让上司感到意外”的黄金准则。

团队的激励

激励理论

双因素理论

ERG理论

成就需要理论

期望理论

公平理论

第五章项目沟通和冲突管理

沟通模式

沟通障碍

冲突管理

第六章项目可行性研究与启动

项目选择的4要素

项目的合法性

项目的含金量

项目的成熟度

项目的使用性

可行性研究目标

技术的先进性和适用性

经济上的盈利性和合理性

运行环境上的可能性和可行性

可行性研究作用

为决策提供依据

可行性研究是项目设计的依据

项目评估的依据

为商务谈判，签订有关合同协议提供依据

可行性研究的内容

技术可行性分析

经济可行性

运行环境可行性

可行性研究的步骤

初步可行性研究

详细可行习性研究

可行性研究报告

项目启动的标志

立项启动准备

召开项目启动会议

任命项目经理

第七章项目招投标与合同管理

招投标的基本程序

准备阶段

1.制定总体方案

2.项目综合分析

3.确定招标方案

4.编制招标文件

5.组件评标委员会

6.邀请有关人员

招标阶段

1.发布招标公告

2.资格审查

3.发售招标文件

4.招标文件的澄清修改

投标阶段

1.编制投标文件

2.投标文件的密封和标记

3.送达投标文件

4.撤回修改投标文件

开标阶段

开标仪式，招标人主持

评标阶段

审查投标文件的符合性

对投标文件的技术方案和商务方案进行审查

询标

综合评审

评标结论

定标阶段

审查评标委员会的评标结论

定标

中标通知

签订合同

编写项目标书
是整个招标最重要的一环

编制标书的原则

全面反映客户需求的原则

科学合理的原则

公平竞争

维护企业利益，政府利益的原则

招标书的主要内容

招标公告(邀请函);投标人须知;招标项目的技术要求及附件;投标书格式;投标保证文件;合同条件(合同的一般条款及特殊条款);设计规范与标准;投标企业资格文件;合同格式等。

三大部分：程序条款、技术条款、商务条款。

投标决策

竞争对手分析

风险分析

目标分析

声誉与经验分析

客户资金分析

项目所需资源分析

客户本身的自资信题

编写投标书

项目合同管理

签订合同时应注意的问题

1.规定项目实施的有效范围

2.合同的付款方式

3.合同变更索赔带来的风险

4.系统验收方式

5.维护期问题

软件项目合同条款分析

1.与软件产品有关的合法性条款

软件的合法性条款(主要表现在软件著作权)

软件产品的合法性（主要指该产品的生产，进口，销售已获得国家颁发的相应的登记证书）

2.与软件系统有关的技术条款

与软件系统匹配的硬件环境

软件匹配数据库等软件系统

软件的安全性，容错性，稳定性的保证

3.软件使用的标准体系方面的条款

4.软件实施方面的条款

5.技术培训条款

6.支持与服务

7.管理咨询条款

合同管理

合同收尾

产品选择与商务谈判

第八章软件项目需求和变更管理

软件需求：
用于达到某一目标所需的软件功能，包括业务功能，系统性能，使用便利性

用户需求

涉及方面

软件的功能

操作方式

界面风格

报表格式

用户机构的业务范围

工作流程

用户对软件应用的展望

特点

用户需求直接来源于用户

用户需求需要以文档的形式提供给用户审查

可以把用户需求理解为用户对软件的合理请求

用户需求主要是为用户方的管理层撰写的，但是用户方的技术代表，软件系统今后的操作者以及开发方的高层技术人员，也有必要认真阅读用户需求文档

系统需求

功能需求

非功能性需求

数据需求

需求规格说明书

要求

清晰，完整，一致，可测试

需求管理：
在软件开发过程中，对用户需求进行分析，确认，跟踪，实现，变更的管理过程

需求管理复杂性分析

需求的描述问题

需求的完备程度问题

需求开发的工期问题

需求的细致程度问题

需求的变化问题

需求管理的基本原则

需求必须是文档化的，正确的的，最新的，可管理的，可理解的

只要需求变化了，需求变更的影响就必须被评估

需求必须分优先级

需求一定要分类管理

子主题

需求管理过程

1.定义需求

2.需求确认

3建立需求状态

4.需求评审

5.需求承诺

6.需求跟踪

正向跟踪，逆向跟踪

7.需求变更控制

工作分解结构

目的

1.为项目计划的制定提供依据

2.为工作量的估算和分配工作提供依据

3.帮助项目经理关注项目目标

4.为绩效考核和项目控制定义基准

5.为项目风险分析提供依据

常见的两种分解方法

基干成果或功能的分解方法，以完成该项目应该交确定相关的工作、活动和要素;

基于流程的分解方法，以完成该项目所应经历的流程为导向确定相关的任务，工作、活动和要素。

分解形式

图表形式

分解层次与结构

WBS编码设计

清单形式

任务分解过程

分解步骤

①确认并分解项目的主要组成要素。通常，项目的主要要素是这个项目的工作细目。项目目标作为第级的最整体的要素。项目的组成要素应该用有形的、可证实的结果来描述，目的是为了便于检测。当明确了主要构成要素后，这些要素就应该用项目工作怎样开展、在实际中怎样完成的形式来定义。有形的、可证实的结果既包括服务，也包括产品。

②确定分解标准，按照项目实施管理的方法分解，可以参照WBS模板进行任务分解，而且分解标准要统一。分解要素是根据项目的实际管理而定义的，不同的要素有不同的分解层次。

③确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任。工作细目的分解如果在很久的将来才能完成的话，那么这种分解也就没有了确定性。

④确定项目交付成果。交付成果是有衡量标准的，以此检查交付结果。

⑤验证分解正确性，完成后，建立-套编号系统。

分解标准

分解结果的检验

任务分解的注意事项

①要清楚地认识到，确定项目的分解结构就是将项目的产品或服务、组织、过程三个不同的结构综合为项目分解结构的过程，也就是给项目的组织人员分派各自角色和任务的过程。应注意收集与项目相关的所有信息。

②对于项目最底层的工作要非常具体，而且要完整无缺地分配给项目内外的不同个人或者是组织，以便于明确各个工作的具体任务、项目目标和所承担的责任，也便于项目的管理人员对项目的执行情况进行监督和业绩考核。

③对于最底层的工作块，一般要有全面、详细和明确的文字说明，并汇集编制成项目工作分解结构词典，用以描述工作包、提供计划编制信息( 如进度计划、成本预算和人员安排)，以便于在需要时随时查阅。任务分解结果必须有利于责任分配。

④并非工作分解结构中所有的分支都必须分解到同一水平，各分支中的组织原则可能会不同。任何项目也并不是只有唯- -正确的工作分解结构。

⑤任务分解的规模和数量因项目而异，先分解大块任务，然后再细分小的任务，最底层是可控和可管理的，避免不必要的过细，最好不要超过7层。按照软件项目的平均规模来说，推荐任务分解时至少分解到一周的工作量(40 小时)。

责任分配及成本分解

需求变更原因分析

1.范围没有圈定就开始细化

2.没有良好的软件结构适应变化

3用户改变需求

需求变更处理流程

提出变更，变更评估，实施变更