先前我曾透露自己在暑假里参加了一个叫“花旗杯”的软件设计比赛。昨天，二十强结果出来了，很遗憾我们没有入围。

在此之前，我一直认为自己有十足的把握进复赛。我和老广说，哪天一定要好好出去搓一顿。然而现实狠狠拍了我一巴掌。这让我不得不思考这样一个问题：为什么我们没能入围？

我们项目的灵感来源于大卖场的排队结账问题。在中国绝大多数的卖场里（如家乐福、沃尔玛、大润发），消费者在选购完商品后往往会面对一个棘手的问题：他需要很长的排队来结账。收银员需要一个接一个地为顾客刷商品，然后处理支付。这样当客户比较多（特别是节假日），平均每位顾客购买商品也不少的时候，所有人的平均结算等待时间就会被拉长。这样无论是对消费者的购物体验还是商场的运营成本来说都是不小的打击。买的人得把大把时间浪费在无谓的排队上，而卖的人得安排更多的收银台来应对问题。 于是，我们想通过软件来提供一个解决方案。我们花了将近一个月的时间来完善想法，设计，开发。最后，我们完成了一个 C/S 架构的软件系统。

系统的客户端被部署在 Android 手机上。它拥有以下功能：

  • 通过条形码识别来获取商品信息
  • 移动支付

我们的想法是，用户在购物的时候用手机扫描商品，装入购物车，最后用电子支付的方式来完成购物。这样顾客在逛超市的同时就能完成商品的扫描了（是不是类似自助结账？）。此外软件提供了更多的商品附加信息让用户参考（起初想加入评价、推荐系统的，最后迫于时间切了）。理想情况下用户结账时不需要等待，超市也可以省去不少人力成本。

此外，移动支付和参赛主题——“提高服务质量与产品价值”扯上了关系，银行肯定会感兴趣的。

下面是软件的 slides：

没错，我们当初觉得只要把产品实现了，就一定能进复赛。可是现在我得回头看看自己存在哪些问题了。

1 具体实施难度太大

实际上，系统的实施是建立在诸多前提和假设的基础上的。譬如，我们需要银行和卖场达成协议参与支付合作；商场愿意提供商品数据；用户拥有较好的移动设备。 嘴上说起来容易，但是放在现实环境中实施难度非常大，要考虑的因素太多。你没法保证用户不会实际上多拿一件商品而在结算的时候偷偷漏掉。我们想通过一个商品核对通道来阻止这种非诚实的做法，但是这和原先的人工收银相比并没有节约多少成本。

2 创意撞车

小组确定并提交创意是在 5 月中旬，而在当月下旬，Google Wallet 推出，我们发现悲催了，Google 正好还和花旗合作了。但是报名表已经提交，我们希望在其他地方找到突破。

本以为所有参赛小组就我们做这方面的开发，后来在 TOP 20 名单里我们发现了一个类似的项目“SignPay”。不是你死就是我亡，很遗憾我们技不如人败下阵来。

3 软件不够完善

虽然整个比赛花了一个月时间，但是真正用在开发上的时间并不多。我们把很多时间花在了应付参赛材料上。大量的文档！说到这不得不吐槽一下：尼玛的组委会，要这么多文档是闹那样？还要中英文版的，坑爹啊！把我们当翻译了啊！

我还是坚持认为开发出可用的软件才是王道，文档再多它还是文档！

4 缺少清晰的商业模式

这是花旗杯评委给老广发的邮件里说的，确实我们没仔细研究过商业模式。觉得只要用户多上去就一定能赚钱。。。好吧，学期的需求工程讲了不少东西，如果能在需求阶段下点功夫或许没那么糟糕。

5 物理购物车和虚拟购物车有所脱节

这也是老广收到的那份邮件说的不足之处，他们觉得做个物联网会很牛逼。这东西炒的是很热，但是成熟的不多。我们考虑过这个问题，可是觉得涉及到硬件层，望而却步了。

遗憾一：没能进复赛

这个是肯定的，毕竟是参赛性质的开发。没进复赛，实属遗憾。

遗憾二：没能把软件写完

在提交作品时，系统还存在很多不足的地方。几个 feature 没写完，老广的后台管理界面，我的账户管理模块、商品搜索……还有不少地方的 bug 没修复。还有个痛便是评价和推荐系统的夭折。。。

遗憾三：代码没能进一步重构

天生的完美主义者，痛恨丑陋的代码。可讽刺的是，自己经常写出烂代码。最后只能通过不停重构来让它看上去不那么丑陋。回头看看，该重构的地方没来得及重构。

遗憾四：设计啊，美工啊

我们小组没有美工，最后只能由我来设计界面，P 图……愿有生之年再写应用时有一设计师相伴。。。

后记

吐槽这么多，我觉得做事呢，最重要的就是开心。发生这样的事，我们都不想的，所以呢还是得脚踏实地。说说收获吧：

  • 自己亲手一行一行地码了一款 Android 应用
  • 顺便学了学设计，美工
  • 结实了老广、QCX，QC，天明和几个商院的朋友
  • 暑期没完全荒废掉

好吧，花旗杯之路算是结束了。前事不忘后事之师，向前看！