系統工程對產品經理工作的啟發

0 評論 10947 瀏覽 48 收藏 10 分鐘

系統工程中的很多方法與經驗,都值得產品經理學習和借鑒,來更好地管理我們產品的整個生命周期。

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

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

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協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!