引言

本文探討一家軟體公司維護專案的自動化專案。該專案涉及透過為此目的開發的工具將離散且分散的流程自動化，並整合到集中式監控機制中。

本文列出了範圍和不同方面，如資源和進度規劃以及網絡圖和工作分解結構。

項目範圍

該專案的範圍是開發一個自動化工具，用於集中管理工作流程。具體包括：

• 開發儀表板以及為此目的所需的資料庫。

• 列出功能需求，包括監控 SLA 合規性和吞吐量定義流程。

• 維護不同管理層級具有不同控制層級的存取權限。

計時和其他管理功能不屬於該工具的一部分，因此不在範圍之內。此範圍與可交付成果的輸出直接相關，包括如上所述的前端和後端組件。

資源和進度計劃

該專案涉及一個由六名資源組成的團隊，其中包括一名團隊負責人來監督開發團隊。

資源將分配給兩個團隊：

1. 一個團隊負責設計和開發，另一個團隊負責需求和測試方面。

2. 第二個團隊將擁有規劃需求以及將其轉化為第一個團隊可用的規範的職能專業知識。

此外，該團隊的專業知識將用於測試，並且他們了解測試的範圍和功能方面。

此專案的計劃週期為兩個月。前幾週將用於處理各利害關係人的需求，接下來的一個月將用於實際設計和編碼。最後幾週將用於測試和實施該工具。

網路圖

關鍵路徑如上所列。由於本專案涉及直通式開發，因此關鍵路徑與 SDLC 階段的關鍵路徑相同。

打亂計劃的影響

如果計劃趕不上，需求階段可以與設計階段合併，並進行並行活動。這將超越 SDLC 的常規「瀑布」模型，轉而採用敏捷方法。

關卡加載資源的效果

兩個資源團隊可以互換使用，但要求資源的技能組合相同。

風險評估

此專案的風險管理計劃將列出以下潛在風險及其緩解計劃：

• 資源風險： 就知識獲取和人員流失風險而言，可分為兩個部分。第一部分可透過培訓和知識分享來緩解，第二部分可透過記錄流程和知識管理來緩解。

• 範圍蔓延： 任何範圍的變更都必須得到所有利害關係人的批准，並分擔成本。

• 方差： 任何因時間、成本或品質約束（「三重約束」）而導致的預算差異都應由所有利害關係人共同處理。這可以透過定期報告進度和識別潛在問題來實現，這些問題需要各利益相關者共同解決。

• 技術： 任何技術變革都會對專案造成直接風險，因此應確保選擇適當的技術。

結語

本文試圖以一家軟體公司維護專案的自動化工具為例，描述專案管理流程的一些面向。雖然內容並不全面，但它確實解答了作業中列出的一些問題。