系統工程為了實現系統的最終目标，對系統的各個子系統、部件以及信息流等進行研究分析與設計，使用各種組織和管理技術，使整體系統實現最優的運行，負責整個系統的生命周期。

對于産品經理來說，要負責一個産品（從解決問題，滿足需求的角度上來講，産品也是一個系統），系統工程中的很多方法與經驗，都值得産品經理學習和借鑒，來更好地管理我們産品的整個生命周期。

1 系統工程簡介

那麼什麼是系統工程呢？我們可以先來看看ISO900對系統工程的定義：a system is an object consisting of interrelated or interacting elements（components）.

系統工程的過程則由以下七個任務來構成，被稱作SIMILAR tasks。

1. 描述問題（State the problem）：系統工程的第一個任務，就是把我們要去解決的問題陳述清除，即定位問題。我們需要明确我們的目标用戶，了解用戶的需要，探索需求，從而定義系統功能。

2. 調研替代方案（Investigate alternatives）：對于用戶提出的需求，我們可以調研市場上已經出現的能夠相對滿足（或部分滿足）的産品（或者我們稱之為競品），調研這些産品的表現情況（用戶評價與反饋）、成本以及風險，為我們帶來經驗和啟發。

3. 系統建模（Model the system）：在前兩個任務中，需求與調研都已相對成熟，我們就可以着手來設計我們的産品（系統）了，大緻來講，接下來就是使用建模工具，或者自己開發适用于該業務的建模工具來建立模型，來清晰表達需求、發現項目中的難點以及及早暴露問題。

4. 系統整合（Integrate）：這裡的系統整合是指将各個子系統都整合起來，使系統能夠完整地運行起來。

5. 系統啟動（Launch the system）：這一步是我們要整體運行系統了，讓系統開始完整地進行輸入（輸出我們預期的結果）。

6. 性能評估（Assess performance）：接着，我們就可以用想用的技術性指标來評估系統運行的相關情況，從而來量化當前系統的性能，評估系統是否滿足了需求。

7. 再次評估（Re-evaluation）：系統評估是一個不斷重複的工作伴随産品的不斷叠代。

2 系統生命周期

在産品設計的早期，産品經理就應該開始考慮産品的系統生命周期的問題。我們如何進行需求探索與分析？當前的競品或替代方案對于這些需求的滿足情況如何？研發資源是否到位？系統維護與叠代是否已有方案？等等。 既然産品經理對産品的整個生命周期負責，那“系統生命周期”的如下七個環節則是需要産品經理去良好把握的關鍵，以确保産品工作的順利展開。

系統生命周期的七個環節：

本文我們将重點聊聊系統工程中需求探索分析與系統測試評估方面的内容帶給我們的啟發。

3 需求探索與分析

需求探索與分析非常有趣，當然也非常重要，需求的明确是産品成功的基石。

我們的用戶往往并不能夠準确地表達他們的需求，他們往往傾向于用盡量少的語言來籠統地提出需求，比如說，“我要這個産品用起來很爽”，“簡單不要搞複雜了”等等，這時候産品經理一定要做好一件事情：将用戶提出的需求明确化，具體來說就是将需求明确為可量化、可測試、可實現。

舉個例子，共享電單車用戶說我要這個車騎起來很快，那麼具體的快是怎樣的一個速度區間值呢？給出一個預期的速度範圍就是一個“可量化”的需求；那我們最終産出的這款共享電單車是否滿足了用戶的速度需求，是可以通過速度測試來知道的，這就是“可測量”；用戶還說，我希望這輛電單車永遠都有電，也不用換電池，對于這個需求，如果最終确認是朝着永動機的方向研發，那我們就應該立即停止項目，因為“不可實現”。

對于需求是否是“可實現”的評估，這裡的一個行業經驗是我們會去參考現有的相關解決方法來得到一個相對穩妥的結論。

對于需求，還有一個繞不開的話題當然就是優先級問題。通常産品經理對于優先級的定位都是通過我們熟悉的四象限定位法來确定的，重要并急需、重要不急需、不重要但急需、不重要也不急需。但如何來把握這四個象限，更多的是一種經驗。系統工程中對于需求也有分類，這或許會對産品經理在優先級定位的問題上有所啟發。

系統工程中我們将需求分為了兩類：強制性需求（Mandatory requirements）和偏好型需求（Preference requirements）。簡單來說，強制性需求指的就是為滿足用戶基本需求，保證産品主流程暢通必須具備的功能需求，偏好型需求則更多是指提高用戶體驗的相關需求。

舉個例子，共享單車項目，注冊登錄、交納押金、掃碼開鎖，還車結算等與用戶主用車流程相關的需求都屬于強制性需求（也就是重要并急需），沒有這些功能的支持，主用車流程将受阻，用戶無法正常完整使用産品，而分享朋友圈、邀請好友等功能，沒有影響到主用車流程的需求，則可以歸類到偏好型需求了。

當然，如果我們有一個team的任務就是研發基于共享單車系統的陌生人交友産品，用車流程則是支援部門考慮的事情，我們則專注在分享朋友圈和邀請好友上面，所以确定我們要研發實現的系統的邊界（System boundary）與核心目标也是尤為重要的。

需求的探索與分析其實是一個過程，對于這個過程的理解與實踐，我想用下面的這張圖來說明一下：

4 系統功能性測試評估

到了驗收的環節，産品經理需要做的，是确認開發交付的系統是否滿足終端用戶的需求。從系統工程的角度上來看，驗收需要關注兩個問題：功能是否完備、系統是否可靠。

1.功能是否完備：這裡我的一個經驗是用一個checkList來一個功能一個功能地驗證。

舉例：如果我們驗收的是一個計算器APP（如下圖所示），從需求文檔中我們可以整理出下面的一個checkList來進行功能完備方面的檢驗。

2.系統的可靠性由這幾部分組成：有效性、穩定性、安全性和保密性。

• 有效性：系統在被請求時提供相應服務的能力。
• 穩定性：系統穩定輸出服務的能力。
• 安全性：系統正常工作不會導緻災難性故障的的能力。
• 保密性：系統保護自己免受攻擊的能力。

産品經理對于系統的可靠性的把控方面，則通過上述的幾個組成部分和測試部門的同學密切合作，通過系統測試報告來了解以及和開發同學不斷完善，使産品最終可交付使用。

本文由 @羅冠林 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!