看完你也能独立负责项目！APP从头到尾的所有工作流程详解！

4.1，apk、api文件的命名规范和不同类型安装包的管理：

这里全是我个人的经验，做好这些，会对以后安装包的管理会有极大的帮助。我们当时把搭建了一个开发者环境，这个环境下的APK、API文件只能在局域网类使用，在这个环境下可以任意折腾和测试，不会影响到已经上线的应用。

开发者环境下打包的安装包图标和命名要和线上环境下的应用区别开。以后在续测试时就不会因为各个版本搞的手忙脚乱。

4.2APK、API文件管理

4.2.1开发版：纯开发自己使用或者产品使用，其他无关人员一般情况下不会接触到这个版本。网络环境：仅特定网络环境下使用（需要技术人员搭建环境）。

4.2.2公测版：经过产品和测试人员的详细测试后，基本没有什么BUG了，就可以拿出来给公司的人使用，也算是上线前的稳定性测试。网络环境：仅在特定环境下可以使用（需要技术搭建环境）。

4.2.3商店版：准备提交到市场的APK、API文件。在经过开发版本、公测版的全面测试后，排除一切不稳定bug，此时打包的商店版仍然需要经测试人员的最后把关，最后一定要保证的是，准备上线的APK、API文件是经过测试人员的最后把关的，否则如果开发如果做了改动不通知测试和产品人员，上线后出了问题再改就晚了。

五、APP测试和版本号管理

版本好号的管理，前期就要搞清楚，否则后面产品上线后，出现bug要改进，或者添加新功能后对老版本是否有影响，这个时候版本号管理的好就会起到很大的作用，一方面你可以随时找出之前上线过的apk、API文件，另一方面面对不断修改打包的文件不至于把自己搞混。

下面是我个人的意见，如哪个大牛有好方法可以分享出来。版本号始终是唯一的，是依次迭代递进的，不要为了上线时版本号好看就去刻意干扰版本号，严禁搞多套版本号。

测试须知：

UI、交互、产品在技术人员开发阶段，要多和技术人员沟通，最好是将大功能细化成小功能模块，每次做好一部分就通知相关的人进行检查，以免累计到最后问题过多修改动作太大。UI负责盯着开发是否按照自己的设计实现的，交互负责关注交互效果是否符合你的标准，产品负责关注各个功能的实现是否正确。

测试用例：好的测试用例能够有效的推进测试的进程，好的测试用例在于尽可能的把APP的各种需要测试的情况用人话描述清楚，这点就看你的文字能力了，测试用例写出来会交给测试人员来测，这也是他们评判APP是否达标的标准。

Bug管理工具：bugtags,bugclose等等，市面上有很多，多是免费的，即使是收费也不要在意那么点钱，借助bug管理工具能够有效的提高测试人员和技术人员的协作效率。

（三）项目上线后

之前给大家介绍了两个部分，项目启动前和项目执行中。项目上线后，作为产品需要关注的事情有几个方面，一是APP数据，二是用户反馈，三是需求提取。

一、APP数据

新增用户：第一次启动应用的用户；

新增独立用户：全体应用的新增用户的总和（去重）

活跃用户：当天启动一次的用户即为活跃用户，含新用户和老用户；

活跃独立用户：当天应用的活跃用户总和（去重）

MAU：MAU（monthly active users）月活跃用户人数。

DAU:DAU(Daily Active User)日活跃用户数量。常用于反映网站、互联网应用或网络游戏的运营情况。

用户留存率：在互联网行业中，用户在某段时间内开始使用应用，经过一段时间后，仍然继续使用该应用的用户，被认作是留存用户。这部分用户占当时新增用户的比例即是留存率，会按照每隔1单位时间（例日、周、月）来进行统计。

用户留存率中的40-20-10法则：如果你想让游戏、应用的DAU超过100万，那么日留存率应该大于40%，周留存率和月留存率分别大于20%和10%。

次日留存率：（当天新增的用户中，在往后的第1天还活跃的用户数）/第一天新增总用户数；

第2日留存率：（第一天新增用户中，在往后的第2天还有活跃的用户数）/第一天新增总用户数；

第7日留存率：（第一天新增的用户中，在往后的第7天还有活跃的用户数）/第一天新增总用户数；

第30日留存率：（第一天新增的用户中，在往后的第30天还有活跃的用户数）/第一天新增总用户数。

另外就是APP的埋点数据，这个功能的点击率是多少？这个功能有多少人打开，又有多少人使用了？有多少人在频繁使用这个功能？等等，这些埋点数据要时常关注。结合数据变化来反思功能设计的问题，从而优化产品。

二、用户反馈和评论

产品上线后，用户的反馈和评论对于产品人员来讲是尤为珍贵的材料，一方面这是你的真实用户的直观感受，另一方面他们再表达直接的需求。那么，怎么样处理用户的意见就显得格外重要。用户反馈什么我们就做什么，这是肯定不行的。很多情况下用户表达的只是一种表面现象，要学会去挖掘用户背后的需求本质。多去研究世界上一些革命性的产品，多去了解人。

当看到四处飞来的意见时，我们要学会思考，而不是全盘接受、全盘照抄。

是不是我们的目标？想想我们的目标用户是谁。

使用场景是否成立？还是这只是极个别人的场景需求。

用户目标是否正确？我们的APP是不是用来满足用户这个需求的？

产品定位还正确吗？如果做了这个功能，还符合我们产品的定位吗？

如果要做这个功能，那么自身的项目资源是否能够满足？如果需要举全部资源来做这件事情，那就要慎重再慎重。

三、需求提取

也许用户的意见是个圆形，但经过分析之后，很有可能得到需求是个三角形。

“如果我最初问消费者他们想要什么，他们应该是会告诉我，‘要一匹更快的马！’”

——这是亨利·福特的一句经典名言，如今我们在《乔布斯传》里又见到了它。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!