分类
互联网

远离腾讯系的金融产品

最近一周接连遇到两件事情。

一件是腾讯旗下微众银行,每天从我的平安银行卡里面扣钱,连着扣了 4 天,实在忍不住了,千辛万苦联系到客服,结果终于知道了原因。因为之前我设置了一个存钱计划,每个月会向微众银行存 1000 元。计划分两步,第一步是从平安银行扣款存入微众银行,第二步则是从微众银行账户转到存钱计划“活期+”。

但这个月,不知道他们的系统抽了什么风。这个计划只执行了一半就失败了。但又不是全失败,第一步扣款是成功的。但第二步失败了,导致我在微众银行的 App 上看到的是,是‘执行失败’四个红字。查询微众银行的交易记录,这四千元的交易也全都失败了。但我从平安银行查看,扣款成功,余额减少了。这就奇怪了!钱难道飞了吗?后来客服详细解释才发现,钱都到了微众银行账户,但是因为 App 上的交易流水并没有把两个步骤分开显示,只显示了最终的结果,所以显示成了执行失败。

按理说,如果只是从微众银行到“活期+”失败了,你下次重试就再重试这个步骤就好了,完全没必要再完全从头开始从平安银行扣钱啊。这个傻乎乎的机制,导致了我的钱不停地被扣,到了微众银行,却到不了“活期+”。不仅少了收益,而且这种不停的扣钱,还会影响到整体的用钱计划。

两天之后,我又遇到一件事,我还房贷的银行提醒我本月还贷金额不足。我在腾讯的理财通设置了还贷计划,为什么会没有转呢? 又费劲千辛万苦,好不容易找到客服,发现是,本月执行还款计划失败了,而且失败后没有提醒我,导致钱没到银行那边。

这两件事发生后,让我对腾讯系统的金融业务产生强烈的质疑。不得不想办法尽快把腾讯系下的所有资金全部转移到支付宝。

之所以这么做,原因有三:

1  系统系统可靠性让人质疑

大家都知道,金融业务相对于其他业务,在可靠性方面有更高的要求,可是作为互联网巨头的腾讯,至少在金融业务是上,可靠性并不好。经常没理由的失败。

2  不合格的产品设计水平

腾讯在业界是以产品力见长的。但在金融业务上,产品设计不仅没达到优秀,甚至连合格都称不上。

比如,如果微众银行账户和“活期”是两个账户,你显示交易记录的时候,这两个账户之间的交易也需要显示,而不是把他们当成一个账户。

比如,如果任务执行失败,你需要做两件事。一是告知用户这个失败,让用户知道;第二是你必须要告诉用户该怎么做来避免失败。遗憾的是,这两个都没有做。

比如,如果完成一件事,有三步,前两步成功,第三步失败的时候,你应该从第三步开始重试,而不是完全开始。

这些都是互联网产品设计的常识。除了第一个问题可能需要一点点的金融常识。后面的原则,几乎是每个一年级产品经理都应该掌握的。

这样的错误,出自腾讯,令人震惊!

3 客服躲起来了

近几年互联网业务的有个趋势,就是为了减少人工客服的成本,都用一个没什么用机器人憨憨挡在前面,解决不了问题,至少能浪费你的时间。而腾讯的客服,躲得最深,你要找到他们比在支付宝找到客服要费时多了。

就在我这篇文章写完的时候,腾讯的人发来短信,告诉我还贷计划失败的原因。是因为设置的是 14 日还贷,系统提前 2 个工作日还款。但因为遇到周末,这次还贷不是在以往的 12 号,而是 11 号。而 11 号的时候,我的平安银行卡里钱不够。

我想了一下,为什么我 11 号钱不够呢?原来,因为我的计划是按照”活期+”每月只扣 1000 来设计的。但这个月他不是扣了 4000 吗。

惊不惊喜,两个 BUG 还实现了完美的业务闭环!组合服用,威力更大!

分类
小技巧

使用Google Sheets 维护多语言界面文案

