論產品經理對傳統IT公司的重要性

我如今一家傳統的軟件公司，專一在監控行業。就客戶需求與研發流程管理，如今的研發模式大概以下圖：

上圖中，我把客戶的需求定義爲要求，是有帶有咱們行業相關背景的，客戶是對系統不會有很深的認識的，並且客戶絕大部分對其提出的要求是不清晰的，借用偉大喬布斯的話「用戶不知道本身要什麼」。

在此模式下，咱們的需求人員在對接了來自客戶的要求後，分析整理後，輸出需求規格說明書，下發任務給開發表明（或系統SE）。在明確需求後，開發表明（或系統SE）輸出架構說明(可選)和概要設計，並與開發、測試一塊兒明確功能點(測試項)，作好任務分配與排期。後續流程大致也與圖上一置。

在這裏面，其實有兩次的需求分析(需求人員與技術人員對需求的解釋角度是有區別的)與相關文檔輸出。這是與流行的敏捷最大區別的地方，在敏捷的流程裏，需求是要直接與研發體系人員（開發，測試）一塊兒需求討論和澄清並完成任務分配的。

再明確一需求的行業定義：功能性需求，非功能性需求，（設計與實現）約束條件。在現體系下，需求人員更多完成的是「功能性需求」。並且需求人員的責任是承接客戶要求並輸出給開發表明，很容易出現將客戶的需求簡單轉化後就交由後方研發，最終變化爲開發表明轉化客戶要求到系統需求的狀況。實際的結果變成：開發表明完成需求的分析，明細，設計與研發任務的轉換。

此研發模式個人理解爲：對客戶咱們是2階段提交。

在「兩階段提交」模式下。咱們需求同窗在需求收集並分發研發後，對該需求的掌控就失去了。若是這裏遇到需求變動，天然就帶來了你們的拒絕（名人言：研發不是害怕需求變動，怕變動致使的混亂）。「兩階段提交」中還有一個隱藏的角色：項目經理，他須要監控項目的進度與風險。

有「兩階段提交」，那麼咱們應該還有一種模式：「三階段提交」。

提出此想法是基於一個簡單原則：「功能性需求」應該是能夠經過原型呈現的。那麼需求人員是須要輸出原型的，並且還得比較詳細、全面的呈現（畢竟要給客戶確認嘛）。那麼在分析需求並製做原型時，需求到技術的翻譯，研發表明要配合。提交研發時能夠直接與研發人員（包含測試）同步，也可交由開發表明分配功能，但需求的澄清應該由需求人員發起。

在此圖中，我調整需求人員角色爲產品經理。由於我以爲產品經理的職位是不單單關注系統（或需求）自己，還要關注其價值。應該在原型階段讓客戶看到的不單單是功能的呈現，更要感受到其可帶來的價值，從客戶獲得更多Confirm，減小Cancle。

以上都是我在學習需求分析後的感想。歡迎板磚來拍，期待能與優秀的你更多的溝通與交流。