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

xdwangxf

C114果然是藏龙卧虎，看来是来对了。
蝼蚁也罢，新兵也好，只要坚持自己的想法，也是一种经历；批评也好，表扬也罢，都是一种鼓励。

好了，闲话少叙，让大家进入正题。

后面每期连载的基本章节安排是：
1. 对上一期的简单回顾；
2. 本期的重点内容；
3. 本期内容的展开；
4. 小结。

【简单回顾】
上期是连载的一个引文，针对无线通信产品设计的一个侧面，提出问题，并对问题简单的描述和原因分析。然后给出个人对于问题的解决途径的一点思考。

【本期重点】
本期针对LTE网络，提出大家需要设计和交付的一个产品。从用户和投资方等涉众关注的角度，对产品的需求分析之前的准备阶段进行分析和讲解。因为是连载，目的是描述清楚即可，因此有些内容无法详细展开描述。有兴趣的可以邮件或者QQ交流。

【本期内容】
1. 产品选择
如何选择演练的交付产品？产品选择不能太简单。如果太简单，很多常识点串不起来，达不到分析的效果；但也不能太过于复杂，太过于复杂，一个是不好讲解，另一个原因是容易偏离到无线通信技术方向上。那就偏离了本连载讲解产品设计的初衷。大家选择交付的产品要尽可能多的覆盖大家需要关注的常识点，同时具有一定的代表性。下面大家就来选择需要交付的产品。

现在的通信领域，LTE是热门话题之一。从最初的R8协议，到后来的R9、R10、R11等，可以说是无线通信三网合一的一个终结点，更是一个起始点。

了解LTE网络的知道，图1-1是LTE接入网的网络架构图。

图1-2 User-plane protocol stack（From 36-300）

图1-3 Control-plane protocol stack（From 36-300）

图1-2和图1-3分别是LTE Uu口的用户面和控制面的协议栈框图。需要说明的一点是，很多人对LTE协议都有了解，这里不对LTE协议的相关内容展开描述。只是根据讲解的需要，摘录需要的内容即可。

有了上面描述的铺垫之后，大家需要交付的产品就是，LTE终端的协议栈App，一个能够满足基本协议需求的协议栈（不包括基带处理），交付周期为3个月。这里大家不关注项目管理中的人力资源的调度和风险控制等，大家关注的重点是如何从原始的产品需求开始，通过不断的迭代过程，达到最终交付的目的。

需要交付的产品确定了，下一步应该做什么呢？

LTE网络本身是一个扁平化的网络，其协议栈本身的逻辑框架也是比较清晰的。那么是否大家能够在了解协议的基础之上，就启动方案分析和设计呢？

这里抛出一个问题：如果有做过类似产品的，可以回想一下，以前都是如何做的？（欢迎讨论，呵呵。因为我也很想知道。）

针对技术积累不很丰富的团队，面对有一定难度的商用产品，前期的工作一定要稳扎稳打，须知欲速则不达。做App产品，如果前期不工作不扎实，出来混，迟早是要还的。大家可能都有过陷入测试泥沼的经历。

一般来讲，在需求分析之前，需要有一个前期的准备阶段。那么这个前期的准备阶段，是干什么呢？

2. 准备阶段

在准备阶段，主要有三件事情需要完成：

• 了解问题的领域
• 涉众分析
• 规划业务范围
  

最后是针对上述三点分析的整理。这个阶段是为后面的需求分析打基础。

一般做设计、开发的人员，是不会做准备阶段的工作的。一般这些个工作都是由系统规划部和更前端（比如市场技术线）来共同完成的。流入到研发部门的，已经转换成比较规范的产品研发产品需求了。研发部门即便是做需求沟通和澄清，也是和规划部打交道。虽然研发部门也有产品经验比较丰富的员工。

（1）了解问题的领域

“App是一种工具，是用来辅助人们解决某一问题的。App的价值就在于它能够符合问题领域的需要，并达到人们解决问题的希望”。---《大象—Thinking in UML》

问题的领域，其实就是在一定的前置条件约束下，产品需要解决客户的问题。这里的重点是：前置条件是什么？客户的问题又是什么？

如果作为一个App项目的项目负责人，对于问题的领域不了解的话，那么这个项目的噩梦刚刚开始。

举个简单的例子，LTE的数据卡和手机，虽然都属于无线终端，但是运行在数据卡和运行在手机上面的协议栈是不同的。单单针对节电的要求，手机终端要比数据卡要求高很多。同样，拿宏基站和微基站来说，虽然都是基站，而且很多模块可以复用。但是从根本上，可能硬件平台和App架构上面都会有较大的区别。因为系统性能上面的要求就不一样。

因此，作为项目负责人，需要对问题领域，也就是产品的背景、使用环境、运行环境（包括硬件平台和App平台）、整个系统的规模、重要涉众的希望，有一个基本准确的分析和掌握，同时也要让团队的每一位成员了解，大家将要做一个什么样的产品。

现在主流的终端厂商，基本都用高通或者联发科的套片方案，不关心协议栈的设计和实现。但是这里大家为了描述清楚问题，这个工作就需要大家自己来做了。怎么样？是不是有点挑战性？

   

图2-1 多模手机逻辑框图

图2-1 是一个多模手机的逻辑框图。这里大家不用去关心图中的每个逻辑单元的细节。大家需要交付的是图1-2和图1-3中描述的用户面和控制面的App协议栈。这两部分是运行在图2-1的“处理运算单元”中，也有根据硬件配置的不同，为了加快调度速度，调度部分运行在Baseband中。
好，现在暂时放下上面的技术细节，让大家来分析产品的问题领域。针对手机终端的App协议栈，可以简单划分为接收处理和发射处理，也就是常说的下行和上行（无线通讯系统中，下行和上行都是以基站为参照系来讲的）。表2.1描述了App协议栈的问题领域。

