海外的项目接近尾声，MM上Beta已经发布半个月了，一直想捋一捋想法列一下遇到的坑。

先从四个部分来说吧，定位の坑、设计の坑、开发中の坑、发布の坑。

定位の坑

其实一开始海外的定位想打的是小、轻、快、管理、隐私，因为考虑到一点是android原生系统在文件管理这方面不是特别好用，还有一点是海外用户比较看重隐私这块，以及说竞品打了小、轻、快、安全等等的点，希望在定位上能够更偏向功能一些，或许能有出路。

但是一方面从海外的APP排名以及DU方面给的反馈来看，隐私和管理貌似并不是海外用户特别刚需的点，并且在V1.0的时候打这两点，一是不于传播，二是发展空间有限，三是可能做不过别人。

所以开了一次会之后，大人觉得应该拿我们现有的、擅长的、别人没有的点来做。

动态。

于是产品的大框架定了下来，小轻快动态。

动态这个点，是因为我们现在国内正在做动态壁纸相关的内容，已经有比较成熟的技术支持，较为擅长。

产品定位定下来了，产品都做出来了，但是在发布的前夕，写汇报PPT的时候，要定位目标用户，然而并没有很明晰。

因为布的局比较大，第一个版本就支撑了多语言，每个语言之间的代表性国家启示还是有较大的差异性，所以最后定的目标用户是对手机桌面小轻快有需求的，喜欢轻度美化手机的，喜欢动态壁纸的人。

除了用户定位不够清晰之外，连slogan都纠结了好多个版本，运营那边给到的slogan实在是太像卖手机和卖车的了，格局太小，最后定的这个sloan，只能说是中规中矩并没有什么太大的新意。

在定义slogan的时候，因为是海外的产品，所以研究出最好的做法是直接用英文来定义slogan，再意译成中文。因为中文文字的弹性和表达的空间都更多更美。

设计の坑

设计的坑想从两个方面讲，一个是产品方面的，一个是视觉方面的。

产品方面的，因为是第一个产品，其实从一开始就没有想太清楚要做成什么样，加上人微言轻，所以最后大方向定的还是往动态走，但是还是希望保留了国内的接入内容的形态，让整个产品显得更丰满一些。

然而。

并没有内容源。

整个开发的过程就是一直在妥协的过程：

1、首先是有很多内容源都没有覆盖全语种，导致开发的过程中一边开发一边砍功能，很多功能都delay了。当然这个问题回想起来在当时的情况来看的确是没有办法避免的，除非能够做到首发的时候只做一两个语种，不然本身是小渠道，一方面人家也不愿意在你都没量的时候投，另一方面能够支撑全语种的资源的确是很少有人在做。

2、第二是功能设计上的，因为我自己本身的目标定位很模糊，所以在写方案的时候存在很多立场不坚定的地方。而且其实我有个很不好的习惯是，凭直觉去画原型，没有想好充足的理由为什么这么做，所以很容易被驳回需求，也很容易修改需求。目前正在努力改正这一点。

3、第三点也还是和我自己有关，对产品没有一个宏观上的把控，太容易纠结细节了。

譬如动效，有很多需求没有经过严格的评估就做了，后期就会出现蛮多耗费RD工作量的问题。

一开始因为项目组都没有人有经验，没有对动效做把控，没有系统的边框去限制什么做什么不做，只在动效开始前圈定了三个大概方向，导致动效那边放开了手做，的确是在细节上优化了许多体验，但随之带来的问题是在V1.0的开发过程中耗费了太多的时间去投入在应该是在V2.0之后才需要深度优化的内容。

另一点，因为觉得动效的视觉创意很好，导致有个核心功能是为了动效而动效，其结果是背离了这个功能存在的初始原因，不仅没有达到功能的目的，反倒还增加了内存损耗。

针对这点的感悟是，一个合格的PM，至少对每个版本都应该清楚，我这个版本要做的是满足基本功能，还是说去继续深化体验。把握做与不做的度是很重要的！

觉得最近自己有提升，因为最近接手新项目的动效审核模块，已经圈定好了先从感知度高、能够规范APP的整体操作体验、增强交互感知这三个方面的动效开始做起，后续版本迭代再来深度优化delay的功能。

