思路转换的失败

从2008年底開始，我就在Android上进行程序开发探索。随着时间的推移。我越来越不敢妄自预測或者如果程序创意一定会成功，很多其它地发现用户的期望以及需求和事先预想非常难一致。在一年半的开发过程中。尝试了各种不同的方法和思路来进行程序创意规划和试错。至今，依旧失败的教训居多，侥幸成功的非常少。

因此。我将在本文中分享所经历的创意过滤经验以及失败教训。

思路转换的失败

在转入Android开发时。我的相关工作经验都是在大型基础平台上做程序开发。

针对的用户群体动辄就是全球目标用户。在商业推断和分析上，最基础的一个考量就是用户群体和业务模式的总量的收益是否足够大，对用户群体的研究和商业推断分析全然依据市场分析报告和数据来做推断。因此，不可避免地在程序创意思路上会沿用曾经的工作思路和分析方法。

在考虑Android上的创意的同一时候。不自觉地就考虑和分析了例如以下几个方面的问题：

1. 是否为用户所必需？

2. 技术上是否率先？

3. 程序的粘性是否足够？

4. 用户群体是否足够大？

因此。沿用这个思路，不可避免地就会往大的应用和大的服务上去思考和做出推断。

经过多方的讨论。找到了一个切入点：在用户联系人信息上同一时候显示出用户在社会网络（比方Facebook/Twitter）上的同步更新，并加上相关的操作是不错的想法。

理由例如以下：

1. 联系人是手机用户须要的不可缺少的功能，绝对必须使用。

2. 技术上因为须要实现和系统联系人类似的功能，工作量不会小。

假设加上未来在云端的备份，技术门槛也不会太低。

3. 绑定用户的社会网络信息。这个粘性理论上和用户使用社会网络的粘性一样。

4. 用户群体为全部社交网络的用户。考虑到Google手机的用户都是技术的爱好者和早期技术推广者，那么，基本上大部分Android用户都会使用。

依照这个思考方式分析下来。毫无疑问。这个想法一点也不差。可以相当完美地达到预期的规划。

因此，我们投入了3位开发project师和1位产品经理，一共工作了3个月的时间。产品才初步成型。产品的源码接近2MB，最后编译出来的程序接近4MB。

经过了痛苦的研发过程。产品出来之后，结果却令人大跌眼镜：

1. 程序包过大。用户根本不愿意下载。下载量很慘淡。

2. 用户全然搞不懂这个程序的目的和使用方法。程序的命令以及描写叙述非常难表达。而且程序须要绑定用户的社交网络账号，才干够显示信息。

没有绑定之前，看不到不论什么特别信息，也体会不到程序的作用。非常多用户在上手时看到须要绑定，便開始疑惑了。

3. 终于实用户搞明确了程序的使用方法，认为想法不错。但程序的稳定性和性能遇到的了严重的瓶颈。

虽然在其它平台开发经验不错，可是毕竟这是一个新的平台，而且程序操作相当复杂。用户依旧选择了放弃使用。

4. 下载量不高，评分又逐渐减少，程序就在排行榜的榜单上渐渐消失了。

5. 慘淡的结果，让全部參与人员都開始沮丧，认为这并非一个好的想法。后来在iPhone上发现了类似的程序，从销售情况来看，表现相同不够好。再后来，Moto的Cliq基本上完整地把这个想法实现了。并作为一重大创新和卖点进行推出。

经过重复地反省和对照，初步得出了这种失败教训：

1. 对于个人开发人员和小型团队来说，不适合做过于基础的程序。

操作的模式和理念上的创新与用户的接受度有相当的距离。这种事情仅仅有大公司才有財力和可能进行推广。比方说手机生产商。他们能够通过预置的方式进行推广。而对个人开发人员来说。得先证明你的想法是成功的，不能如果一个会成功的需求和应用。然后卖给设备厂商。

2. 个人开发人员和小型团队不适合做大的程序，尤其是开发时间不要超过2个月。4个人，3个月的时间，对于一个小团队来说 ，是相当宝贵的。这不不过时间和金钱的问题。很多其它的是信心问题。

3. 用户是否能真正接受你的想法。是一个关键性的问题。

设想和推导都非常完美，只有缺了用户是否真正喜欢和接受这一条，又没有方法进行高速地验证和试错，基本上不能成功。

因此，在开发人员头脑风暴产生一个创意之后，要做的几个最基本的过滤在于：

1. 开发时间是否太长？

2. 开发的技术难度是否会过高，而导致不能实现或者质量不可靠？

3. 有如何的办法来推断用户是否会喜欢？

有了这几个过滤条件，相信可以降低失败的几率。或者说可以Fail Fast（尽快失败），从而降低损失。

技术门槛的失败

在Android开发的过程中，除了大型的程序探索，我们也研究了些小程序来练手。

有个同事提出Android上删除程序不方便。于是。找人花一天左右的时间做了一个叫Quick Uninstaller的程序。

程序非常easy。启动之后显示全部程序图标，双击程序图标，就可以删除该程序。想法以及难度，都不非常独特。

可是，效果却出乎大家的意料。用户好评如潮，因为功能比較简单，用户基本上无需学习，加上又是先行者。产品质量很稳定，没有不论什么“force close”(Android程序出现异常或者等待时间过长，会弹出“force close”的对话框)。用户毫不犹豫地直接打出5分，而且基本上没有不论什么低分出现过。

可是，好景不长。在一次Google清洗的过程中，由于一些版权问题，账号被Google封掉了。全部程序被强行下架。这个时候，竞争对手迅速上位。就是眼下在排行榜前列的Uninstaller，而我们的程序则一落千丈，虽然如今在某个细分分类中另一定的位置，可是相比排名最高的程序，已经相差非常远了。

这也让我们多了一个失败的教训：

