【信息化】软考高级（信息系统项目管理师）论文自我总结精华和模板
23年考完PMP和MBA后感觉自己还需要在职称方面努努力，于是乎开始了高项的备考。幸不辱命，第一次考试就过了，我准备论文是用的自己实际的项目经验，且为甲方的视角并加入了部分敏捷，非常独特，在软考中比较少见，脱离了千篇一律的模式，论文比较难挂，本篇是个人对论文的总结，AAA 、AA、A指的是2023年下半年我觉得会出题的概率，可忽略。
论文总结如下：
开头及结尾：
2022
年
9
月，我作为
XX
规划设计院的信息化经理，负责了院内
OA
系统的建设工作。该项目总合同金额为
142
万元（其中主合同为
132
万元，补充合同为
9
万元，不含服务器费用），建设工期
6
个月，我在项目中担任甲方项目经理的角色，带领乙方实施工程师、测试工程师、开发工程师和产品经理完成系统建设任务。该项目包含行政办公、固定资产、审计管理、公文管理、图档管理、经营管理、项目管理、费控等主要模块，旨在建设一套专业的
OA
系统来支撑公司的流程管理体系。本文以该项目为例，讨论了信息系统项目建设过程中的
XX
管理，主要从
.......
过程进行阐述。
在
2022
年
6
月，我和公司领导为项目编写了项目建议书，其中对项目建设的必要条件做出了一定要求。然而，公司本身缺乏
OA
开发经验，且又希望在
OA
的建设过程中学习成熟的流程管理模式，识别最佳实践并标准化业务流程，所以公司决定通过外部采购来满足公司的需求。经过招标过程中的
“
招
”
、
“
投
”
、
“
评
”
、
“
授
”
等环节，
XX
软件公司以
132
万元的价格中标。另外，参考中标人提供的运行环境建议
·
，我们采购了三台腾讯云服务器，三年服务期共计
19
万元。系统采用
Java
的
Spring Cloud
架构，数据库用的是
MySQL
，另外使用
docker
独立部署文件存储和
ES
全文检索服务。考虑到本系统既有通用的模块，又有需要定制化开发且前期难以确定的模块，所以我们在此项目中采用了
以预测型为主、敏捷型为辅的混合型开发方法
。
尽管该项目的技术复杂度不高，但系统外要与
6
个系统对接接口，内要与
7
个部门沟通协调，业务极其繁琐。所以，在项目中需要格外注意细节，特别是要严格把控
XX
的管理，在本文中，我将特别围绕项目的
XX
管理进行论述。
..........
在团队的共同努力下，系统成功上线试运行，
1
个月后运行趋于稳定，于
2023
年
3
月如期验收，对
XX
管理的高度重视为项目的成功打下了坚实的基础。在这个项目中我学到了很多经验，也获得了不少的心得和感悟。
首先，甲方的信息化岗需要强烈的责任感，不然啥事都扔给乙方，自己当个甩手掌柜岂不美哉？然而，要做出让绝大部分员工都满意的系统，需要信息化管理者不断求索，严格认真的把控项目
的每一个过程。其次
，我深刻认识到一个企业若想要长久发展，必须要建立良好的制度和流程，企业信息化最大的问题不在于技术也不在于信息系统，而在于流程制度的混沌和人的无序。我认为信息化的关键在于利用信息化过程来规范制度流程并管理人的行为，从而提升综合管理能力，增强企业的竞争力。
在未来的工作中，我将继续推进企业的信息化转型，为我国信息化建设添砖加瓦。
AAA
整合：
一、制定项目章程
项目章程是公司高层下达一份正式批准项目的文件，是对项目经理正式授权的过程。
前期两个多月的项目招投标工作完成后，我和院领导根据
合同
和
招标文件
，一起制定了项目章程，最后由领导在项目启动会上正式签发，授权我担任本项目的项目经理。该章程包括
项目目的、项目背景、高层级的需求、整体预算、总体里程碑进度、主要可交付成果
等内容
，
为项目的顺利实施奠定了良好的基础
。
二、制定项目管理计划
所谓磨刀不误砍柴功，在正式工作之前，我们首先考虑了如何整合所有管理计划。我带领项目团队以
项目章程
及
其他规划过程的输出的子计划
为依据
，
联合项目主要干系人，多次召开会议，共同讨论
编制了
项目管理计划
。这份计
划除了各类子管理计划和基准之外，还规定了本项目采用以
预测型为主、敏捷为辅的混合型的开发方法
，对于固定资产、公文管理等通用模块我们使用预测型的开发方法，对于前期难以预料的定制化开发模块，如安全生产、费控等模块，我们采用敏捷开发。
三、指导与管理项目工作
有了完善的管理计划，更应按计划贯彻执行
。指导和管理项目工作是领导团队完成
可交付成果
过程。
在项目实施过程中我非常重视对项目跟踪，及时了解项目的进展情况，记录项目遇到的各种问题，使用腾讯在线文档编制成一份
问题日志
。另外，定期与用户、公司高层、相关设备供应商等干系人进行必要沟通，交流项目进展中存在的问题，收集他们对项目的意见和建议，添加到问题日志中。
敏捷
...
四、管理项目知识
管理项目知识是一个在整个项目中持续开展，不断积累、分享和学习显性知识和隐形知识的过程。对于调研和项目运行过程中遇到的比较繁琐的业务知识、使用
IPAD
看板、
teambition
等工具进行知识分享，让每个人都能看到业务的具体解决思路。并且把总结到的经验教训汇总成经验教训登记册。每隔一段时间，就会开一次知识分享会，在会议上分享各种知识，总结经验教训，持续更新到
经验教训登记册
。
五、监控项目工作
冰冻三尺非一日之寒，项目失败的背后是日积月累的错误，监控项目工作在整个项目过程中必不可少。具体而言，我要求项目成员每周提供项目周报，每周周五下午开展周例会对当前项目的情况进行评估和分析
，结合在项目过程中收集到的各种
工作绩效信息
，对项目当前的进度快慢、成本效益进行分析，最终形成了一份
工作绩效报告
。
另外在敏捷的开发阶段，我通过
10
分钟的
每日站会
，依次汇报昨天干了什么，以及今天的工作计划，了解项目的情况，使用
看板
和
迭代燃尽图
监控项目过程中，本次迭代任务还剩下多少个功能点待完成，控制项目进度在预定的轨道上运行。
六、实施整体变更控制
项目实施的过程中，各种类型的变更是不可避免的，实施整合变更控制就是在项目中，有变更的时候，要严格遵守变更控制程序，谨防随意变更。比如在项目阶段前期，办公室领导对公文管理赠送的在线文档编辑功能十分不满意，认为其产品老旧，兼容性差。我进行了初步评估，测试后确实产品一般，但胜在免费。经过和乙方的沟通后提议使用
WPS
在线文档编辑插件代理原来的插件。经过院领导（
CCB
）的同意后，通知干系人结果并签订补充合同
9
万元，采购了
WPS
在线文档编辑服务。办公室领导对新的插件十分满意。
然而在
敏捷开发部分
，我们拥抱变更，不再走变更流程，把用户的需求转化为一个个用户故事，加入产品待办事项列表里并进行优先级排序。在每两周的迭代计划会议上选取优先级最高的用户故事加入迭代事项列表中。
七、结束项目或阶段
结束项目或阶段是完结所有项目管理过程的所有活动，以正式结束项目的过程。
2023
年
2
月，项目成功上线试运行，在运行一个月后，我们组织业务专家、公司高层领导和人事、财务、综合办公室等部门负责人，以及乙方项目团队召开了项目验收会议，
确保所有工作完结
，经我方评审后一致通过验收，确认签字。同时，我整理和归档了项目中的各式文档，总结项目的经验教训，更新组织过程资产，加入到公司的知识库当中。
AAA
资源：
一、规划资源管理
所谓磨刀不误砍柴功，在正式工作之前，我们首先考虑了如何进行资源管理工作。
项目规划阶段，
我带领项目团队以
项目管理计划
及
项目章程
为依据，联合项目主要干系人，多次召开会议，讨论
编制了
资源管理计划
与
团队章程
，
为项目的顺利实施奠定了良好的基础
。
在资源管理计划中，我采用
RACI
矩阵
对项目团队成员的职责进行了明确，当然在记录团队成员的角色与职责时，我们特别注意每项工作有且仅有
1
名负责人，以免出现职责不明的情况。
二、估算活动资源：
估算活动资源是估算完成项目目标所需资源种类、数量、特性的过程。本项目中，我组织相关会议，邀请所有团队成员及重要干系人，以
资源管理计划、范围基准
为依据，在会议上通过类比过去同类型的项目的方式估计本项目所需资源，最终形成了资源需求、估算依据和
资源分解结构（
RBS
）
。例如：该项目需要
1
个测试、
2
个开发、
1
个实施、
1
个产品，还需要云服务器
3
台，办公用笔记本
4
台，单位食堂饭卡
4
张。
三、获取资源
有了完善的资源管理计划，更应按计划贯彻执行。
获取资源是获取项目所需的人员、设备和材料等资源的过程。本项目在早期的招标文件中乙方已经
预分派
了项目团队成员。对于需要的服务器设备，我方根据前期和乙方沟通的资源需求，采购了
3
台腾讯云服务器三年使用权，共计
19
万元。我通过一系列的沟通和协调，完成了其他资源的合理调配，最终形成了
项目团队派工单、物质资源分配单
、
资源日历
等文件。
四、建设团队
建设团队是提高团队技能，加强团队协作，改进团队氛围，进而提高团队绩效的过程。本项目主要
集中办公
的方式，让项目团队处在同一地点办公，强化团队的沟通协调。然而却因为新冠疫情的存在，部分团队成员时不时会被封锁在家，所以我们也会组成
虚拟团队
，使用
IPAD
看板、在线文档、腾讯会议等工具进行线上沟通交流，完成项目的建设。另外，我为乙方项目团队申请了工作餐，使他们可以在我方单位食堂免费就餐，也不定期组织团队一起吃个饭交流一下感情，团队很快就从
震荡阶段
进入到了
规范阶段
。
五、管理团队
管理团队实际上就是一个
解决问题
和
管理冲突
的过程。
在项目管理过程中，冲突总是不可避免的，但是只要有好的解决方法，坏事也能变好事。一般而言，解决冲突的方法有
合作
/
解决、缓和
/
包容、撤退
/
回避、妥协
/
调解、强迫
/
命令
，我更喜欢使用合作
/
解决的方法来管理冲突。例如有一次，产品经理和开发就固定资产标签打印问题争执不下，产品经理认为，对接打印机打印需要的标签格式是一个很简单的需求，最多用
3
天时间解决，然而开发人员却说打印机太过老旧，对接起来难度太大，会影响项目进度。我了解到这个他们冲突的根源之后，询问了一下同学群里有没有写过类似对接打印机接口的代码，最后群策群力了解到这个东西其实压根不需要对接打印机的后端接口，因为打印机的编码使用的是国际标准
128 Code
算法生成的条码，直接使用这个算法生成图片，不需要对接接口也行。最后开发和产品经理觉得这个方案既简单又省时，都欣然接受这个方案。
六、控制资源
冰冻三尺非一日之寒，项目失败的背后是日积月累的错误
，
控制资源过程在整个项目生命周期中必不可少。
具体而言，我要求项目成员每周提供项目周报，每周周五下午开展周例会对当前项目的情况进行评估和分析，
工作绩效数据
转化为
工作绩效信息
，并使项目一直行驶在规定的轨道上。然而总会有脱轨的时候
，比如在项目阶段前期，办公室领导对公文管理赠送的在线文档编辑功能十分不满意，认为其产品老旧，兼容性差。我进行了初步评估，测试后确实产品一般，但胜在免费。经过和乙方的沟通后提议使用
WPS
在线文档编辑插件代理原来的插件。经过院领导（
CCB
）的同意后，通知干系人结果并签订补充合同
9
万元，采购了
WPS
在线文档编辑服务。办公室领导对新的插件十分满意。
然而在
敏捷开发部分
，我们拥抱变更，不再走变更流程，把用户的需求转化为一个个用户故事，加入产品待办事项列表里并进行优先级排序。在每两周的迭代计划会议上选取优先级最高的用户故事加入迭代事项列表中。
AA
采购：
一、规划采购管理
所谓磨刀不误砍柴功，在正式工作之前，我们首先考虑了如何进行采购管理工作。
我带领项目团队以
项目管理计划
及
项目章程
为依据，联合项目主要干系人，多次召开会议，讨论
编制了
采购管
理计划
与
采购工作说明书
，
为项目的顺利实施奠定了良好的基础。该计划包含采购产品、采购方法、采购数量、采购时间等详细内容，除了
OA
系统还有云服务器的购买（由中标人给出系统运行环境后再决定）等采购工作。公司
本身缺乏
OA
开发经验，又希望在
OA
的建设过程中学习成熟的流程管理模式，识别最佳实践并标准化业务流程，经过院领导、信息部和采购部的多轮商议，最终决定通过外部采购一套专业的
OA
系统来满足公司的需求。
本项目项目初步估算的成本已达
100
万元以上，按照院内和集团的管理办法，必须采用公开招标的方式进行招标。我与采购部积极合作，联系了招标代理机构
-
深圳市
XX
采购网，招标代理机构参考我们的项目需求和建议制定了
招标文件
，该文件包含五大内容，分别是投标人须知、评标方法（综合评标法）、主要合同条框和格式、项目需求及投标文件的编制格式。根据代理机构的建议，综合评标法使用的评分标准为：技术标
60%
，价格标
30%
、商务标
10%
。
二、实施采购
有了完善的管理计划，更应该按计划执行。
实施采购主要的工作是获取选定的卖方并完成采购的过程。本项目中，我们以
采购管理计划、采购工作说明书和采购文件
为依据，经过
“
招
”
、
“
投
”
、
“
评
”
、
“
授
”
四个流程，最终选定了中标人签署合同。
“
招
”
，根据有关规定，公开招标的文件必须在两个以上网站或者媒体上发布，我们准备好了预先制定的招标文件，编制了招标公告，发表在了公司的官方门户网站以及招标代理机构的深圳市
XX
采购网上。
“
投
”
，经过
20
天有条不紊的招标工作，共有
5
个投标人投标，校验资质后有
1
个投标人不符合，其余
4
个符合资质。
“
评
”
，该环节主要是招标代理机构代理开标，也由他们组织评标委员会，评标委员会有
5
位，其中含技术专家
3
位。当天开标人开标，唱标人唱标、投标人述标、评标委员会评标，最终得出了按得分依次排序的三位中标候选人。
“
授
”
，最后虽然有三位中标候选人，但是只能和得分顺位第一的中标人讨论项目需求，均对项目情况无异议，然后对合同条款进行多次修改，均确认无误后签订了合同。
三、控制采购
冰冻三尺非一日之寒，项目失败的背后是日积月累的错误。控制采购在整个项目生命周期中必不可少。具体而言，我要求项目组成员每周提交项目周报，并且在每周五下午开展周例会对项目的情况进行评估和分析，把
工作绩效数据
转化为
工作绩效信息
，并使项目一直行驶在正确的轨道上。然而总会有脱轨的时候
，比如在项目阶段前期，办公室领导对公文管理赠送的在线文档编辑功能十分不满意，认为其产品老旧，兼容性差。我进行了初步评估，测试后确实产品一般，但胜在免费。经过和乙方的沟通后提议使用
WPS
在线文档编辑插件代理原来的插件。经过院领导（
CCB
）的同意后，通知干系人结果并签订补充合同
9
万元，采购了
WPS
在线文档编辑服务。办公室领导对新的插件十分满意。
而在
敏捷开发部分
，我们拥抱变更，不再走变更流程，把用户的需求转化为一个个用户故事，加入产品待办事项列表里并进行优先级排序。在每两周的迭代计划会议上选取优先级最高的用户故事加入迭代事项列表中。
审计、检查
AA
成本：
一、规划成本管理
所谓磨刀不误砍柴功，在正式工作之前，我们首先考虑了
如何进行成本管理工作。
项目规划阶段，
我带领项目团队以
项目管理计划
和
项目章程
为依据，结合公司知识库中的成本管理计划模板，进行了成本管理计划的编制，为日后项目顺利实施提供良好基础。这份计划确立了绩效测量规则、估算单位标准、成本报告的具体格式等内容。例如针对人力资源，我们规定使用人
/
天作为计量标准，
1
人
/
天为
2500
元。成本管理计划编写完成后，发起评审会议通过后把成本管理计划发送给各项目干系人。
二、估算成本
有了完善的成本管理计划，更应按计划贯彻执行
。资源需求、范围基准、项目管理计划
=
》
应急储备
、类比估算、标杆对照
、
自下而上估算
=>
成本估算、估算依据
在
敏捷开发
阶段，我们定义项目中最小功能为
1
点功能点，以此作为基点，算出其他的每项工作的功能点。
三、制定预算
我们对项目的成本进行了汇总，首先汇总各个活动的成本估算及其应急储备，得到相关工作包的成本；
然后汇总各个工作包的成本估算及其应急储备，得到控制帐户的成本；接着再汇总各个控制帐户的成本，得到成本基准；考虑到项目的各种风险和不确定等因素，我们为项目预留一部分管
理储备，最终形成了项目资金需求。
范围基准、成本估算、项目管理计划
=
》
成本汇总
、储备分析
=
》
成本基准、项目资金需求
（成本基准
+
管理储备
）
四、控制成本
冰冻三尺非一日之寒，项目失败的背后是日积月累的错误
，
控制成本在整个项目生命周期中必不可少。具体而言，我要求项目成员每周提供项目周报，每周周五下午开展周例会对当前项目的进度情况评估和分析，形成
工作绩效信息
，并使项目一直行驶在规定的轨道上。
EV PV
分析原因、纠正措施、
变更举例
AA
沟通：
这两者之间既有区别又有联系，沟通管理主要是对信息的管理，而干系人管理主要是对人的管理。
通过沟通管理解决了沟通内容的问题，而通过干系人管理则解决了沟通对象问题。如果沟通管理不当，可能导致信息传递延误、向错误的干系人传递信息、与干系人沟通不足或误解
等问题。而干系人管理不到位，比如没有有效识别出关键干系人，或因干系人分类错误而缺乏及时有效的沟通时，可能因无法获得来自干系人的支持而导致项目失败。
在
本文中，我特别围绕干系人管理和沟通管理进行论述。
一、规划沟通管理
所谓磨刀不误砍柴功，在正式工作之前，我们首先考虑了如何进行沟通管理工作。
项目规划阶段，我带领项目团队以
项目管理计划
和
干系人登记册
为依据，结合公司知识库中的沟通管理计划模板，进行了沟通管理计划的编制。首先我和项目团队召开会议对干系人登记册中的所有干系人进行沟通需求分析，使用
权利
/
利益矩阵
将所有干系人分成四类。第一类是公司内的信息分管院领导与信息部总监，对项目影响重大，而且非常关注项目结果，权高利高，应该
重点管理、即时报告
。第二类是综合办公室、财务部、审计部、人资部等职能部门的负责人，他们有较大权利，但是一般不会是系统的主要使用者，权高利低，应该
令其满意
。第三类是项目组成员以及重度使用系统的一线工作人员，权低利高，我们要
随时告知
项目情况。第四类是公司内的所有普通员工，权低利低，我们要持续
监督
，尽量提高其使用体验，降低他们对
OA
流程合规化的抵触心理。最终汇总上述信息并经过评审，编制出项目沟通管理计划，确定了在项目的各阶段，分别用何种工具、以何种方式对特定的干系人进行最有效的沟通工作。
二、管理沟通
有了完善的沟通管理计划，更应按计划贯彻执行
。
IPAD
面板、在线文档、企微拉群、输出
项目沟通记录
敏捷：迭代计划会、迭代评审会、迭代回顾会
三、监督沟通
冰冻三尺非一日之寒，项目失败的背后是日积月累的错误，持续监督沟通
在整个项目生命周期中必不可少
。
具体而言，我要求项目成员每周提供项目周报，每周周五下午开展周例会对当前项目的进度进行评估和分析，
形成工作绩效信息
，并使项目一直行驶在规定的轨道上
。其次，在项目中也遇到了很多沟通的问题，比如固定资产标签打印问题，产品经理觉得需要对接标签打印机的底层，打印出预计的标签。而开发认为这个标签打印机过于老旧，对接困难，开发难度太大影响项目进度。我作为甲方的项目经理对需求又进行了深入了解，在网上多番调查的情况下，找到了此标签打印机的固定算法
128code
，使不需要对接标签打印机底层也能直接用算法生成标签，使问题得到了解决，节约了时间又降低了技术难度，双方都对结果满意，沟通达成一致。
变更请求
举例
~
。
A
范围：
一、规划范围管理
所谓磨刀不误砍柴功，在正式工作之前，我们首先考虑了
如何进行成本管理工作。
我带领项目团队以
项目管理计划
和
项目章程
为依据，结合公司知识库中的范围管理计划模板，进行了范围管理计划的编制，为日后项目顺利实施提供良好基础。计划包括如何制定项目范围说明书，如何根据项目范围说明书创建
WBS
，如何维护和批准
WBS
，以及如何确认和正式验收己完成的可交付成果等内容。
二、收集需求
范围管理计划、招标文件、投标文件、合同
=
》标杆对照、工作跟随、思维导
图、原型法、
访谈
=
》
需求文件
、
需求跟踪矩阵
。
三、定义范围
项目章程、范围管理计划、需求文件
=
》产品分析
=
》
项目范围说明书
（业务方签字确认、评审，内容包括：
产品范围描述、可交付成果、验收标准、除外责任、制约因素、假设条件
）
四、创建
WBS
项目范围说明书、需求文件
=
》
分解
、用户故事、产品待办事项列表（
敏捷
）
=
》
WBS
（范围基准）。
五、确认范围
测试后的软件
=
》看板、检查、
迭代评审会
（
敏捷
）
=
》略
六、控制范围
对比基线、分析原因、偏差分析、纠正措施、
变更举例
A
干系人：
一、识别干系人
项目启动阶段，根据发布的项目章程和采购文件，通过会议和干系人分析的工具，将大多数的干系人识别出来，并使用
权利
/
利益方格
，将干系人进行分类，形成了一份
干系人登记册
。
这份登记册把干系人分成四类，第一类是公司内的信息分管院领导与信息部总监，对项目影响重大，而且非常关注项目结果。第二类是综合办公室、财务部、审计部、人资部等职能部门的负责人，他们有较大权利，但是一般不会是系统的主要使用者，对项目关注度一般。第三类是项目组成员以及重度使用系统的一线工作人员，尽管该类干系人权利低，但他们是软件的直接使用者。第四类是公司内的所有普通员工。
二、规划干系人参与
所谓磨刀不误砍柴功，在正式工作之前，我们首先考虑了如何进行干系人管理工作。
我带领项目团队以
干系人登记册
为依据，对项目干系人的影响和利益进行分析，并进行优先级排序，再评估出干系人的所需参与程度和当前参与程度，最终形成了一份干系人管理计划，为日后项目顺利实施提供良好基础。
第一类的干系人权高利高，应该
重点管理、即时报告
。第二类的干系人权高利低，应该
令其满意
。第三类干系人权低利高，我们要
随时告知
项目情况，做好协调沟通。第四类是公司内的所有普通员工，我们要持续
监督
，尽量提高其使用体验，降低他们对
OA
流程合规化的抵触心理。
三、管理干系人参与
有了完善的管理计划，更应按计划贯彻执行。
管理干系人参与是在项目的整个生命周期中与干系人进行沟通和协作，以满足其需要与期望，解决实际出现的问题，并促进干系人合理参与项目活动的过程，有助于提升项目经理来自干系人的支持，并把干系人的抵制降到最低，从而显著提高项目成功的机会。
我们根据
干系人管理计划
与
干系人登记册
，积极与领导层、职能部门一线工作人员、项目团队成员进行交互式沟通。我们把主要干系人都拉入企业微信群组，并使用
IPAD
看板，持续公布团队做了什么，还需要做什么，让干系人实时知晓项目的情况，另外，每周召开项目评审会或敏捷的迭代评审会进行沟通协调，保证信息无障碍传递。种种措施，赢得了来自多方干系人的支持，大大减轻了项目实施的压力。
四、监督干系人参与
冰冻三尺非一日之寒，项目失败的背后是日积月累的错误
，
持续监督干系人参与在整个项目生命周期中必不可少。
我深知，在整个项目生命周期中，干系人的参与对项目的成果至关重要。我使用
干系人参与评估矩阵
来记录干系人的当前参与程度，并按
不知晓、抵制、中立、支持、领导
等进行分类，积极沟通协调，使干系人达到计划的参与程度。在项目实施的过程中，曾出现开发越过项目经理擅自接收财务方提出的变更需求，结果导致借款审批流程和需求原型不符，我及时了解情况，召集财务、产品、开发及时面谈，形成共识，所有的需求变更都要走变更流程。在每个迭代结束，产品发布上线前，我还组织职能部门干系人参加我们的迭代评审会，以保证项目的成功上线。
B
进度：
规划进度管理：范围管理计划、项目章程
=
》会议评审
=
》
进度管理计划
定义活动：范围基准、项目管理计划、项目章程
=
》
滚动式规划
、分解（需求分析、蓝图设计、系统建设、系统测试、系统上线分解为具体的活动）
=
》
活动清单
、活动属性、
里程碑清单
排列活动顺序：活动清单、里程碑清单、范围基准
=
》前导图法绘制 （举个例，先做啥后做啥）
=
》
项目进度网络图
估算活动持续时间：活动清单、进度管理计划、范围基准
=
》类比估算、三点估算、自下而上估算（加上
10%
的应急储备时间）
=
》
持续时间估算、估算依据
制定进度计划：范围基准、持续时间估算、估算依据、项目进度网络图
=
》
敏捷发布规划
、关键路径法、资源平衡
=
》
项目进度计划
、
进度基准
控制进度：纠偏、变更、偏差分析、
举例说明进度问题
（赶工、快速跟进）。
B
质量：
规划质量管理：
）如何进行评审流程、测试流程
，
质量测量指标、质量管理计划
（用户满意度不小于
...
任何操作
2ms
内
...
系统故障率
...
）
管理质量：
举例说明测试的问题
(
没有自测等
)
，改进质量、形成质量意识
/
文化、根本原因分析、审计
=
》 指令报告
控制质量：核对单、检查、根本原因分析、测试（单元、集成、系统、验收测试）
=
》 合适的可交付成果
C
风险：
一、规划风险管理
所谓磨刀不误砍柴功，在正式工作之前，我们首先考虑了如何进行风险管理工作。
我带领项目团队以
项目管理计划
及
项目章程
为依据，联合项目主要干系人，
编制了风险管理计划，
为项目的顺利实施奠定了良好的基础
。该计划
包括
风险管理策略、角色和职责、管理应急储备、概率和影响矩阵、干系人风险偏好、风险类别、风险概率
和影响定义
等内容。
在计划中，我们还确定了每两周召开一次风险评估会议，评估项目活动的最新风险状态。
二、识别风险
风险识别是判断哪些风险会对项目产生影响并记录过程。
根据项目的实际情况
，
我们将风险划分为
技术风险、管理风险和外部风险
三大类，并使用
风险分解结构（
RBS）
列出已知的风险，然后进一步细化这些已识别的风险，形成包含
风险描述、潜在责任人和潜在应对措施
的
风险登记册
。在
敏捷开发
阶段，风险识别是一个持续的过程，我们通过
10分钟的
每日站会
分享和记录可能的风险，并在每个迭代周期的迭代回顾会议上进行评审。
三、实施定性风险分析
定性风险分析是分析和评估风险的概率和影响，并对风险进行优先级排序的过程。我们组织公司财务、行政、人资等部门通过会议对已识别的风险进行
概率和影响评估，
我们采用头脑风暴的方法来确定每个风险发生的可能性以及对项目的影响，最后再进行进行风险优先级的排序
。
在这一过程中，我们为风险登记册添加了
责任人、概率、影响、分值、风险类别和策略
等新的信息。
四、实施定量风险分析
定量风险分析是对风险进行量化计算和分析
并将结果汇总更新到风险登记册中
的过程
。但是，因为此次项目本身架构清晰，而项目组成员又对类似项目经验丰富，前期识别到的风险都完全处在可控范围内，所以我们根据项目管理的裁剪原则，
研究评审后决定
跳过实施定量风险分析过程。
五、规划风险应对
规划风险应对就是针对正面风险和负面风险，制定不同应对措施，以提高项目成功的机会或降低项目失败的威胁。我们以
风险管理计划
和
最新的风险登记册
为依据，分析各个风险应如何应对。在公司启动
IPO
的一年里，经常会被要求提交各种旧系统里的流程审批数据。
然而项目前期既无法确认哪些数据未来是会记事务所要提交的，也无法确定哪些数据无法导入新系统（新旧系统数据结构不同，早期无法确定是否能导入）。
为了解决这个问题，我们讨论后决定，未来能导入新系统的数据尽量导入，万一遇到无法导入的旧数据
，先用文件存档，再以图片的形式保存审批流程截图。通过以上措施，我们能够在系统切换到新系统后尽量保留原有的数据，以确保公司业务的顺利进行。
六、实施风险应对
有了完善的管理计划，更应按计划贯彻执行。
实施风险应对是根据制定的风险应对计划，执行
.....
举例（新冠）
七、监督风险
冰冻三尺非一日之寒，项目失败的背后是日积月累的错误，持续监督风险在整个项目生命周期中必不可少。
具体而言，我以
1-2周为节点，在风险评审会或敏捷的迭代回顾会议中与团队成员一起
评估风险是否变化，是否有新的风险出现，并且对已出现的风险评估应对措施执行的有效性。另外，还有公司审计部的定期实行
风险审计
，形成审计底稿供负责我院
IPO
的事务所审阅。
附录(敏捷流程及PMP知识点)：
