通過流程模型來描述產(chǎn)品管理業(yè)務(wù)流程的動態(tài)特性析

1、 通過流程模型來描述產(chǎn)品管理業(yè)務(wù)流程的動態(tài)特性析信息模型描述了產(chǎn)品管理業(yè)務(wù)流程的靜態(tài)特性。但產(chǎn)品管理業(yè)務(wù)流程需要不同的角色參與和協(xié)作，分別完成不同的任務(wù)。因此，本節(jié)通過流程模型來描述 Gizmo 的產(chǎn)品管理業(yè)務(wù)流程的動態(tài)特性。營銷管理流程產(chǎn)品管理流程產(chǎn)品管理流程主要圍繞產(chǎn)品商業(yè)計劃書來進行的，并通過狀態(tài)值來標識該產(chǎn)品在產(chǎn)品生命周期中所處的狀態(tài)。這些狀態(tài)值可為：Concept（ 概念階段）、Under Development（ 概念階段）、Introduced（ 處于上市推廣階段）、Growth（ 處于市場份額增長階段）、Maturity（ 產(chǎn)品在市場上有穩(wěn)定的銷售額和穩(wěn)定的增長）、Declin

2、e（ 銷售額下降，并逐步丟掉市場份額）和 Terminate（ 產(chǎn)品的維護成本超過了銷售額，產(chǎn)品將退出市場）。通常，產(chǎn)品商業(yè)計劃的維護由產(chǎn)品經(jīng)理來進行，并組織公司相關(guān)人員對關(guān)鍵點進行評審，因此對產(chǎn)品商業(yè)計劃的處理流程不通過工作流技術(shù)進行固化和自動化。發(fā)布管理流程發(fā)布管理流程涉及到發(fā)布創(chuàng)建、規(guī)劃發(fā)布內(nèi)容、實現(xiàn)發(fā)布和驗證發(fā)布等環(huán)節(jié)，涉及產(chǎn)品經(jīng)理、開發(fā)經(jīng)理等角色。此外，其他職能部門領(lǐng)導(dǎo)或公司高層組成集成產(chǎn)品管理團隊（IPMT，Integrated Product Management Team）對發(fā)布進行評審。下圖是描述 Gizmo 手機發(fā)布流程的流程圖，幫助流程參與人員理解流程活動以及先后順序。圖

3、 3. 發(fā)布管理流程活動圖下表簡要描述發(fā)布管理流程中的每個任務(wù)。表 2. 發(fā)布管理流程任務(wù)描述 任務(wù)名稱 責(zé)任人 任務(wù)描述 增加（Add Release） 產(chǎn)品經(jīng)理 根據(jù)市場規(guī)劃或用戶需求規(guī)劃的產(chǎn)品發(fā)布 計劃（Plan Release） 產(chǎn)品經(jīng)理 確定實施該發(fā)布的時間信息（如計劃發(fā)布日期）和成本信息（如預(yù)算成本）確定該 Release 要解決的用戶需求，并指定開發(fā)經(jīng)理 評審（Review Release） IPMT 對該發(fā)布從市場、進度、成本、風(fēng)險等因素進行評審，如評審?fù)ㄟ^則 Start Release，否則 Postpone 該 Release 完成（Finish Release） 項目經(jīng)理

4、 完成該 Release 的相關(guān)開發(fā)、測試工作 驗證（Verify Release） 產(chǎn)品經(jīng)理 對該 Release 的質(zhì)量以及相關(guān)信息進行驗證，如通過則批準該 Release 下圖是描述發(fā)布的狀態(tài)遷移圖，幫助明確流程所處理信息的狀態(tài)遷移順序以及實現(xiàn)狀態(tài)遷移的動作，從而提高對發(fā)布流程的管理水平。圖 4. 發(fā)布管理流程狀態(tài)轉(zhuǎn)換圖其中每個狀態(tài)的定義如下表。表 3. 發(fā)布管理流程狀態(tài)描述 屬性值 說明 計劃中（In Planning） 該發(fā)布正處于計劃中 已計劃（Planned） 該發(fā)布的計劃已經(jīng)完成（工作內(nèi)容、時間、成本等信息已確定） 已啟動（Started） 該發(fā)布的開發(fā)工作已經(jīng)啟動 已完成（F

