创业公司走向移动化的5个误区

本文来自First Round Review，他们准备的文章既讲故事，还同时向创业者提供可操作的建议，以助力打造优秀的公司。2009 年，Farhan Thawar 加入 App 开发公司 Xtreme Labs 任 VP of Engineering 一职

本文来自First Round Review，他们准备的文章既讲故事，还同时向创业者提供可操作的建议，以助力打造优秀的公司。

2009 年，Farhan Thawar 加入 App 开发公司 Xtreme Labs 任 VP of Engineering 一职。那时候的 Xtreme 囊中已经有很多大客户，其中就包括了最大的社交网络和最热门的体育组织。而这些大客户的共同点就是，他们都亟不可待地要在移动互联抢占先机。

无需赘言，移动终端一次次用数据证明了自己才是大势所趋。Facebook 公布其在美国日访问量的 78% 来自手机端，Twitter 是 75%。并且 Twitter 65% 的广告收入来自手机广告。

对于创业公司来说，他们有限的时间和金钱资源使其不得不在移动化的道路上步步为营。今天的 Farhan Thawar 在 Xtreme 被加拿大公司 Pivotal Labs 收购后任 Pivotal Labs 的 VP-Engineering 一职，他谈论了创业公司在通往移动化道路上的 5 个误区。

误区1：在每个平台上建原生App（“Native App”）纯粹是种浪费

现实：如果你想要一个5颗星的App，不用挣扎了，5颗星是属于原生App的。

跨平台 App（Cross-Platform App）的好处无需赘述，这是个一劳永逸的工程，一次代码能在所有设备上使用。听起来简单，没错，Facebook，LinkedIn，甚至美国西南航空刚开始也都是这么想的。 但图方便的代价就是，很快 Mark Zuckerberg 就跑出来宣称对于 HTML5 （可使网页 App 实现接近原生 App 的体验效果）是个巨大的错误。Thawar 至今仍记忆犹新的是，在西南航空还在用跨平台 App 的时候，他参加的所有会议都把这个 App 作为 App Store 里最糟糕的案例拿出来讲。

“公司们取捷径的时候，丝毫没有意识到，他们把最糟的用户体验留给了所有人“

三家公司后来都重新开发它们的 App。然而跨平台 App 仍对在时间金钱上都捉襟见肘的创业公司最具吸引力。他们过度依赖 HTML5，混合 App （“Hybrid App”）和跨平台工具包， 尽管它们都无法生成绝佳的用户体验，至少现在还达不到。每个看上去很美的解决方案都有它的弊端：

HTML5：跨浏览器兼容问题难以解决，导致最后需要对每个平台进行优化。

混合 App：其实就是原生 app 外壳封装的 web app，这种 app 会像网页一样整体刷新重绘界面，给人慢的印象。此外，应用本身和 web 界面间的沟通层通常较为复杂，也更容易出错。原生 app 无界面延迟，只重载数据。

跨平台工具包：要求每个平台有大量自定义代码，这样给每个平台写原代码更容易。

与其求广不如求精，把最热门平台的 App 写深写透才最重要。这又引发了另一个议论，究竟哪个平台能带来最大收益？当大多数公司都把操作系统 iOS 或 Android 放在首位时，调查结果令他们大跌眼镜。其实黑莓和 Windows Phone 的使用者才是一些公司的目标客户， 这一切都取决于你想要这个 App 扮演什么角色。为找到最佳平台就意味着要挖掘客户群的人口统计资料，从而发现用户们不同的使用习惯。例如 Android 用户和 iOS 用户就有十分不容的使用习惯。Thawar 认为要在完全攻克一个操作平台之后再拓展到其他平台，从时间和质量上来看，这都是做出一个好 App 的唯一途径。

误区2：我们已经有完善的后台支持App了

现实：你需要改变，升级或者完全重建后台以创造出最佳移动体验。

API 设计和实现对构建出运行优良的 App 至关重要。很多公司都体验到远高于网站的来自移动终端的访问量。试想，以银行为例，多数人或许一周都不会登录网银一次却可以每天浏览 50 次手机银行。你的后台设施可以从容应对这样大的流量吗？Thawar 记得曾有一个拥有优良网站后台的客户，在移动 App 上线后，才意识到服务器在处理每个请求时就需要往回输送 1.4MB 的数据，在这种量级的数据交换下优良的用户体验几乎不可能。

Thawar 给公司们应对类似问题的建议是：

