APP案例分析

标签：火车站   简约   网络拓扑   live   原型设计   简便   不同的   软件工程   应该   

今天探讨的APP是：铁路12306。

选择这个APP,是因为使用了很多年，很有感触。

第一部分：调研、评测：

1、下载软件并使用起来，描述最简单直观的个人第一次上手体验。

第一次安装这个软件的时候，是三年多前，为了购买学生票，在那个时候，铁路12306APP经常会出现卡顿状态，远比现在差很远。随着这几年不断的更新变化，从验证码的图片选择，系统的不断完善，改善了很多，但是还是有不足的地方。

2、按照《构建之法》13.1节描述的 bug 定义, 找出几个功能性的比较严重的 bug。

（1）软件流畅性不好，经常卡顿。

（2）今天是9月30日，明天就是国庆。发来短信说过期时间，还下载失败，无疑增加乘客的忧虑，然后乘客只好登录铁路12306APP查询车票，订单查询分为已完成订单和未完成订单，已完成订单还分为今日订单、未出行订单和历史订单。历史订单应该包括今日订单之前的订单才对，然而并不是这样，它只是包含了历史已出行的订单，难道未出行的订单就不是（之前订好的订单）吗？总之查询订单做得比较不好，界面文字不够直译。

（3）就是学生票问题，由于是学生，所以在自己的这一栏就是学生状态。在买票的过程中，除了假期能买学生票之外，其他时间段都不行，系统不会自动改为成人票，不是学生票区间，提示学生票需要证件，然后点击转换成成人票时，经常出现卡顿状态，然后显示成人票，也可能购买成学生票，就经常会买成学生票，然后改成全票很麻烦，如果没有票的情况下，退票就直接没有票了，这时候只能去火车站售票点改全票，十分麻烦（因为改签人特别的多）。所以如果不是要买学生票的情况下，我想大多数人都会通过携程之类的平台购买了。

　　以上这些只能说是问题，或者逻辑不对，至于严重性的Bug,倒是没有那么严重。

3、用专业的语言描述 (每个bug 不少于 40字)，如有必要, 配图更佳。

（1）症状：输入出发点查询后，时不时卡顿。

程序错误：应该是数据量太大，读取数据的时间就非常慢，数据库的检索功能不好。

根本原因：一直在就绪状态，没有得到执行。（我猜的），虽然也经常提示网络连接问题，但是别的软件又不会。

（2）症状：查询车票太繁琐，不明确。

程序错误：分得太繁琐，导致程序也得相对应的写很多不需要的东西。

根本原因：设计逻辑不好，因为是登录后的，所以可以直接显示本人未出行订单，然后所有的订单都放在历史订单里面，至于其他人的才更改默认用户姓名进行搜索就可以了。

4、选择一个朋友（用户）进行采访，并加以记载。

采访同为学生的L同学，通过铁路12306APP购买动车票的体验。

5、提示: 采访提要

（1）介绍采访对象的背景和需求。

采访对象：周边的人（学生居多，因为有购买学生票的事）。

需求：需要订购动车票。

（2）让采访对象使用该产品的功能。

（3）描述用户使用这个产品的过程，用户的问题解决了么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？

用户使用这个APP的过程，卡顿现象还是时常发生。数据量肯定是完善的，界面很简单（其实可以增加很多方便用户查询的界面）。功能上来说，查询不够直接，需要改进，还可增加出发点和终点公交路线等等功能。根据地点还有时间段，把学生的学生票选项直接变成成人票。体验方面，卡顿状态能去除最好。

（4）用户对产品有什么改进意见？

提高APP流畅度，完善查询功能。

（5）结论：经过这么多工作，你一定有充分的理由给这个软件下一个评价:

一般。

第二部分 分析

1、尽可能地使用软件的所有功能 。

主要功能为：登录（实名认证）、车票预定、订单查询、查正晚点等等。

2、分析这个软件目前的优劣 (和类似软件相比)， 推理出这个软件团队在软件工程方面可以提高的重要方面 (具体建议)。要求把对比的结果列出一个表格，对比每个软件各自的优点和缺点。

3、针对不同的维度评分，对用户体验方面、UI界面美观度、核心功能，分别打分

第三部分 建议和规划

1、如果你是项目经理，如何提高从而在竞争中胜出？

利用这个火车站官方APP的优势，努力把软件流畅度提升起来（最重要），增加查询的一些功能，比如常见问题总结、订单查询需要更加的直译等等。

2、目前市场上有什么样的产品了？

购买火车票已经有很多网站，用得较多的有携程旅行、高铁管家、去哪儿旅行和同城旅行等等，这些购买火车票都很方便。

3、你要设计什么样的功能？

设计常见问题总结栏，完善订单查询界面以及相关功能和学生票的功能完善，还有就是购买哪趟车提醒的功能。有些软件有抢票的功能，这个行为不是太好。

4、为何要做这个功能，而不是其他功能？