1. 技术门槛不高，不能保证你一直保持优势。

对你来说简单的程序。对竞争对手来说，程序相同的简单。

因此。你能做，别人也能做。在这一点上，事实上竞争相同激烈。

2. 封账号的代价相当之大，基本上等于你的努力悉数尽毁。

Don’t do evil。

因此。在这个案例中。添加了一个新的创意过滤条件：

程序的创意是否过于简单？假设过于简单，那么创意可以始终保持成功的机会不会太高。

依赖第三方资源的失败

在经历了前面的屡次失败之后，我们開始做些研究的工作。发现老外事实上也非常八卦。什么笑话、娱乐新闻等，接受程度非常高。因此。我们就想到了FML（Fuck My Life）的站点，也就是老外比較热衷的糗事分享站点，每天有非常多人会公布各种各样的糗事，文字最后均会以Fuck My Life结尾。

于是。想到假设在手机上有这种client。用户可能会更加愿意用，尤其是在发生糗事的时候。忍不住就想分享出来，粘性也会足够。

基于以上考虑，我们投入力量，实现了一个功能比較完好的版本号，不仅融合了此服务所应有的相关功能，同一时候还花了不少工夫，加上了好多自己定义的功能。

经过一段时间的努力，在Entertainment分类上，排名进了前10名，印象中程序最好排到了第3名。

好景不长在，失败总会有。

这个时候。FML的官网发现了这个机会。他们认为这是一个非常好的想法，应该自己在Market上公布自己的官方程序。于是，他们干了这种事情来清除竞争对手。他们直接向Google举报，说其他程序没有得到他们的授权。一次举报，竞争对手所有清干净了，于是他们的官方程序上线了。

这一次，得到了一个更加深刻的教训：

1. 不要过于依赖第三方资源。依赖第三方资源或者站点的名气。的确可能帮助你的程序受到非常多关注，代价也相同存在。一旦人家開始动手举报，你连还手的机会都没有。

2. 不要选错第三方资源。非常多的服务提供商是不开放的。虽然他们没有明白说明。

同一时候还有非常多服务提供商是充分开放的，比方Twitter就是一个非常开放的样例。

选错了第三方资源。结果一样会失败。

因此，这里又多了一个创意过滤的条件：

是否依赖于第三方资源？ 假设是。请尽快绕道离开，由于非常难靠这个想法走太远。

胡乱模仿的失败

因为才疏学浅和关注面单一。想法总会实用完的时候。在尝试了非常多自己的想法之后。非常多人都会有想法来借鉴或者说抄袭App Store上排名靠前的程序。

可是，以我的经验和分析来看，这条路基本上不可行。

有下面几个方面的原因：

1. 画虎不成反类犬。假设是在人家创意上进行的功能改进。你还可能有一定的突破和机会。

假设不过抄袭，因为平台的不同，Android的控件和iPhone的程序控件相差太远，哪怕做出来程序类似。操作体验和程序的精致程度也和iPhone上程序相差甚远，往往就成为画虎不成反类犬。

2. 版权问题。老外的版权意识很强，不不过原作者很关心，用户也很敏感。假设侥幸程序排到了前列，不仅会把原作者招惹过来。用户还会出来举报。

一旦Google收到了举报邮件。基本上是杀无赦。反倒是偷鸡不成蚀把米。

因此，创意过滤中又多了一个条件：

创意是否有版权争议？假设是，尽快停止。

失败仅仅是时间的问题。

其它

总的来说，在我的探索过程中。成功的少。而失败的太多太多。

在与Google打交道的过程中。依旧有非常多失败的教训可供分享。

1. Don’t do evil。美国人做事的方式很直接。同一时候会默认你是善意的。

对于Google来说，尤其如此。因此。在我尝试过的程序中，你能够随意公布你的程序到Google Market。可是。假设涉及到版权纠纷，无论是站点的全部者、原程序的开发人员还是其他不论什么一种类型的版权纠纷，一旦举报到Google。轻者下架单个程序。重者封禁整个账号。而且下架全部程序。也就是说，一旦受到处罚。你就别想翻身了。因此，Don’t do evil。

2. Google的审查底线。虽然Google不做审查，但除了和版权争议相关的程序之外。哪怕是你自己的程序，依旧有例如以下的禁区是不能碰的：

a. 不要使用不论什么Google相关的名义。程序名、开发人员名都不能涉及到Google或者看起来类似Google的名称，否则Google不会予以通过。

b. 不要违反不论什么Google的开发人员协议。须要细致阅读Google的开发人员协议，在不同一时候候Google的开发人员协议会常常更新。

因此，仅仅要违反了不论什么Google开发人员协议，当Google处罚到你的时候，基本上没有申辩机会。因此。务必要小心。

总结

在我开发的经验过程中，成功的经验不多，而失败的教训无数。哪怕如此，我坚信在移动互联网领域，依旧存在这样或者那样的机会。

或许不经意间你的一个创意就得到了用户的热捧。有幸跑到排行榜的前列。可是这须要足够多的精力和耐性来打磨你的产品，才不至于昙花一现。同一时候，也不能得意忘形，说不好。就会有各种各样的可能导致你失去优势。因此。移动领域的确是一个新的机会，但绝对不是一个可以随随便便抓住的机会。希望我的失败教训可以帮助到开发人员，以此为鉴。

作者简单介绍：刘铁锋。曾供职于微软亚洲研究院搜索技术中心，眼下从事移动设备软件相关开发工作，关注Android、iPhone等相关开发技术以及App Store、Android Market等业界应用商店进展。

（本文来自《程序猿》杂志10年05期）

《程序猿》10年7月刊精彩内容预告：http://www.programmer.com.cn/3484/

《程序猿》订阅：http://book.csdn.net/programmer/