引言

本文探讨一家软件公司维护项目的自动化项目。该项目涉及通过为此目的开发的工具将离散且分散的流程自动化，并整合到集中式监控机制中。

本文列出了范围和不同方面，如资源和进度规划以及网络图和工作分解结构。

项目范围

该项目的范围是开发一个自动化工具，用于集中管理工作流程。具体包括：

• 开发仪表板以及为此目的所需的数据库。

• 列出功能需求，包括监控 SLA 合规性和吞吐量定义流程。

• 维护不同管理层级具有不同控制级别的访问权限。

计时和其他管理功能不属于该工具的一部分，因此不在范围之内。该范围与可交付成果的输出直接相关，包括如上所述的前端和后端组件。

资源和进度计划

该项目涉及一个由六名资源组成的团队，其中包括一名团队负责人来监督开发团队。

资源将分配给两个团队：

1. 一个团队负责设计和开发，另一个团队负责需求和测试方面。

2. 第二个团队将拥有规划需求以及将其转化为第一个团队可用的规范的职能专业知识。

此外，该团队的专业知识将用于测试，并且他们了解测试的范围和功能方面。

该项目的计划周期为两个月。前几周将用于处理各利益相关者的需求，接下来的一个月将用于实际设计和编码。最后几周将用于测试和实施该工具。

网络图

关键路径如上所列。由于本项目涉及直通式开发，因此关键路径与 SDLC 阶段的关键路径相同。

打乱计划的影响

如果计划赶不上，需求阶段可以与设计阶段合并，并开展并行活动。这将超越 SDLC 的常规“瀑布”模型，转而采用敏捷方法。

关卡加载资源的效果

两个资源团队可以互换使用，但要求资源的技能组合相同。

风险评估

该项目的风险管理计划将列出以下潜在风险及其缓解计划：

• 资源风险： 就知识获取和人员流失风险而言，可分为两个部分。第一部分可通过培训和知识共享来缓解，第二部分可通过记录流程和知识管理来缓解。

• 范围蔓延： 任何范围的变更都必须得到所有利益相关者的批准，并分担成本。

• 方差： 任何因时间、成本或质量约束（“三重约束”）而导致的预算差异都应由所有利益相关者共同处理。这可以通过定期汇报进度和识别潜在问题来实现，这些潜在问题需要各利益相关者共同解决。

• 技术： 任何技术变革都会对项目造成直接风险，因此应确保选择适当的技术。

结语

本文试图以一家软件公司维护项目的自动化工具为例，描述项目管理流程的一些方面。虽然内容并不全面，但它确实解答了作业中列出的一些问题。