[铁道部信息化管理]需求分析（二）—— 涉众、用户体验

 

• 12306的已知信息、数据及问题
• 需求分析（一）—— 售票系统领域知识（区间票、订票、预留票）
• 需求分析（二）—— 涉众、用户体验
• 核心业务逻辑架构分析与设计（子系统分析）
• 需求分析（三）—— 票仓
• 票仓设计（一）—— 预生成车票方案的优缺点
• 票仓设计（二）—— 区间二进制方案的优缺点
• 票仓设计（三）—— 平衡方案的优缺点
• 票务并发冲突处理原则设计（基于平衡方案）
• 缓存逻辑架构设计
• 数据库逻辑设计
• 灾难备份与恢复

 

涉众

12306在2011年让大家不满意的众多原因中，没有更多考虑所有涉众应该是其中之一。

http://baike.baidu.com/view/10063.htm

项目涉众（stake holder，产品或项目相关人员）的利益之间的相互作用在需求过程中表现得最为强烈。

项目涉众包括： 　　

客户：为达到其公司的业务目标而投资项目或购买产品。 　　

用户：直接或间接与产品打交道，是客户的一部分。 　　

需求分析员：负责编写需求并传达给开发团队。 　　

开发人员：设计、实现和维护产品。 　　

测试人员：确定产品的行为是否与预计的相一致。 　　

文档编制人员：负责编写用户手册、培训资料和系统帮助。 　　

项目经理：制定项目计划并带领开发人员获得成功。 　　

法律人员：确保产品符合所有相关法规。 　　

生产人员：制造包含该软件的产品。 　　

市场营销、技术支持及其他与产品和客户打交道的人员。

======================================

12306是要拿出来给所有购票者用的，购票者不满意，则一切白搭。

大家也可以发现我至今没有讨论过技术实现，因为没有搞清楚需求前，任何实现都会有缺陷。

当然，实际情况是需求永远不会有明确或结束的那天，我们必须工作在某个版本的需求上。由于目前没法子获得12306的相关需求，本人所做的任何设计都是基于一个理想化原型的设计。

 

这篇博文无法写出太多内容，因为我不是资深的前台系统设计人员。我只能从用户角度出发来思考并对目前的UI提出一些建议。并且我试图说明有些系统的性能问题能适当通过UI设计来缓解。

例如，打字机键盘的26字幕分布就是为了解决机械敲击部件所承受的请求压力降低。呵呵，有兴趣参考百度 http://zhidao.baidu.com/question/3217575.html

对于UI的主要想法有如下：

1、希望快速进入购票功能页

2、希望能快速订票

3、希望查询结果能更快

 

1、希望快速进入购票功能页

其实非高峰时段，12306的工作状态还是令人满意的，不令人讨厌。只是一旦到了春节、国庆，举国上下都要对他口诛笔伐。悲剧的承包商哦。

当春运、国庆的时候，如果能让用户访问订票模块更快一点，避免一些页面跳转，至少能降低一些Web服务器的压力吧？（当然，这种降低对整体系统压力没有太大意义。）

因此如果能在特殊时段使用特殊的网站页面导航结构，应该能带来一些好处。

 

2、希望能快速订票

春节，老子要回家。冲到售票大厅...

我：11日到成都卧铺有吗？（起点站：上海，终点站：成都，日期：2013年2月11日，第一次余额查询）

窗口：没有！

我：那12日的呢？（起点站：上海，终点站：成都，日期：2013年2月12日，第二次余额查询）

窗口：也没有！

我：那最早啥时候有？（起点站：上海，终点站：成都，日期：无，第三次余额查询）

窗口：14日早上6：00，16日下午3：00到

我：好的，要3张。

窗口：没有！只有1张。（第一次锁票）

我：那要3张哪个车有？

窗口：14日下午3：00的（第二次锁票）

我：好的

（交易）

======================

反正排我后面的兄弟一定生气，售票员也生气。要是我能一开始就说清楚：

上海到成都，3张卧铺，越早越好

可能只要一次操作就可以了。

 

12306的订票界面上必须要用户输入精确的车次信息。这种处理方式是典型的信息化系统中的问题。

任何操作都是直接与数据处理对接，本质上没有考虑任何用户需求和体验。

如果能有一个UI，让我能输入足够的参数，然后几分钟内返回我有没有车票，会有多好？

有票，那我立刻去确认付款，没票，那么就增加搜索范围。反正我是不愿意告诉我先等上十几分钟，然后还说没订上。

基于余票数量缓存的非实时性，当高峰期大家在抢票的时候，多个请求对应一个座位的情况必然发生。如果能引导用户填写更为详细的订票细节数据，则后台系统可以根据一些规则在多个车次范围内替用户一次完成订票全过程。

如果搜索范围内没有票了，也能立即让购票者知道订票失败。

当然，有人会感觉这种做法会导致一次请求触发后台系统做更多的事情。不过任何IT系统的目的不就是要让用户的交互更直接，更有效么？

后台处理慢，这个是后台设计者必须面对的问题。

 

当有大量客户积压的时候，解决方案就是尽量快速得帮助客户走完整个业务流程。

因此在UI上能有个一键订票就最爽了。

 

3、希望查询结果能更快

当然，平时的情况下，目前的查询结果已经不慢了。我只是吹毛求疵得想进一步优化

目前的12306的余票查询，参数有：

发站、到站、车次、始发终到类型、车次类型

如果能有个时间上去，应该能过滤掉部分数据。

1、最早发车时间

2、最晚到站时间

 

少查点东西，后台能轻松点，网络传输对带宽的压力也能小点。

这两个新的参数最好不是可选参数。其实设计思想就是如同打字机键盘布局设计。

A.增加点点用户UI操作的时间，以缓解单位时间内的并发量（老实说效果应该不会太明显，只针对首次查询有意义）

B.缩小查询范围，降低后端压力和传输带宽（这个应该会有点效果的，目前默认是查当天0：00到24：00的）

 

=========================================

前几天注册了www.12306NG.org的账户。

这些博文会同步在那里发布。

希望中国的开源社区能更兴旺，希望中国的技术社区能更兴旺。