5、inished） 該發(fā)布的開發(fā)工作已經(jīng)完成 已驗證（Verified） 該發(fā)布所實現(xiàn)的用戶需求都完成，可以交付該發(fā)布 已推遲（Postponed） 該發(fā)布被推遲 用戶需求管理流程用戶需求（User Request，下圖中簡稱 UR）管理流程覆蓋了從提交到最終解決的一個端到端的流程。Gizmo 的用戶需求管理流程的流程圖參見如下圖。圖 5. 用戶需求管理流程活動圖下表簡要描述用戶需求管理流程中的每個任務(wù)。表 4. 用戶需求管理流程任務(wù)描述 任務(wù)名稱 責(zé)任人 任務(wù)描述 起草（Draft UR） 產(chǎn)品相關(guān)者 起草用戶需求描述 提交（Submit UR） 產(chǎn)品相關(guān)者 當(dāng)確認用戶需求起草完備后，提交用戶

6、需求 分析（Analyze UR） 產(chǎn)品經(jīng)理 分析用戶需求的合理性，如該用戶需求合理，則接受（Accept），如和別的用戶需求重復(fù)，則執(zhí)行 Duplicate 動作，如不合理，則執(zhí)行 Reject 動作，如提交的信息不全，則執(zhí)行 Clarify 動作 計劃（Plan UR） 產(chǎn)品經(jīng)理 分析用戶需求的優(yōu)先順序，并根據(jù)發(fā)布的時間安排以及可用資源狀況，確定用戶需求將在哪個發(fā)布中解決 評審（Review UR） 系統(tǒng)工程師 對用戶需求進行技術(shù)評審，如通過則執(zhí)行啟動（Start）動作，否則執(zhí)行推遲（Postpone）動作 完成（Finish UR） 系統(tǒng)工程師 當(dāng)用戶需求已經(jīng)實現(xiàn)并通過測試，則執(zhí)行 Fi

7、nish 動作 驗證（Verify UR） 產(chǎn)品經(jīng)理 對用戶需求的解決情況進行最后確認。 Gizmo 用戶需求的狀態(tài)遷移圖形如下。圖 6. 用戶需求管理流程狀態(tài)轉(zhuǎn)換圖其中每個狀態(tài)的定義如下。表 5. 用戶需求管理流程狀態(tài)描述 屬性值 說明 Drafted 新起草的用戶需求 Submitted 新提交的用戶需求 Accepted 用戶需求已經(jīng)接受 Planed 用戶需求已經(jīng)被計劃到特定的發(fā)布上去實現(xiàn) Started 已經(jīng)啟動該用戶需求需要的開發(fā)工作 Finished 已經(jīng)完成該用戶需求需要的開發(fā)工作 Verified 該用戶需求已經(jīng)完成最后確認 Duplicated 該用戶需求和別的用戶需求重復(fù) Rejected 該用戶需求被拒絕 To be Clarified 該用戶需求需要提交者補充信息 Postponed 該用戶需求已經(jīng)被推遲 產(chǎn)品需求管理流程產(chǎn)品需求管理流程實現(xiàn)了對產(chǎn)品需求的創(chuàng)建、分配、實現(xiàn)和驗證全過程的管理。下圖是 Gizmo 的產(chǎn)品需求管理流程的流程圖和狀態(tài)遷移圖。對每個活動和狀態(tài)的描述類似用戶需求管理流程，故在本節(jié)省略。圖 7. 產(chǎn)品需求管理流程活動圖產(chǎn)品管理流程整合發(fā)布管理流程、用戶需求管理流程和產(chǎn)品需求管理流程之間不是孤立的，它們之間有一定的關(guān)系。下圖簡要描述了如何整合這三個流程，完成一個發(fā)