IBM 軟體産品需求管理流程

級别： 初級

劉 昀, 進階咨詢顧問, IBM軟體部

2006 年 12 月 15 日

IBM 軟體産品的版本(V.R.M.F)從市場規劃和客戶需求開始，到研發以及後續的傳遞遵循 IBM 軟體部內建産品設計(IPD)流程。

1. 簡介

IBM 軟體産品的版本(V.R.M.F)從市場規劃和客戶需求開始，到研發以及後續的傳遞遵循IBM軟體部內建産品設計(IPD)流程。IBM 軟體産品需求管理流程是IPD的一個展現，也就是一個由市場/客戶驅動的，跨市場部門、研發産品管理部門及研發工程部門的端到端需求管理流程。同時，此次内容我們将描述IPD和産品需求管理流程，及流程中的角色（市場、研發産品管理部門及研發工程部門），以及他們之間是如何通過協作來管理需求的。

2. 背景——IPD

IPD指導如何對軟體産品釋出版本進行投資決策和如何協調部門間工作以實作這些決策所定義目标，IBM軟體産品需求管理基于IPD流程，要了解這個需求管理的流程，首先我們要了解IBM所有産品開發所遵循的IPD的流程，包括其決策點。

IPD流程分為六個步驟：

概念：即概念驗證階段，主要對需求包進行評審，以确定其是否有足夠的商業價值；

計劃：即資源投入計劃階段，主要對需求包進行評估，以确定是否有足夠的資源且在一定的時間範圍内将需求包開發出來；

開發：即對需求包進行開發成産品階段；

驗證：即對産品進行驗證階段；

傳遞：即将産品傳遞市場階段；

生命周期：即産品在市場上銷售，使用，維護和退出市場的階段。

其中包括了幾個重要的決策檢查點(DCP)：

概念決策檢查點：即經過概念階段各方面進行的一系列評審，在此檢查點确定（1）我們對需求包是否有足夠的了解；（2）需求包是否有足夠的商業價值。如果是，繼續進入計劃階段；

計劃決策檢查點：即經過計劃階段的評估，在此檢查點确定（1）我們是否有足夠的資源在既定的時間範圍内完成需求包的開發（2）研發部門是否能在(1)的估計上承諾進行開發。如果是，繼續進入開發階段；

可傳遞決策檢查點：即經過開發和驗證階段，在此檢查點确定（1）産品是否品質合格以傳遞給客戶（2）我們産品的相應支援和銷售是否已經準備好服務客戶,如果是，産品傳遞市場；

生命周期結束決策檢查點：即産品在市場使用一定時期後，在此檢查點确定産品是否退出市場。

一個産品從市場需求開始，經過概念驗證，時間、資源等計劃的支援，然後進行開發，驗證，直至釋出到市場供客戶使用，最後在某個特定的時候結束産品在市場上的銷售，在IBM都遵循着IPD流程。在其中過程中，這個産品的概念是否被接受，是否能得到資源上的投入的承諾，是否通過最終驗證可以在市場上釋出，以及什麼時候在市場上停售，這些關鍵的決策都通過相應的委員會在不同的決策點上進行決策。

3. IPD 與産品需求管理流程

以上描述了IBM IPD的基本概念，我們接下來看IBM軟體産品的需求管理是如何基于IPD的。首先，請看下圖一：産品需求管理流程。

<b>圖一：産品需求管理流程</b>

點選檢視大圖

這個産品需求管理流程是如何與以上IPD的階段相映射的呢？主要為以下幾點：

IPD的概念階段對應的是流程中的“New-&gt;Prioritize-&gt;Prioritized”；

IPD的計劃階段對應的是流程中的“High-Level Sizing-&gt;Sized”；

IPD的開發和驗證階段對應的是流程中的“Plan/Develop”；

其中“Commit-&gt;InPlan”對應的是IPD的“Contract”點；

而産品需求管理流程與決策點的映射，主要為以下幾點：

概念決策點-評估需求給IBM帶來市場價值，決定是否接納，如需求是不是有足夠的業務潛力使得IBM産品能夠成為市場的上司者；

計劃決策點-評估需求開發的投入，決定是否将其放入開發計劃，如是否有相應的資源使得我們能在既定的時間範圍内實作需求；

可傳遞決策點-評估需求實作的狀況，決定是否放入釋出計劃，如驗證需求的功能及品質等是否滿足要求。

4. 産品需求管理流程中的角色

産品需求管理流程中通過以下幾類角色的參與并互相協作，推動需求通過評審并納入到産品開發路線圖裡面。

<b>市場部門</b>

根據市場、競争對手的資訊，客戶的回報，技術發展方向以及IBM現在的産品組合，定義IBM在此市場領域需要提供的解決方案(O/SBP)。

<b>研發産品管理部門</b>

根據市場部門制訂的解決方案(O/SBP)，及客戶回報的的改善和缺陷，定義産品釋出版本所要提供的功能－即産品的需求。

<b>研發工程部門</b>

