敏捷开发产品管理系列之九：划分产品子系统

本文是敏捷开发产品管理系列的第九篇。（专栏目录）

子系统定义

其实子系统不是一个严格的定义，这里指任何产品（当然还有一个问题，什么是一个产品……）的第一级功能目录，也就是最大尺度上的产品分解方法。

由于业界一直缺少标准分解方法乃至一些简单规则，可能一百个产品有一百个分法。

在开发火星人的过程中，“我们”偶然发现了一种易于掌握的方法。“我们”加上引号，是因为实际上是我在培训课的学员看了我们实际的分解结果后发现的；被他一语道破之后，我本人也恍然大悟。这种分解方法可能大家平时也在用，但却没有太注意。

下面的内容来自火星人内部的帮助系统，数据是由沙盘项目自动生成的，略有修改。因为有CSS差异，所以有少许格式问题。

此外，这是一个完整的“四步走”的第一步，在发完四篇博客后，会给大家一个链接直接到网上看。

高级教程：四步生成故事树  [展开] [要求补充帮助]

此教程适合在火星人系统中直接创建新产品的高级用户，建议第一次使用帮助时跳过。

此演示数据是依靠当前企业中的第一个产品自动生成的。想查看火星人官方示例，请在火星人首页使用公开的演示帐号登录后访问此帮助页面。

合理与不合理的划分的判断准则

由于用户故事树是对用户需求的条目化，因此火星人主张按功能而非架构对其进行分割。下面是一个电子商城 合理 与 不合理 分割的例子：

	商铺管理子系统	商品管理子系统	广告管理子系统	收发货子系统	...
前端界面层
业务逻辑层
数据层

合理与不合理的区别在于：

1. 1. 客户/用户可以理解合理分割的子系统存在的价值。
2. 2. 合理的子系统能直观表明产品的主要功能；不合理的产品则全都是“三层结构”或“四层结构”，看看不出是什么应用。
3. 3. 当大规模增加功能时，合理的子系统也会越来越多，能直观地看到功能增长；不合理的则不会发生变化，只是内部越来越庞大。
4. 4. 每当增加“小功能”时，合理的子系统只影响一个子系统；而1小时就能完成的小改进也可能影响不合理的所有子系统。
5. ……

尽管可能还有其他的价值观准则，导致不同的划分方法，但火星人认为显然以上四条有其不可忽视的意义，除非有等同价值的收益，不应该随意打破。

推荐的划分方法：以主要用户及其业务关系的差异进行划分

在不同子系统中，主要用户不完全相同（一般都有重叠），但主要用户间的业务关系相差很大。比如上例中：

子系统	商铺管理子系统	商品管理子系统	广告管理子系统	收发货子系统	……
主要用户	店主，电商营运者	店主，（到店）买家	店主，电商营运者，（所有）买家	店主，快递，（已购物）买家	……
业务关系	商铺的建立与运营	商品的分类，上架，展示等	商铺和商品的对外宣传	商品的交货	……

下面是火星人自己的子系统：   注意！ 火星人是一个敏捷开发管理系统，下面列出的“产品管理”“敏捷开发”“测试”等是火星人自身的功能，而非指开发中的活动

子系统	产品管理	敏捷开发	测试	企业	……
主要用户	产品经理	产品经理（计划，验收），项目经理和开发人员（故事板）	测试经理/测试人员，产品经理	系统管理员	……
业务关系	产品管理，需求管理，Wiki等	计划，开发（看板），评审	测试用例，自动化测试，测试结果	维护产品，团队，用户等	……

更大尺度上需求的划分：产品

若子系统的数量超过5～8个的合理范围，应考虑在更大尺度上划分为产品。

比如“火星人”处理单个企业内部不同工种的研发管理，而“火星云”处理在站点上，火星人运营者与多家企业、海量用户之间的互动。

火星云的子系统如下：

子系统	站点	用户反馈	……
主要用户	站点管理员，企业管理员	火星人支持人员，用户（企业的管理员，产品经理，项目经理，开发人员，测试人员……）	……
业务关系	建立，统计企业	用户反馈（缺陷，建议，问题……）及其处理	……

产品和子系统没有非常严格的界限，常常是逐渐发展变化的。最初火星云是火星人产品中的一个子系统，但当整个火星人逐渐变得庞大时，火星云也独立成为一个产品。

在使用这种方法后，很想找到一种新的名词来代替“子系统”，因为很多人提到子系统的时候很可能想的都是前台界面和后台逻辑的划分，而最大尺度上的非功能分割。

看了上面的描述，“用户群”本来是一个不错的替代名词，但若没有看过本篇文章，一定会觉得一头雾水。欢迎大家出出主意。

我的CSDN博客之星链接，欢迎常来看博客的朋友投上一票，谢谢：

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