敏捷開發產品管理系列之九：劃分產品子系統

本文是敏捷開發產品管理系列的第九篇。（專欄目錄）

子系統定義

其實子系統不是一個嚴格的定義，這裏指任何產品（當然還有一個問題，什麼是一個產品……）的第一級功能目錄，也就是最大尺度上的產品分解方法。

由於業界一直缺少標準分解方法乃至一些簡單規則，可能一百個產品有一百個分法。

在開發火星人的過程中，“我們”偶然發現了一種易於掌握的方法。“我們”加上引號，是因爲實際上是我在培訓課的學員看了我們實際的分解結果後發現的；被他一語道破之後，我本人也恍然大悟。這種分解方法可能大家平時也在用，但卻沒有太注意。

下面的內容來自火星人內部的幫助系統，數據是由沙盤項目自動生成的，略有修改。因爲有CSS差異，所以有少許格式問題。

此外，這是一個完整的“四步走”的第一步，在發完四篇博客後，會給大家一個鏈接直接到網上看。

高級教程：四步生成故事樹 [展開][要求補充幫助]

此教程適合在火星人系統中直接創建新產品的高級用戶，建議第一次使用幫助時跳過。

此演示數據是依靠當前企業中的第一個產品自動生成的。想查看火星人官方示例，請在火星人首頁使用公開的演示帳號登錄後訪問此幫助頁面。

合理與不合理的劃分的判斷準則

由於用戶故事樹是對用戶需求的條目化，因此火星人主張按功能而非架構對其進行分割。下面是一個電子商城合理與不合理分割的例子：

	商鋪管理子系統	商品管理子系統	廣告管理子系統	收發貨子系統	...
前端界面層
業務邏輯層
數據層

合理與不合理的區別在於：

1. 1. 客戶/用戶可以理解合理分割的子系統存在的價值。
2. 2. 合理的子系統能直觀表明產品的主要功能；不合理的產品則全都是“三層結構”或“四層結構”，看看不出是什麼應用。
3. 3. 當大規模增加功能時，合理的子系統也會越來越多，能直觀地看到功能增長；不合理的則不會發生變化，只是內部越來越龐大。
4. 4. 每當增加“小功能”時，合理的子系統隻影響一個子系統；而1小時就能完成的小改進也可能影響不合理的所有子系統。
5. ……

儘管可能還有其他的價值觀準則，導致不同的劃分方法，但火星人認爲顯然以上四條有其不可忽視的意義，除非有等同價值的收益，不應該隨意打破。

推薦的劃分方法：以主要用戶及其業務關係的差異進行劃分

在不同子系統中，主要用戶不完全相同（一般都有重疊），但主要用戶間的業務關係相差很大。比如上例中：

子系統	商鋪管理子系統	商品管理子系統	廣告管理子系統	收發貨子系統	……
主要用戶	店主，電商營運者	店主，（到店）買家	店主，電商營運者，（所有）買家	店主，快遞，（已購物）買家	……
業務關係	商鋪的建立與運營	商品的分類，上架，展示等	商鋪和商品的對外宣傳	商品的交貨	……

下面是火星人自己的子系統：   注意！ 火星人是一個敏捷開發管理系統，下面列出的“產品管理”“敏捷開發”“測試”等是火星人自身的功能，而非指開發中的活動

子系統	產品管理	敏捷開發	測試	企業	……
主要用戶	產品經理	產品經理（計劃，驗收），項目經理和開發人員（故事板）	測試經理/測試人員，產品經理	系統管理員	……
業務關係	產品管理，需求管理，Wiki等	計劃，開發（看板），評審	測試用例，自動化測試，測試結果	維護產品，團隊，用戶等	……

更大尺度上需求的劃分：產品

若子系統的數量超過5～8個的合理範圍，應考慮在更大尺度上劃分爲產品。

比如“火星人”處理單個企業內部不同工種的研發管理，而“火星雲”處理在站點上，火星人運營者與多家企業、海量用戶之間的互動。

火星雲的子系統如下：

子系統	站點	用戶反饋	……
主要用戶	站點管理員，企業管理員	火星人支持人員，用戶（企業的管理員，產品經理，項目經理，開發人員，測試人員……）	……
業務關係	建立，統計企業	用戶反饋（缺陷，建議，問題……）及其處理	……

產品和子系統沒有非常嚴格的界限，常常是逐漸發展變化的。最初火星雲是火星人產品中的一個子系統，但當整個火星人逐漸變得龐大時，火星雲也獨立成爲一個產品。

在使用這種方法後，很想找到一種新的名詞來代替“子系統”，因爲很多人提到子系統的時候很可能想的都是前臺界面和後臺邏輯的劃分，而最大尺度上的非功能分割。

看了上面的描述，“用戶羣”本來是一個不錯的替代名詞，但若沒有看過本篇文章，一定會覺得一頭霧水。歡迎大家出出主意。

我的CSDN博客之星鏈接，歡迎常來看博客的朋友投上一票，謝謝：

http://vote.blog.csdn.net/blogstaritem/blogstar2013/cheny_com