给App或者网站做多语言,说简单也简单,但也很枯燥。如果大公司的话,可能有专门的团队来做这件事,但如果你恰好在一个做出海业务的创业团队,这个枯燥的活,你逃不脱。

幸好,经过一段时间的摸索,结合Google sheets,我探索出了一套还算高效的流程,记录一下。

1、先用一种语言做设计并开发完全部功能

在给一个应用做国际化的时候,可能有两种思路。一种思路是,一开始在设计阶段,就给出不同语言的设计稿,在页面开发过程中就实现多语言化。这样的好处是,因为文案而导致的视觉问题,在设计阶段就会被考虑到并解决,但坏处也很明显,就是维护文案麻烦,设计起来工作量也太大。如果有些文案,是开发阶段才想到的错误提示等,常会遗漏翻译。为了避免这些问题,我们的方案是,先用一种语言做设计和开发, 等开发全部完成之后,将涉及到界面文案的部分,全部抽出到语言包文件中。然后开发将语言包文件给产品进行多语言化。

2、 分离文案

当我们拿到开发给出的语言包,往往是代码和文案的混合。以Android App 为例,类似这样:

 <string name="binding">绑定</string> 

第一步,将文件中的内容全部拷贝到一个新建的Google Sheets 文件。这些内容在Google Sheets中会是一个多行一列的形式。

第二步,使用***分列*** 功能,将内容分伟不同列。分列之后,长成这样:

 <string	name="binding"	绑定	/string 

一列多行的文件会变成多行多列,每一行是一个文案。这时候,文案部分就称了单独的一列。

3、 使用Google Sheets 自带的 GoogleTralate() 函数进行翻译

当源语言单独成列之后,新建几列,用来放置目标语言。这时候,使用GoogleSheets而不是Excel的优势就体现出来了。他默认自带的函数***GOOLETRANSLATE()*** 会很容易将内容翻译并放到目标单元格中,省去了你通过网页翻译需要重复复制粘贴的麻烦。该函数使用很简单,只要要输入 =GoogleTranslate(文本,[源语言],[目标语言])并回车即可。比如,你想将E列的中文翻译成法语,只要输入 =GoogleTranslate(F2,"en","fr") 即可,回车后还可以下拉到整列,以便将整列都翻译。而翻译不同的目标语言,只需要调整刚才输入公式的第三个参数即可,比如你要一列荷兰语的翻译,只需要将刚才的公式输入改为 =GoogleTranslate(F2,"en","nl") 即可.

这样,你可以在几分钟内得到一个App 的十几种语言翻译。

GOOGLETRANSLATE()函数

4、邀请Native Speaker 加入Google Sheets 进行校对

如果你有相关的预算找专门的翻译人员或者你的用户中有热心人士愿意帮忙,你可以邀请他加入这个Sheet 中,授予其编辑权限对机器翻译的内容进行校对。

5、拼接为符合开发要求的文件

因为我们再第一步的时候,改变了开发所给的文件格式。等我们得到了每一列的翻译并没有问题的时候,就可以将翻译好的内容输出为开发项目中要求的格式。

这个时候,我们还是使用公式来快速完成。输入类似这样的公式=A2&B2&">"&E2&"<"&D2&">" ,他会将文案左右两边的<string name="binding"></string> 重新拼接在一起,和一开始开发给你的内容格式一样。 这样每一列复制出来,存放在一个语言包文件中即可。

6、UI走查

开发将语言包文案放入到项目中并编辑打包后。需要你切换到每一种语言进行UI走查,主要检查两点。一是检查是否有语言漏翻译的(虽然基于这个流程来做,很少出现,但DoubleCheck总是没错的),二是检查是否有些文案的长度破坏了界面。尤其注意法语、日语会很长,而阿拉伯语是从右往左排列的。这些都容易是UI出问题。发现问题之后,有些可以通过精简文案解决,有些则需要优化UI设计。如果是通过精简文案结局问题的,需要将文案的变化同步到Sheet中。

7、增量更新

一个应用发布之后,会继续发布很多新版本。在每个新版本中,有新增的文案,就必须重复上述步骤,确保增量内容遗漏。