我的产品坑，你要填？ （顺带说说消息推送）

我在看书，认真的在看

    【这里没有碎碎念】你看的多，还不如做，你爽了，它也舒服了            ——周先森

消息推送系统从确定需求到开发花掉了接近一周的时间，消息推送系统不复杂，一套系统出来还是吸收到很多东西。

在需求确定、需求评审、测试、上线反馈（主要针对后台）的点上来一些反思总结，目的在于希望自己以后不要踩这些坑，也同样希望和大家一起进步。

懒跌看详细内容的，可以直接看总结要点：

1.需求确定：沟通！沟通！沟通！跟业务方一定不能用产品专业术语，当需求方不止一个的时候，这时候特别注意要兼顾双方的需求，同时以双方的目的为出发点

2.需求评审：拒绝！拒绝！拒绝！每当需求评审的时候，开发人员会从这个功能上考虑可不可以做？你的出发点是为什么做？（一定记住）。所以往往就会出现一种情况——开发想得多。当然开发人员是为业务方好，但是在业务方的流程上就行不通的地方，开发程序开发出来只会造成业务方的逻辑混淆与操作习惯。所以在需求评审的时候，当开发方说为了防止万一什么什么发生的时候，一定要冷静分析。这个是一定存在？在业务流程上一定要做？

3.测试：测试环境测试（通常ui界面）、预生产环境测试（功能测试、接口测试）。有时候也是同时进行的，讲细点：在ui测试上一定要和原型一致（不要考虑太多，不然需求评审有何用？不对的地方需求评审就应该提出来）。功能测试、接口测试：在功能测试上你只需要考虑功能是否能满足需求确定的时候的需求目的，是否符合需求方的操作习惯与业务流程；在接口测试上（我认为重点），这个数据走向，列表显示的字段这个是需要确认确认确认清楚，这个错了，一切都完了。特别主要当两个系统或者多个系统数据共用的时候要清楚共用的原因。

4.上线反馈：多说一点，上线之前一定要见测试报告，测试报告有了之后才准上线。上线后给需求方看，这时候如果是多个业务方就会有不同意见，你要去权衡（通常从开发周期、需求价值），没有一步就做到位的，需要优化就要放在后期优化，不是去改现在开发完的需求！记住

---

说消息系统（前端讲多点，后台少点，没有原因）

前端：

平台：iOS、Android

推送方式：通知栏推送、弹窗推送（正在使用应用）

显示样式：

iOS通知栏样式：logo+名称+消息内容 Android通知栏显示样式：平台logo+消息标题+消息内容

推送机制：iOS通过苹果自己官方推送给用户；Android是通过自己长链接推送给用户。这是根本区别，所以在通知栏获取消息的时间是不一样的。同样在消息列表就会出现异步的问题（iOS）所在在前端的消息列表当中两个平台获取消息的方式是不一样的。这个要注意

前端流程：

虽然很粗糙，但是很实在（原型截图）

后台：

太多，人懒，可以语音就好了！烦请【简书】开通这个功能，

想一起探讨的朋友可以留言。