因为学生票的关系，长期使用这个软件购买车票，对这些功能很有感触。有相关问题总结栏，可以方便购买者浏览，出了问题，自己有个怎样行动的方法，不然还要去网页查询或者询问他人等等，很麻烦，订单查询功能，现在的也不是不好，不够直接，还有就是不是很方便，因为已经登录过自己账号了，查询的话还要分栏目，日期什么的查询，有些不好。因为车票都是提前购买，所以有个提醒功能的话，就会更加的完美。至于抢票的功能，觉得这是没办法的情况下，才需要的，已经有别的软件实现了，自己没有必要这么做。

5、为什么用户会用你的产品/功能？

因为这是从用户的体验出发，这些功能都是用户最长遇到的，反感的东西，现在有了这些功能，相信用户会感到十分的人性化设计。

6、你的创新在哪里? 请使用 NABCD 分析

（1）N（Need需求）

解决了问题出现时，有个快速查找的解决问题流程的方案，让用户更加放心使用，这是原本软件没有的地方。解决了用户查询订单的麻烦，因为每个用户都有自己的账号，每次登录该APP都会登录账户，查询订单应该更加的简便（原来的查询订单就像文章上部分讲的不够直译，还有功能不是很完善）。解决了学生票的不完善。解决了忘记第一时间购买的车票（虽然用户可以自己用手机备忘录实现，但是APP实现这个功能的话，用户肯定会觉得这个APP更加的人性化，因为自己设置备忘录，还要去算日期的，并不是很方便，而且每趟车的起售时间也是不确定的，这点APP来实现的话，效果更加好）。当然，重中之重的应该是完善这个软件的流畅性。

（2）A (Approach做法)

对于问题栏的做法，这个比较简单，通过对数据的增删改查就可以了。

对于用户查询订单，这个需要重新设计页面，原来的比较的繁琐。所以这个需要更改原来的代码，但还是类似的，需要先把前端的界面设计好，改掉原来分很细的地方。只不过查询订单时，默认是用户人自己，然后近期的未出行的订单直接显示出来，一般都是查询未出行订单的人数多，对于完成订单的（不管出行不出行），全部存在历史订单里面汇总。

对于提醒预定的功能，这个需要全新的界面，需要用户自己填写出发时间，还有车次，所以要有车次的查询功能，然后自己对售票前多久提醒自己来定义。

一个刚开始的团队，需要先了解每个人的强处。根据功能点来分配给对应最佳的人选，当然需要一个人来查看进度，测试各自功能点的实现，小问题，少数人商量解决，大问题，整个团队开会协商（这是目前自己的见解）。

（3）B (Benefit好处)

解决了目前系统存在几个较为严重的问题。更加的完善该系统，更加的人性化，对于同类型的APP，存在的最大优势在于，很多其它APP也是要导入12306的数据，然后其它APP还有很多其它无关的功能点，占用系统的资源，当这个铁路12306APP流畅性得以解决，功能更加的完善，相信更多的人会选择这个，毕竟这个才是官方的购票软件。

（4）C (Competitors竞争)

如Benefit好处所说的一样，这个是单纯的购买火车票的官方APP，虽然现在也在增加商旅服务（约车服务、订餐服务），但是这些都是自身功能不足的完善点，而且是官方的APP，其它软件也是基于这个平台的数据，所以提高软件流畅性，完善功能之后，这个软件必然是用户的首选用来购买火车票，对此，对竞争十分有信心。

（5）D (Delivery 交付) 

需要通过大量的测试，不同的人群，不同的年龄，发布测试版，根据回馈的意见，做出相关的改进。

7、如果你来领导这个团队，会有什么不一样？

只能说，更加的照顾团队，关注团队的每一个人状况，相信当团队人心一致的时候，就是发挥最大能力的时候。

8、如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？

第1~2周：调研、可行性分析和原型设计，制定项目计划

第3周：需求分析和定义。

第4周：系统设计。确定系统总体架构，确定开发工具等，对应用系统关系进行架构性设计，用图的方式描述出用户和各子系统或模块的全局视图，以及和其他系统的关系，也就是搞清楚系统的边界问题。概要设计中高层架构设计、设计网络拓扑图和系统部署图。对子系统、模块进行合理的划分。同时确定模块的名称。

第5—10周：软件编码。一开始美工2人，开发2人，测试1人，然后一个美工转开发，另一个兼顾测试。一开始的测试人员需要兼顾全局，需要给一个能力较强的人员来当。

第11周：5人内部疯狂测试，压力测试，美化界面，改掉不足，还有规范代码。

第12周：第一次软件小型用户测试，收集用户反馈的意见。

第13周：根据用户的反馈意见做出正确的修改。

第14周：第二次软件大型用户测试，同样收集用户反馈的意见。

第15周：同样根据用户的反馈做出正确的修改。

第16周：美化界面，多次进行测试、压力测试，规范代码。

第17周：软件发布。

APP案例分析

标签：火车站   简约   网络拓扑   live   原型设计   简便   不同的   软件工程   应该   

原文地址：http://www.cnblogs.com/wekinglin/p/7615948.html