文章分享了作者在香港做旅游产品时，由于文化壁垒而面对的一系列挑战。希望通过对作者心路历程的了解能够对你的产品工作带来一些帮助。我们都知道有各类肤色的人，知道有多种语言，但是我们却未必知道或者体会到其实还有各种文化背景导致的不同思维逻辑和世界观。在以前我以为所有人都会像我们身边的人那样去思考去处理问题，但是不然，等你走出与生俱来的文化背景后，可能得重新来审视你以前的认知。
1.初见
我接触香港的产品是2011年底，当时混混沌沌进入了ctrip，其之前收购了一家香港旅游公司，这个新搭建的团队正是为这家旅游公司搭建网站，一切都从0开始。 这个团队的文档都得用繁体字或者英文，当时我有点没底，因为以前接触繁体字少，英文也菜，其实身边同事情况也差不多，但是他们大多是开发人员，影响没那么大。 随着时间的推移，还是碰到了纠结的问题：- 一个是在开发过程中开发人员输入法没切换到繁体字，系统的页面总有简体字和繁体字掺杂在一起的情况；
- 另一个问题就是：有些语句的用词我们把握不准。
2.领略
14年的时候部门开始规划移动端项目,这个时期我开始接触产品规划，当时香港还不怎么流行旅游类APP，但是facebook 和 whatsAPP等社交类的已经流行起来了，从群体上来说facebook 和 whatsapp应该是偏年轻人，旅游不是高频也不专属特定年龄段因此没有大面积推广。 旅游产品预订的流程比较长，要展示的内容比较多，但是受到手机屏幕大小的制约，在产品规划时就觉得内容要精简，流程要压缩，有些步骤要默认处理，受这一思想指导，加上香港OP那边也没什么建议，又是从0开始。 上级决定先尝试开发一个业务系统，边走边改进，积累点经验，当时也没考虑流量的问题，那时只好参考Ctrip的APP风格，结合我们web网站的业务逻辑，同开发人员还有上级确认后，定了三个产品目标：- 主流程的页面要控制在6个页面内，精简内容；
- 尽量减少用户输入；
- 尽可能符合香港人使用习惯；
- 一个用户资料错误，做产品时默认设置性别=男，但是有些用户是女的，没注意这个栏位，也就没去修改，导致出票时信息对不上；
- 另一个是由于APP要控制页面数，删除掉了web有的订单核对页，客人在提交订单后才发现日期选择错了；
- 还有人投诉在他没看条款时系统默认给他勾选了条款；
3.主动出击
在后来的产品规划和优化中，我们团队都尊重香港的文化因素，尽可能多的站在香港用户的角度去感受产品。不是等待投诉后才去优化，而是主动出击。主要是有三个方面： 以前系统订单的客人资料信息都是没有加密的，包括电话，电邮，证件号码，原因是这些信息要在预订过程中展示给客人确保资料无误；但是在一次系统扫描中，发现这些信息可能会被外界获取，这样会带来危害，如果是竞争对手获取那么就可以通过电话挖走用户；黑客获取会招致更大问题。但是预订时就优化客人可能无法检查填写信息是否正确。 当时我注意到我们系统的订单基本可以在24小时内处理完成，只有个别系统的处理时间比较长，那时我提出了优化方案就是在下单完成后对用户资料进行页面加密，在下单完成24小时后对数据库用户资料进行彻底加密。 逻辑考虑是页面加密时数据库数据并没进行加密可以不影响订单处理，在24小时后订单基本处理完成后对数据库进行彻底加密，其实当时对彻底加密有反对声音，因为彻底加密会使系统的用户资料都加密，包括日志里的用户资料都加密，可能会影响一些订单日后的跟进处理，在单个业务系统实验一段时间后发现没什么问题就在全系统铺开了，后来担心竞争对手分析订单数据，上级要求对超过6个月的订单进行了订单号加密。这样我们保证了用户信息的安全。这一招后来携程也借鉴了，但是他们的后台逻辑具体如何我是不清楚的。 另一个优化是Moto支付，当时系统监控到同一联系人在多个城市预订同一天的酒店，并且订单金额非常大，当时我们是觉得很高兴的，把这情况反映给香港op，他们的反应却很不安。 后来他们通过一些手段发现是有人盗刷信用卡，并且连续几天出现这情况。当时我们认为信用卡是客人自己丢的，为什么要我们系统承担盗刷风险，但是香港的法律就是维护用户，要求旅游公司赔偿一部分损失。 在这之后我们引入了风控系统，风控的规则是上海ctrip定义，我们只是调接口传数据，上海返回风控结果，这时又出现问题了，风控有误判也有没挡住的盗刷，之后又做了3D支付，把风险转嫁一部分给银行。这一块还在不断优化，就是想给用户一个安全的支付环境。 最后一个是打点系统，这个是开发人员做的，不算产品但是提升了产品的防御能力。香港的法律十分注重维护个人权益，客人一投诉就得给客人赔钱。之前有些投诉我们觉得很奇怪，因为按照客人的那种处理模式，我们反复的验证都不会出现客人那种投诉的情况，但是客人坚持是系统问题，客人还有截图，我们没反驳机会。所以每次一投诉就是折腾一番，没找到原因还得赔钱。 聪明的开发人员也是为了尽早找出问题，因此开发了一个打点系统，记录用户的操作（当然敏感信息没记录），以便分析。在后来的日子里这套系统的确找到了一下遗漏的业务流程，但也给那些通过修改页面脚本进行投诉然后来骗赔款的用户当头一棒。 有几次用户投诉的内容与其在APP预订的流程不一致，其还保留了截图，认为是我们系统问题，要求赔款金额也比较高，后来就是通过我们的打点系统的数据对客人的说辞进行反驳，客人才从不依不饶中安静下来，不要求请求法律处理，因为我们也有证据。 以上就是个人在香港项目中的一点体验，浅闻小见，盼诸君多多指教。不胜感谢！ 本文由 @飘雪的南方小城 原创发布于人人都是产品经理。未经许可，禁止转载。 题图来自PEXELS，基于CC0协议 爱盈利-运营小咖秀 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