根據産品需求，評估開發需求所需要的資源、時間等，并對需求進行設計、開發和測試等，建立需求與設計開發之間的追蹤關系。

<b>技術支援</b>

代表IBM與客戶進行溝通，回報需求所處的狀态。

以上角色的互相協作關系請參考以下産品需求管理流程的三個階段描述。

5. 産品需求管理流程的三個階段

此流程是通過IBM内部系統RATLC實作，這個将在後面第7部分介紹。

IPD概念階段

研發産品管理部門根據市場部門制訂的解決方案(O/SBP)，定義産品所要提供的功能－即産品的需求。研發産品管理部門将這些需求資訊送出到RATLC，包括：

需求描述及提出理由

需求所涉及的産品子產品

如果此需求是因為客戶回報的改善和缺陷而産生，那麼研發産品管理部門将其與需求關聯。改善是指客戶在使用此産品的過程中提出的功能改善的要求，而缺陷是指：客戶在使用此産品的過程中發現的缺陷。

當備選需求進入RRM以後，評審委員會，包括市場部門、研發産品管理部門，研發工程部門的代表會複審備選需求以決定那些需求通過概念決策點 （目前的版本）。評估的條件包括其業務的重要性和對産品開發的影響（初步的需求規模評估）在評估的過程中，任何對此需求開發風險的認識，如需要的開發時間、性能要求等都被記錄下來，作為此需求的風險記錄，作為整個開發過程的參考。

對已經準許需求進行排序，同時需要增加以下内容：

将在哪個版本實作

負責人

業務的重要性

沒有通過概念決策點的需求：

被拒絕，即現在沒有任何實作的時間表；

被延遲，将在下次版本的概念階段被重新考慮；

需要添加負責人和注釋以備查。

IPD計劃階段

為了了解開發的投入，并能夠給每個需求制訂詳細的開發計劃，所有需求都要進行規模評估。評估的内容包括現在或将來開發此需求所需要的人力，時間和資源。通過研發工程部門和研發産品管理部門的多次和及時的溝通，需求的規模被确定。如果需求規模被修改，研發産品管理部門将再次和市場部門和技術支援部門溝通，以确認修改。修改的記錄會記錄在需求變更流程裡面。通過規模評估的需求，需求會關聯一條或多條的規模評估記錄：需求開發所需要的資源、人力及計劃。

同時，開發團隊根據IRUP指導對需求進行詳細的描述和設計，包括用例模組化，建立測試政策和項目計劃等。

沒有通過計劃決策點的需求：

被延遲，将在下次版本的Concept Phase重新考慮；

IPD 開發和驗證階段

在此階段，開發團隊決定是否針對需求制訂開發計劃, 并對需求進行開發和測試，如果制訂計劃，需要提供以下資訊：開發的狀态。在開發過程中，需求一直處于InPlan狀态，直到通過Availability DCP後，需求狀态轉變為Delivered。

如果由于開發計劃延後，或開發過程中出現技術問題而導緻開發團隊決定不将其放入開發計劃，需求會被Decommitted。如果有變更情況，負責人需要将變更記錄與需求關聯。

6. 産品需求管理流程的價值

1． 統一的版本需求管理流程：無論是外部的客戶需求，IBM的市場規劃需求都使用相同的流程，統一的評估，統一的規劃，確定需求的開發與業務目标發展一緻。

2． 需求端到端狀态的可視化：需求記錄包含豐富的資訊包括變更的記錄，使得市場部門、研發産品管理部門和研發團隊能夠及時了解需求所處的狀态，減少多方溝通的時間，并能夠及時的向客戶傳遞相應的資訊，提高客戶的滿意度。

3． 需求資訊的集中管理：每條需求都有相應的屬性，如客戶優先級别，所涉及的産品子產品等，需求開發時間等。有了這些資訊，市場部門和研發團隊可以定制各種報表對需求進行查詢、過濾和排序，多角度的了解需求的狀況。

4． 全球同步進行需求管理：雖然IBM市場部門及研發團隊都分布在全球不同地點，但是所有相關人員可以通過WEB的方式通路需求，進行需求的溝通。

7. RATLC——通過ClearQuest實作需求管理流程

在IBM内部是使用什麼系統來支撐需求管理流程的呢？答案是RATLC。 它既是 IBM 軟體部用于管理産品需求和産品缺陷的系統。 RATLC通過Rational ClearQuest工具定制實作。同時由于IBM的軟體研發團隊分布在全球各地，為了實作每個地區團隊能快捷地通路需求，RATLC通過ClearQuest MultiSite實作了“本地複本，全球同步”的模式。現在RATCL在全球一共有 11個複本，分别位于北美、印度、法國和中國，複本之間的一緻性通過ClearQuest MultiSite的自動同步功能實作。

IBM Rational ClearQuest 是一個強大而高度靈活的需求、缺陷和變更、測試計劃和用例管理平台，能在整個開發周期内捕獲、跟蹤并管理各種類型的記錄，幫助您以更高的效率傳遞出更高品質的軟體。無論您使用的平台是Windows、UNIX或是Web，可完全自主定制的界面和工作流程引擎都能适應任何開發流程。由于ClearQuest支援業内标準資料庫，是以它可任意擴充，以支援任何規模的項目。