开发中の坑

时间才过去了一两个月，感觉记忆都模糊了，只能凭借现在的印象来列一列开发过程中遇到的坑。

1、首先是时间。

开发的时间永远是不够的，就如同画原型写案子的时间永远是不够的一样。每个版本计划里总是有那么些会被delay的功能。

所以在排版本优先级的时候，千万！！千万不要去抠细节！先把功能的优先级列出来，某些虽然体验差了点，但功能是完善的，那先上再说，不要被处女座的完美主义坑死，因为永远不会有完美的产品，就像不会有完美的案子。

2、跨项目组合作。

跨项目组合作一直是一个很大的问题，特别是当你的产品的核心亮点是控制在另一个项目组手里，并且那个项目组不大容易沟通的时候，这个时候千万要小心。

我因为too young to native，默认UI接入动态壁纸的时候，因为不想被对方限制，所以一直想自己胁迫UED用编辑器解决默认动态壁纸的问题，然而果然失败了，并且拖了大约三周～一个月的时间才找领导聊，发布时间险些受到影响。

跨项目合作的时候我们遇到了这几个问题：1、对方项目组内RD之间的关系并不和谐，导致同一个功能两个形态分两个人开发，实现的形式迥然不同，我方RD不仅要协调两个RD之间的关系，还特么要调整实现方式。2、时间点受限。对方RD-A是个很有时间观念的人，所以很快就配合我们接入了，但RD-B是个很难沟通的人，时间观念不强，导致我方接入效果的时间一直往后拖延，最后不得已砍掉了由B开发的功能。3、接入后，有不可控制的bug和崩溃情况，并且对方对自己的技术十分有信心，排查之后认定是我方接入形式有问题，但截至今日（2015/08/29）并没有找到崩溃原因。

所以针对跨项目组合作这件事情，还是需要有两个注意点。1、尽量不要把核心的东西放到别人项目组去，以免受限制。2、对时间的监管不严，一方面是项管没有发挥作用，另一方面是不要觉得自己什么都能搞得定，如果对方项目delay超过一周，那就要重新评估一下接入价值。

3、找不到内容源。

废了九牛二虎之力开发出来的功能因为没有内容源而被屏蔽了，即浪费了时间，功能上又不完善。

所以在确定功能开发前，最好先确定内容源。

发布の坑

说到发布的坑，不得不提提MM和GP两个渠道的事情。

MM上的问题还是两个，一个是上文写到的跨部门合作结果被坑的事情，另一个是留存的问题。

留存的问题，目前做法是列出觉得可能影响留存的原因，每周发一个包来验证。另外还学会了一门技能，就是把后台的用户数据导出来，根据IMEI来判断唯一性，然后以他一周为单位，来看他每个时间段做了什么操作。虽然目前还没有什么成体系的发现，但也很努力在尝试。

GP上的问题主要还是政策性的。

国外的官方市场和国内不一样，是非常敏感多疑的。

我们第一次上架就被下架了，理由是我们打了个点，想知道用户安装了什么应用。但谷歌爹觉得这是伤害到用户行为的（没错都怪RD），所以被下架了。

改完上架了第二次，又被下架了，理由是我们某个功能里，提示用户保存了邮箱，但没有告诉用户我们用来做什么，也没有让他有确认的机会。

于是我们在他点击保存的时候给了个提示框，后续在新手页面增加了用户条款里面有注明这点。

改完了上架了第三次，又被下架了，直接被封了包名，理由是违反了开发者内容政策。给谷歌发邮件问也不回我们，纠结了大概半个月，换了包名，期间还影响到了接入的其他项目组的功能，导致循环崩溃了。

后来千方百计打听到说，如果APP里面有第三方推荐应用的链接，必须要打上AD的角标，不然就视为想自己做一个应用商店，就是违规。

于是我们把第三方的链接拿掉了，平安上架。

总结

目前进军海外GOGOGOGO遇到的问题就是这些了，还在努力地和留存做抗争，有什么新进展会继续更新在这里的。