无线通讯产品App的设计讨论 -- 连载三

xdwangxf

【上期简单回顾】

在连载二中，首先确定了一个需要设计和交付的产品，基于该产品，展开前期准备工作。在前期准备中，对问题领域和涉众做了一定的分析。

【本期重点】

本节中，对前期准备阶段的整理业务目标进行分析和描述，然后针对前期准备工作的三个阶段，给出一个小结。

【本期内容】

1.      规划业务目标

针对上一期连载的业务目标描述，首先提出一个问题？

大家有没有觉得业务目标的描述好像和大家需要交付的App协议栈的关系有点远？有芯片和操作系统，有终端能力集，还有待机要求等等。

这些业务目标，其实都是以终端作为边界，提炼出来的业务目标。而App协议栈，只是终端的一个组成子系统，属于终端边界之内。这里先不对边界展开讲，大家可以自己理解一下。

因此，现在开始，让大家缩小边界范围，将关注点放在App协议栈上面，来规划业务目标。因为LTE终端的App协议栈所包含的业务点比较多，大家不可能将所有的业务点注意罗列。只能以满足分析和讲解的需要，罗列部分主要的业务点。

提示：这里讲的业务目标和需求是不一样的。需求是业务目标的规范化描述，可能一个业务目标会分解为一个到多个需求。

规划业务目标主要包括三个重点：

（1）    挖掘业务目标

（2）    整理业务目标

（3）    制定需求调研计划

挖掘业务目标：业务目标来自于和产品相关的涉众。注意针对的产品或者系统边界不同，涉众也有所不同。挖掘业务除了需要业务技术之外，更需要与人沟通。与人沟通没有约定的范式遵循，因人而异。

一部分技术人员往往不擅长于这一点，须知管理的一个重要的环节就是与人沟通。

表1.1 App协议栈业务目标描述

序号	业务目标描述
1	使用芯片平台MTK6732 （产品经理 or 老板提出的需求）
2	运行在Android4.2系统之上 （产品经理提出的需求）
3	支撑终端能力等级Cat4，下行最大速率130Mbps，上行最大速率30Mbps。
4	支撑TD-LTE的接收机和发射机功能
5	基线协议版本是Rel.9 （960）
6	支撑TDD/FDD协议栈共版本（产品提出者坚持的需求）
7	支撑丰富的可调可测功能（项目经理提出的需求）
8	支撑实时日志功能（系统工程师提出的需求）
9	支撑平滑演进到LTE-A协议栈（产品经理提出的需求）
10	协助支撑基带系统的基本的可调可测功能（系统工程师提出的需求）
11	…  …

好，表1.1列出了现在面对的主要的业务目标。当然，还可以继续列下去。但是对于大家的讲解来说，这些已经是足够了。

整理业务目标：整理业务目标，起始就是对挖掘到的业务目标的梳理，包括增加、删除、修改业务目标，对业务目标进行分类和划分优先级。

通过和相关涉众反复的沟通、确认、澄清和辩驳（有时候也需要辩驳甚至争论），业务目标整理后的结果如下：

表1.2 业务目标整理结果

序号	业务目标    编号	优先级	类别	描述
1	TN-000-0001	1	架构类+功能类	芯片平台MTK6732
2	TN-000-0002	1	架构类+功能类	支撑Android4.2系统
3	TN-000-0003	1	架构类+功能类	终端能力等级Cat4，下行最大速率130Mbps，上行最大速率30Mbps
4	TN-000-0004	1	架构类+功能类	支撑TD-LTE的接收机和发射机功能
5	TN-000-0005	1	功能类	基线协议版本是Rel.9 （960）
6	TN-000-0006	1	架构类+功能类	支撑TDD/FDD协议栈共版本
7	TN-000-0007	2	架构类+功能类	支撑丰富的可调可测功能
8	TN-000-0008	2	架构类+功能类	支撑实时日志功能
9	TN-000-0009	3	架构类+功能类	支撑平滑演进到LTE-A协议栈
10	TN-000-0010	2	架构类+功能类	协助支撑基带系统的基本的可调可测功能
11	TN-000-0011

说明：

（1）    优先级从1~3，逐步降低；

（2）    经过讨论，认为“支撑平滑演进到LTE-A协议栈”的风险和未知点太多，因此降低优先级；

（3）    类别的划分，有多种。有些分为功能、性能、安全等来分类；有些根据业务目标对产品的影响，比如对产品架构有影响，对产品功能点有影响等来划分。不同类别的划分，没有绝对或者本质的区别。适和团队的，就是好的分类方式。表1.2采用后一种分类方式。

制定需求调研计划：从业务目标到需求，是一个艰苦的过程，也是非常重要的一个过程，非常关键。是从产品分析阶段进入研发阶段的入口。这个过程不是纯技术就可以搞定的。综合素质可以在这个阶段得到充分的体现。因此，这个过程不是需要，而是很需要制定计划。如何制定计划，也是因人、因项目、因企业而异，这里就不再赘述了。