RATLC的具體實作方式：

（1） 通過ClearQuest Designer定制RATLC中的需求管理流程。ClearQuest本身内嵌了需求管理、缺陷管理和測試管理流程。同時，鑒于IBM需求管理流程有特殊性的需求， ClearQuest提供了靈活的手段在上述的内嵌流程中進行客戶化定制。RATLC就是通過ClearQuest Designer的狀态過渡矩陣定制産品需求管理流程中的需求狀态和其過渡關系，如圖二：

<b>圖二：ClearQuest Designer的狀态過渡矩陣</b>

圖三是通過ClearQuest Designer定制好後的需求管理流程的狀态圖，圖中的橢圓代表的是需求的狀态，箭頭上的文字代表使用者經過何種操作後，需求的狀态發生了相應的變化。如需求處在“Submitted”狀态，使用者經過評審，确定了此需求的優先級别并更新了界面中此需求的優先級别屬性後，按下界面中“Prioritize”按鈕，需求的狀态變為“Prioritized”。

<b>圖三：通過ClearQuest定制的需求在流程中的狀态</b>

（2）通過ClearQuest Designer表單定制功能直覺地定制RATLC使用者界面。

我們可以通過ClearQuest Designer提供的可視化表單定制功能直覺地定制使用者界面。基本上是通過Designer提供的界面工具集如按鈕、文字框等拖拽地設計使用者界面。如圖四：

<b>圖四：ClearQuest Designer表單定制功能</b>

圖五是通過ClearQuest Designer表單定制功能定制出來的RATLC需求錄入界面。

<b>圖五：RATLC的需求錄入界面</b>

（3） 通過ClearQuest用戶端定制各式報表

在RATLC中系統管理者配置了不同産品的預設報表，當使用者和登入到系統的時候可以根據報表的類型（如按産品名稱分類的報表）來選擇需要檢視的需求記錄。

或者，使用者登入到系統後，可以自定義報表，如産品經理需要反複檢視某個客戶所送出的所有需求和缺陷記錄的狀态，他可以自定義這樣的報表，以友善在每次登入系統後都能很迅速地查詢到所需要的資訊。

報表的定制也是非常簡單，通過拖拽字段的方式就可以便捷地建立所需要的報表。

<b>圖六：通過ClearQuest定制各式報表</b>

（4）多用戶端界面選擇-Web/Windows UI/Eclipse

RATLC充分利用了ClearQuest多用戶端的特點，為不同類型的使用者提供了不同的使用界面。如市場部門及研發管理部門人員，由于他們的日常操作多為查詢需求的狀态和修改需求記錄等，RATLC為這部分人員提供了WEB通路的方式；而對于研發工程人員，由于他們需要對需求進行開發，這就涉及到與配置管理工具的內建實作變更記錄與代碼的結合，RATLC為他們提供了Windows用戶端或Eclipse用戶端，這樣研發工程人員的開發環境就能很友善地與ClearQuest結合起來。

（4）ClearQuest與ClearCase內建

在RATLC系統中，當某個需求經過準許後被分發到相應的開發人員，此開發人員可以通過ClearQuest與ClearCase的內建，在檢出代碼或文檔修改的時候選擇相應RATLC系統的記錄。這樣，變更的原因（需求）和變更的結果（代碼或文檔）就能緊密的內建在一起，友善随後進行雙向的查詢，如QA可以通過RATCL了解此需求變更涉及到哪些代碼改變，或某個檔案的新版本是由于什麼原因而産生的。

8. 總結

此次我們介紹了IBM軟體産品需求管理流程， 它是IBM IPD的一個執行個體，也就是一個由市場/客戶驅動的，跨市場部門、研發産品管理部門及研發工程部門的端到端需求管理流程。此流程在IBM内部的支撐系統RATLC是通過Rational ClearQuest這一優秀生命周期管理內建器來實作（如圖七）。Rational ClearQuest涵蓋了需求管理、變更管理、缺陷管理和測試管理。

<b>圖七：Rational ClearQuest – 生命周期管理內建器</b>

參考資料

developerWorks 中國網站 Rational 專區

如果您對Rational ClearQuest感興趣并想繼續研究，您可以參考以下網頁：ClearQuest 産品頁面

如果您想試用Rational ClearQuest，您可以到以下網址下載下傳試用版：ClearQuest 試用版

關于作者

劉昀，現任 IBM 中國有限公司軟體部 Rational 華南大區技術主管。現主要負責 Rational 産品在華為的推廣和技術支援工作。在此之前，劉昀曾任職于 Bea 中國有限公司，從事J2EE解決方案的咨詢工作。在加入 Bea 之前，劉昀在美國通用電器從事電子商務系統的設計開發。在軟體工程技術方面，劉昀有着多年的實踐經驗，對于 Rational 的軟體工程技術有着深刻的了解。