2.11 途客圈旅行助手
如今回过头来看，途客圈旅行助手也许是在错误的时间由错误的人员开发出的一款错误的产品。作为途客圈第一款移动端的产品，旅行助手起到了承上启下的作用，是途客圈整个宏伟蓝图中关键的一环。拿到投资让我们头脑发热，没有充分地考虑可行性，就开始着手展开这个项目。
那时viking还留下了很多尾巴。iduu和新加盟的tao在考虑景点POI的wiki化，还有一整套用户激励系统。旅行计划工具还在不断完善，我做了一套API可以处理地铁换乘的查询。这套API基本想法是将一个城市下的地铁站信息数字化成一个带权重的有向图，然后求图上两点的最短路径。这是一个对用户来说非常有价值的功能，可惜随着一次次改版，该功能被一点点湮没。菲姐领着编辑团队将途客圈在地球上的版图从欧洲扩张到亚洲。Kent和各个预订系统洽谈合作，以期能将我们的旅行计划工具接入到机票酒店等的查询与预定系统中，让旅行计划真正“影响用户的旅行消费决策”，为我们的“成为旅行预定入口”的商业目标打下基础。
我们已经在下一盘很大的棋，根本无力再往“旅行中记录与分享”和“旅行后游记与总结”上面发力。
我跟Alex表达了我们没有能力再同时做App的忧虑。Alex认为当前是移动互联网和LBS的一个引爆点，我们要抓住这个历史的时机，一旦错过，我们将追悔莫及。回过头来看，他的话很有道理，“面包旅行”，“在路上”等应用在随后的一年里分别发布，大放异彩。但是，没有人能在市场竞争中永远占据有利地位，所以我们需要搞明白的是，究竟什么是我们关切的核心。在这点上，我们俩的意见并不统一。
最终我们达成妥协，考虑使用外包。Alex、Kent、iduu加上我每天花大量的时间讨论App究竟做什么，偶尔会叫上Nanfang参与（也就在这时，他感觉自己并未被当成核心员工参与重要产品讨论和决策）。最终旅行助手包含了三大主要功能：浏览景点（附近景点），记录旅行中的回忆，查看用户自己在网站上做的旅行计划。Nanfang感觉这个App的功能设置主线不清晰，功能太多，太复杂。但是移除“查看旅行计划”的想法被我否定，而取消“记录旅行回忆”的建议同样也遭Alex拒绝，就这样，旅行助手在妥协中被交到了iduu的手上进行设计。
当时我们这个团队移动开发的能力很薄弱，近乎为零，移动设计的经验非常欠缺，三个创始人对移动项目评审的水平更是一塌糊涂。iduu的交互和设计稿出来我们连连叫好，但所有人压根没有考虑实现上的问题。移动端的设计是件考究的事，产品经理或者设计师需要充分了解开源市场上的UI组件的优劣，以及它们适合在什么样的项目下使用。如果没有这个能力，设计出来的东西再好，交互再完美，工程师也很难实现，或者花了本不该花的大力气去实现。
交互和UI稿出来后，我们联系了一些外包团队洽谈合作事宜，后来发现外包的团队要么感觉不太靠谱，要么要价太高。其实现在回想起来也许当时狠下心来就用有一个很贵但很靠谱的团队，开发人员依旧全力以赴将精力投入到网站产品上，途客圈或许将会是另一番光景。
外包告吹，当时的情形已经是箭在弦上，我们只得自己开发。我提出了两个方案。
（1）使用我们熟悉的Web技术开发，然后用PhoneGap（现在已经成为一个开源项目，叫Apache Cordova）一类的工具将页面打包成App。PhoneGap提供了对手机端SDK的JavaScript封装，让开发者只需撰写HTML/CSS/JavaScript，然后经PhoneGap的编译，就可以生成一个构架在iOS WebView组件上的应用。其优点是可以使用现有技术快速开发，生成跨平台App；缺点是性能以及在复杂交互/用户行为下UI响应比较缓慢。PhoneGap后来被Adobe收购，成为其战略的一个重要部分。
（2）尽快招到合适的iOS工程师，同时Nanfang和我一起学习iOS开发作为预备队。
两个方案并不冲突，于是并行前进。当时移动互联网已经蓬勃发展，大众点评媳妇熬成婆，在移动端大放异彩让几乎所有的互联网玩家都将移动端视为核心利益，所以本来就相对稀有的iOS工程师，变得更抢手。
Nanfang毛遂自荐挖他在ThoughtWorks的好友，可惜那个朋友正处在养家糊口的关键期，对途客圈的前景不明状态感到担忧，所以婉拒了我们。好在人家愿意业余时间教我们iOS开发知识，并答应和我们一起开发这款应用。“十一”黄金周七天时间，Nanfang在辛苦地学习iOS开发，而我在试验PhoneGap等工具的可行性。
也许是眼界的问题，我一直固执地认为移动互联网是一个伪命题。互联网不该和是否移动挂钩。移动设备，就算扯上由传感器构成的物联网，其背后的基础设施还是互联网，运行的还是TCP/IP协议栈，用的还是Juniper等厂商的设备。换句话说，这世上本就不存在游离于互联网之外的“移动互联网”。认知上的误区和模糊让很多人把网站等同于互联网，手机应用等同于移动互联网。如果要这么理解的话，那么移动互联网就是互联网在手持设备上的一个表现层而已。感谢苹果，打造出iPhone，构建了一个由App组成的封闭的生态系统，让人惊呼我们步入了移动互联网时代。可是否有人想过，互联网的基石是什么？开放！那么让大家津津乐道的移动互联网呢？在我看来，“拥抱移动”是一个极其重要的策略，但是它要跟“拥抱App”划清界线。
这种思维上的固执让我一直迟迟不情愿去学习移动端的开发知识。Nanfang很快掌握了iOS开发的基本要素，而我还处在内心挣扎的阶段，厌恶地学着。终于有一天，我对写段文字调个间距还要抠像素这样极其毁灭生产力的开发方式感到愤怒，终止了这段没有结果的学习。我转向PhoneGap，当时似乎还是0.9.x的版本，实测响应速度不太好，尤其是在用户有大量单击和滑动的操作时。我又尝试了Appcelerator。Appcelerator是一款同样让用户使用HTMLl/CSS/JavaScript产生应用的工具。和PhoneGap定位不同的是，它对iOS SDK做了大量几乎一对一的JavaScript封装，让你可以通过使用JavaScript来获得几乎等同于原生应用的速度。优点是速度快，缺点是需要花功夫学习，且容易被锁定在它的架构之上。而且用Appcelerator写代码有种使用使用Ext（一套JavaScript UI，提供一系列标准控件，可以在Web端做出类似Windows的界面）写UI的感觉。
接连否定了PhoneGap和Appcelerator，我们只好决定“拥抱原生”。本来几乎谈定了一个来自易车网的靠谱iOS好青年，最终因为薪水的分歧而相忘于江湖。眼看日子一天天过去，招聘也不是一条靠谱的路子，于是我跟Nanfang商量，他和他朋友做iOS端开发，而我为他们提供API。后来，Nanfang觉得这样效率不高，于是他就接手API，前后端兼顾。我不记得当时是否有djangorestframework或django-tastypie这样的Rest API框架，但我们没有使用任何现成的框架，完全靠自己写出的一套框架，最终却吃力不讨好。
在App开发艰难前进的时候，我们迎来了一位新员工Hugh。Hugh是“邻伴”的设计师。助跑结束后，融资无望的团队就此解散，让人扼腕。在17楼的日子里，“邻伴”和“茄子茄子”是最有拼劲的两支团队，他们伴着我跟Nanfang（后来还有iduu）一同度过了近4个月苦中求乐的生活。
说几句题外话。那段时间里一个某著名广告公司的年轻人连续一个月每天晚上加班到11点，身体最终不堪重负，不幸离世，让人慨叹。现在想想，真是有些后怕，我当时的工作强度远大于此。我当时每天不到7点就开始工作，一直到晚上九十点，工作强度估计要大很多。我们规定的工作时间是一周6天，我基本上干足7天，连“十一”都没有休息。这种强度维持了几乎4个月，而“邻伴”“茄子茄子”有些人的工作强度不在我之下。我们这群人之所以能一直坚持，是因为我们的工作是快乐而具有开创性（即便你会嗤之以鼻）的，他的工作是苦涩而压抑的；我们送走一个白天，迎来一个更敞亮的白天，他送走一个黑夜，又吞下另一个黑漆漆的夜晚。
Hugh的设计表现力中规中矩，但是有潜力可挖。但是选择他则从另一个侧面反映了当时融资后的途客圈头脑发热到什么地步。那时我们已经正式签约了Leanne（她次年春天就毕业了），肯定会留下iduu，所以加上他途客圈就有了3个正式在编的设计师。两个后端工程师配备3个基本不写前端的设计师，这种配置搁哪都显得奢华无比。
招Hugh进来的主要原因是App的设计。我希望iduu能回过身来做Web，Leanne更多地参与用户反馈的收集整理以及访谈，然后Hugh来配合Nanfang他们继续在App上发力。
App的进度之缓慢大大超出了我们的预期。我们很自然地错过了那年震撼国内互联网圈的Techrunch Disrupt Beijing，那是Techrunch第一次也是到目前为止唯一一次在北京举行技术大会。接下来我们又错过了一两个发布时间点。App就像一个无底洞，渐渐地将途客圈的家底掏空。
在这个时候，Nanfang，我当时最信赖的工作伙伴，提出了离职申请。这对于我来说无疑于晴天霹雳，我整个人都懵了。那感觉，就像玩《三国杀》，只剩三滴血的吕蒙正在苦心憋牌，结果悲哀地被闪电劈中，一大把手牌，偏偏就缺个“无懈可击”。