将有效载荷最大化：最好的移动用户体验和最小的数据传输并。对于移动终端来说，好的 API 允许从服务器回传的最大的有效载荷应低于 4KB。

分页处理：任何类型的返回列表都应当支持游标类型和分页的结果（例如，我能够从第四页开始的 25 个结果）。

重试:

允许客户端向服务器多次发送相同的 API 请求以确保收到，而‘重试‘同样的 API 请求并不意味着向同一个服务器发送两个请求。

低延迟：每一个 API 请求的延迟越小，App 的反应越敏捷。

每一个屏幕生成单个 API 请求：最完美的情形是移动终端的每个屏幕都只向后台发送不超过一个的 API 请求。允许在服务器终端多程序运行并回传数据以达到松散耦合。

误区3: 自己开发和外包给移动开发公司一样快。

现实：自己开发至少要多花4倍时间。

Tharwar 有着和各种公司合作的经验，甚至是最后不选择和他们合作的公司，他也都一一分类存档以积累经验。很多公司会来到 Thawar 的团队这里询问多久能做好一个怎样的 App。当从 Thawar 的团队里得知这个 App 需要 1 到 3 个月的时间后， 一些公司选择自己开发了。但等他们的 App 在 App Store 上线那至少是 1 年后的事了，4 倍的推迟属于正常范围。

很多团队都有自己的 HTML，CSS 或 JavaScript 的资源，但极少创业公司能有一个成熟的移动开发团队。选择自己开发 App 实则是在金钱和时间的权衡中选择了后者。但为什么开发 APP 要花创业公司这么久的时间呢 ― Tharwar 认为创业公司忽略了最关键的需求 : 对口的人才。

多数公司都没有把增强工程师们在某一特定方面技能的时间算进去。当决定自己开发时，你需要的不仅仅是出色的工程师，而是有移动产品开发经验，QA 和 UI 设计方面的专才。 并且这样的一支团队还要能达到高效密切的沟通。如果做不到，可能的结果是：错误的产品愿景，或是不完善的 QA 等等。

如果你决定找外包的 App 开发公司，那如何选择又是一个问题。你需要关注的对方的企业文化是否契合，相互间是否能建立起高效的沟通反馈，对方公司是否有相关经验。Thawar 认为双方能够高效沟通是最关键的。以 Chipotle 为例，这个大型连锁快餐店自 2009 年的第一版 App 上线后，直到 2013 年才推出第二版 C 四年的延迟归咎于沟通低效。不要忘记，使用者期待见到是一个性能和设计上的不断完善的 App。

Tharwar 给出的建议是，在挑选合作公司是关注以下问题：

从过往的项目和客户那里，他们在技术和经验上分别学到了什么？

能否和客户本身的研发团队共同开发？

他们熟悉“敏捷开发“（Agile Software

Development）吗，能否做到例如紧密协作，密切沟通，频繁交付新版本等等。

他们曾犯过最大的错误是什么？

Tharwar 认为最后一点是最重要的， 这是个关于诚实度和透明性的测试。也会让你对相互间的合作方式有一个初步的试水。

误区4：我如果把App的开发外包了，那我什么也不用做了。

现实：创业公司作为客户，也要密切参与到开发过程中。

最完美的情况是让双方每天坐在一起工作，App 开发公司才能够切实理解你究竟想要什么。对于 Tharwar 的 App 开发团队而言，他们的目标是尽早以及不断交付有价值的软件。对于客户方而言，通过和软件开发公司的合作也是一个积累经验和为未来自己开发 App 准备的过程。一个优秀的移动开发团队甚至可以让你看清楚以后要雇佣什么样的员工，且在无形中提高你未来移动团队的质量。

误区5：一旦我把项目给这个开发团队，我就得永远依赖他们。

现实：你随时可以离开，也可以自己接管。

令人讽刺的一个现象是，最好的移动开发公司最后都销声匿迹， 因为他们教会了客户如何去建立自己的移动开发部门。“结对编程”（Pair Programming）让双方尤其是客户方的优秀的工程师们不断进步，当创业公司羽翼渐丰时，建立自己的移动开发部就不是难事了。

作为一个创业公司，你需要一个理解你公司，产品并且把你的成功和他们自己的成功结合在一起的伙伴。这样的伙伴不仅能够祝你在移动业务上势如破竹，更能给整个公司的业务带来新的机遇。

[本文编译自：firstround.com]