2.   前期准备阶段的小结

本期连载，规划业务目标比较好写，要写的内容也不是很多，主要在方式方法的引导上面。

其实更为关键的是小结这个部分，相对更为难写，需要花费更多的时间去思考。因为截止到连载三，大家已经知道

了产品、确定了业务目标，甚至也制订了需求调研计划。产品的准备阶段就做完了，下面要进入到挖掘需求阶段了。

因此这个小结是一个承上启下的连接点。同时有一些基本的概念和理念，在这里要描述讲解清楚。否则，会对大家

对后面内容的理解产生干扰。好，言归正传。

小结中，大家将对下面几点进行一定的展开描述。

（1）    迭代过程

（2）    领域模型和业务模型

（3）    用户了解自己的需求吗？

（4）    如何降低和规避产品的风险？

（1）    迭代过程

大家都知道，XP（极限编程）和统一App开发过程将App开发过程分解为一个一个的迭代，一环扣一环，直到交付。

这里需要强调的一点就是：App研发是一个常变的过程。App的研发过程，需要拥抱变化而不是拒绝变化。因此才

需要将App研发过程分成一个一个时间长度合适的迭代周期，在每个迭代周期内，需求相对稳定。

迭代过程适用于产品的整个研发过程，因此也适用于大家前面讲的准备阶段。即就是，准备阶段、需求分析阶段，

所有的App研发阶段，都可以分为多个迭代过程来进行实施，从而降低风险。

（2）    领域模型和业务模型

大家在连载二中，讲到过了解问题的领域，对领域做了一点简单的先容。这里对领域进一步的补充说明。

领域描述了产品的上下文。一般大家了解一个事物，一般都是先对事物有一个感性认识，颜色、大小、外观。事物

所处的环境以及事物和身边环境中其他事物的静态和动态的交互联系，使得大家对于事物的认识更近一步。这里，

事物的环境以及环境中相关的其他事物，其实就是事物所处的上下文，也就是和事物相关的领域。App产品也是一

样。领域是一个静态的概念，一般领域表现为如下两类：

l  业务对象：和产品关联的业务活动中，产品可以使用或者处理的对象，比如定时器资源、日志文件、基站下行业务数据等；

l  事件对象：和产品相关的已经发生或者将要发生的事件。比如定时器超时、用户触发了拨号的行为等。虽然看起来这些像是动作，但是这里描述的是动作的一个静态阶段。比如定时器在tick过程中，超时阶段。

顺带提一句，UML中的类图，就是静态图，可以很好的表示领域模型。怎么样，有没有一点点豁然开朗的感觉。

业务模型：前面一直在讲业务目标，可能大家听到耳朵都起茧子了。这里讲到的和业务模型，其实就是业务目标对

应的用来表述业务过程的模型，属于动态的范畴，和领域模型刚好相反。业务模型从业务参与者的角度来描述和产

品或者系统相关的业务过程。

UML中的用况图、交互图、序列图、状态图，其实都是从不同的侧面来描述产品的业务模型。

（3）    捕获业务目标和挖掘业务需求

为什么是捕获业务目标呢？业务目标是业务需求的基础，在业务需求之前。这个阶段，可能产品只有一个思想的

雏形或者是一个蓝图。即便是有更具体的认识，但是很多的认识和了解也是模糊的。很多的想法都是思考、交流和

沟通中灵光一现。所以用了捕获。

挖掘业务需求：业务需求是在业务目标的基础上，通过和涉众的反复的交流和沟通，不断的分析思考中，逐步清洗

和确定的。是有明确的业务目标作为基础的。因此需要挖掘。

（4）    用户了解自己的需求

产品是用来给用户使用的，用户了解自己想要什么。其实这个认识是存在风险的。任何一个系统都会有不同的用户

使用，而每个用户的习惯、喜好是有差别的。用户往往是不知道自己的明确的需求的。即便是有系统分析人员协助

的情况下，能够完整得到用户的确定无二意的需求，往往也是比较困难的。这也是为什么使用了“挖掘”。

-----------------------------------------------------------------------------------------------------------

前面三期连载，纯理论的东西有些多，是不是看的有些枯燥？

下一期开始，大家会逐步开始进入到需求分析和模型建立阶段。这个阶段，除了不断了解、熟悉常识点、方法和思

路之外，实战的内容就是大家会实用UML来进行模型的建立。

有兴趣的可以提前熟悉一下UML相关的基础内容，以及StartUML这个免费的工具，还算比较好用。

最后，感谢大家的关注和鼓励，其实也希翼大家能够多批评，多提意见。这是对我最大的肯定和鼓励。

参考书籍：

[1] 大象—Thinking in UML

[2] 统一App开发过程