表2.1 问题领域描述

领域名称	领域描述
产品背景	针对商用终端的LTEApp协议栈。
使用环境	包括室内/室外，温差范围，湿度范围，充电可承受电压和电流范围等
硬件平台	使用什么芯片？对应的仿真平台是什么？处理器的架构什么？支撑多大内存？片内和片外支撑内存各是多大？
App平台	使用何种操作系统,IOS 、Android，还是Window Phone？
系统规模	系统规模大小涉及到App、硬件和用户等多个方面，评价的因素也是多方面的。针对手机协议栈来讲，系统规模不是关键点。
重要涉众希望	设备成本，交付期限，支撑的功能点，待机时间，
接收机	用于同步、跟踪和接收基站下行的信号。针对App协议栈，主要是接收基站下行的bit流。
发射机	用于和基站上行同步，根据基站指示，发送上行bit流。
其他	。。。 。。。

表2.1中描述的相关点，不是每一个点都很重要。要根据项目的时间情况，尽量多分析，必要时可以采用头脑风暴等方法。因为这些是App项目最初也是最重要的输入。

分析完问题领域之后，根据分析的结果，大家需要整理出业务目标。

注意：业务目标非常重要，因为后面做业务分析，进行边界划分的依据正是业务目标。

大家针对后面需要分析到的问题领域，整理出有限的业务目标来，能够满足大家的分析使用，就够了。

表2.2 业务目标描述

序号	业务目标描述
1	使用芯片，比如MTK6732（其基带芯片支撑Rel.9 Cat.4 FDD、TDD LTE）
2	使用操作系统：Android
3	支撑片内16GB，片外支撑扩展到32GB
4	接收机功能：需要支撑的基线协议是LTE R9协议。
5	发射机功能：需要支撑的基线协议是LTE R9协议。
6	终端能力等级支撑：Cat4。    支撑TD-LTE单模，下行最大速率130Mbps，上行最大速率30Mbps。
7	待机时长：理论待机时长 96小时；通话时长 8小时；上网时长5小时；时频播放时长 4小时；音频播放时长  16小时。
8	…  …
9	…  …

业务目标描述，没有完全按照表2-1的内容去整理。因为大家需要关注的是能够满足大家分析的需求，所以表2-1中部分相关性不大的业务点就不再描述了。

针对表2.2，还有一点需要说明，就是其中的内容，重点和后面大家做业务分析相关的主要是表2.2中序号是2、3、4、5、6的点。其中，4和5的划分范围有些大，后面需要细化。但是现在是在准备阶段，因此影响不大。

（2）涉众分析

涉众指的是和产品有利益关系的角色的总和，不仅仅包括用户，也不仅仅指人。

凡是与产品有利益相关的人和事物，都是涉众，都有可能对交付的产品造成影响。

比如说，使用的操作系统，也是协议栈的一个涉众，因为使用不同的操作系统，对协议栈都会产生影响。涉众的发掘，头脑风暴是一种很好的方法。

针对涉众分析，不同的人有不同的办法，殊途同归。大家发掘、分析涉众的目的就是分析哪些角色可能会对产品产生的影响有哪些？在项目和研发管理上面，这些，和研发设计和风险管理，都是有关系的。同时，也是给后面的业务范围定义打基础。

表2.3 涉众分析表

编号	名称	说明	希望和影响
1	产品所有者（老板）	关心产品的成本和研发周期，不关心产品的实现细节，但是在重大决策方面给出决定性的建议	以最少的成本赚最多的钱。有些针对产品的决定是无法改变的。
2	产品使用者	产品使用者表示使用产品的人，根据产品的边界范围不同，来确定产品的用户。	满足需求，对产品的功能具有重要的影响。
3	产品设计者	比较容易理解	设计满足涉众需求的产品，对产品的功能具有重要的影响。
	产品提出者	规划产品目标，一般是产品研发流程中的高级管理者。提出明确的产品目标和粗略的产品描述。	关心产品研发的结果是否满足产品的目标。对产品的实现结果具有非常大的影响。
4	处理器	针对协议栈App系统，处理器不是直接的涉众。但是属于产品实现中需要考虑的约束条件之一。	为协议栈子系统提供运行的物理平台。
5	操作系统	针对协议栈App系统，运行于操作系统之上，直接相关。	直接向协议栈App系统提供功能接口。
6	应用子系统	运行于协议栈App系统之上，有直接的联系。	需要使用协议栈App系统的接口，实现相关的功能。
7	基带子系统	和协议栈App系统直接相关	向协议栈App系统提供接口，受协议栈App调度控制。

本来想在本期的连载中，将准备阶段讲完，但是因为考虑到篇幅，不宜过长。因此本期连载后面预留的“规划业务目标”和“小结”，就放在下一期连载中再来描述。因为这两个点都非常的重要。我的想法是尽量将这两个点讲解的充分、透彻一些。当然了，深度和透彻度，还是受到个人理解的局限性。

最后在讲两点：

1. 如果对本节内容有兴趣的，可以参考一下《大象—Thinking in UML》，个人理解是讲述UML的实践的一本很好的书。

2. 这几天工作比较忙，也是断断续续的在不断补充。同时，贴图也折腾了一点时间。在这里，要对“家园副管09”表示由衷的感谢。这几天一直在耐心的引导和帮助我。给了我莫大的帮助和动力。这里，衷心的感谢。

我是比较懒惰的，如果不给自己一些压力，就没有动力去整理和总结。刚好C114平台给了我这个可能和条件，在这里也能够得到大家的引导和帮助。 热情之后的坚持，更为重要。

批评和肯定，对我来讲，都很重要。

下一期见！