連載：系統工程促進系統全面的思考和建模（讀書筆記04）

看書上的原文，再寫出來，能學得更深刻。這是最好的學習方式。

計劃用二個多月的時間把《如客戶般管理干係人》這本書一節一節的讀完。

因為這本書乾貨多，這樣讀效果好。

01

系統工程

1、系統工程的定義

系統工程是一種跨學科的、使成功的系統得以能夠實現的方法。

系統工程考慮了商業和技術的需要，以提供符合干係人需要的高質量的產品為目標來滿足客戶。

系統工程把所有學科和特殊群體都整合在一起作為團隊的能力。

它聚焦於在開發周期的早期定義好客戶的需要和必需的功能，記錄需求，然後在統觀全局的情況下進行合成設計和系統驗證，包括：運營、性能、測試、製造、成本和進度、培訓和支持，以及處置。

該能力形成了從概念到產品到運營的持續作用的結構化的開發流程。

根據《系統工程手冊》（Systems Engineering Handbook，哈金斯等，2006）

2、系統工程包含兩個最主要的學科

系統工程師運作的技術知識領域，以及系統工程管理。

圖3-4 系統工程管理的3個活動（國防採購大學，系統工程基礎，2001，圖1-1）

3、系統工程的作用

系統工程通過為複雜系統和系統的系統提供一系統的工具、技術和最佳實踐填補了項目管理和技術學科之間的空白。

系統工程促進了系統全面的思考和建模，開發一個系統時一個有意思的出發點就是作戰概念（Concept of Operations，CONOPS）

作戰概念用來與干係人溝通定性和定量的系統特徵和規格說明以滿足他們的需要。

作戰概念是一份文檔，它從使用系統的個人角度描述了計劃中的系統（1362-1998 IEEE）.你可以收集干係人的觀點來建立不同的作戰概念並把它們整合到一起。

作戰概念和需求說明書是開發一個系統必需的最基本的文檔，它們通常以自然語言的方式提供對系統目的和目標的說明。

4、特定的系統工程技術

通用系統語言（Universal System Language，USL）；

通用建模語言（Universal Modeling Language，UML）；

質量功能展開（Quality Function Deployment，QFD）；

集成定義（IDEFO）。

圖3-6展示了系統開發周期中比較有用的定義，評定和評估不同方面的UML圖表組。

需求是下述工作的基礎：

項目規劃；

風險管理；

驗收測試；

權衡；

變更控制。

圖3-8展示了需求的層次結構，我們還能看到每個層次都有與系統開發和驗收相關聯的目標。

解決方案域包括系統需求、系統架構和低層次需求，如子系統需求和組件需求。

表3-1 問題域與解決方案域

02

生命周期和範圍定義

1、有3種基本的項目生命周期類型

瀑布、敏捷、增量和迭代

瀑布：完全的預測型生命周期。

這種生命周期可以在執行前定義好範圍。

預測型生命周期應用在眾所周知的成熟的行業中，比如建築，你可以提前把產品和項目的所有事宜都計劃好。

如圖3-9所示

敏捷：完全的適應型生命周期，由決定下一步該做什麼的成功因素所驅動。

敏捷方法論注重的是交付價值。會在範圍沒有完全定義好的項目中發掘干係人的需要，為應對複雜產品和時間的壓力。

增量和迭代型生命周期，介於上述兩者之間。

這些生命周期旨在更快地交付項目。

如圖3-10所示

圖3-11展示了Scrum的基本理念，這是一個對於IT和非IT項目管理都很成功的敏捷方法。

2、階段管理是PRINCE2的一項核心原則

它構建了以逐個階段為基礎的項目生命周期，作為敏捷方法和迭代型生命周期，PRINCE2強調計劃只能詳細到可管理和可預測的程度（OGC,2009c）。

類似Scrum使用優先待辦項和衝刺計劃，PRINCE2有兩種計劃：短期的詳細團隊計劃和長期的項目計劃大綱。

這解決了規劃周期問題並為項目提供了更好的管理和控制。

03

變更管理

1、識別、評估和控制可能導致變更的問題的系統方法是項目管理成功的重要因素。

項目計劃會有變更，這是「唯一確定會發生的事情」，項目經理有責任監控正在偏離計劃的工作並採取行動。

牢記計劃—執行—檢查—行動的PDCA循環。沒有計劃則無從監督，沒有監督則無從控制，沒有採取行動則控制也是徒勞。項目經理的目標都是讓項目按計划進行。

2、變更管理必須回答下面幾個問題：

什麼在變更控制範圍內，什麼不在？

變更應該如何提出？

誰有許可權批准或拒絕變更？

批准或拒絕的決策如何記錄和宣布？

變更如何實施，這些實施如何記錄？

《PMBOK指南》（第5版）有一個專門的過程管理變更：實施整體變更控制

制訂項目管理計劃的同時我們必須有一份子計劃：變更管理計劃。

什麼在變更控制範圍內，什麼不在；

變更請求模板；

變更管理分析和批准流程；

變更日誌和狀態報告。

圖3-13中的簡化版變更管理流程是一個很棒的出發點，你必須為項目定義正式的變更管理流程，指明在每個階段必須做什麼。

3、每個變更請求必須標準化，項目經理必須根據項目管理計劃和其他項目文檔評估變更是否合理。

批准變更的許可權和責任必須非常明確。如果變更批准了，所有的計劃文檔必須在實施變更之前更新。

不停地變更是另一個陷阱，會引起範圍蔓延，最終導致項目失敗。所以作為項目經理你必須學會說不。

用戶和客戶會不斷地想要比他們實際需要的更多的特性，只是為了以防萬一……

一個黃金法則是永遠不要立即接受一個變更請求。

4、配置管理是關係到項目生命周期中產品最新配置的創建和維護的技術活動和管理活動，特別是在大型複雜的項目中，為保證產品符合干係人的需要，從而要付出很多努力在系統工程和保持需求可追溯性。

圖3-14展示了配置管理所涉及的重點。

問題和變更控制程序

來源：安全人何軍紅

作者：何軍紅（清暉PMP培訓1706西安班學員）

-未完待續-

想要獲取更多項目管理培訓及PMP相關信息，歡迎私信諮詢