大数据开发注意事项

• 需求评审完成后，如果发生需求变更或者迭代，一定需要提供迭代/变更的需求申请单，或者提供JIRA，避免需求不可追溯。

• 对于一些重要指标的定义，就算文档中写了，也要和产品进行确定，例如产品需要近半年的所有销量，那么要明确这个销量是否包含退款、是按照成交时间还是付款时间来计算等等。避免数据指标不匹配，导致二次开发。
• 开发过程中，文档要规范，先设计在开发，而且在做系统建设的时候，要有全局视野，不局限某一个点，并不是发布完成了，就算结束，代码开发完成只是第一步，后续的文档建设、代码复盘、数据监控、数据告警、稳定性等等，都需要在开始规划好。
• 及时反馈，在开发过程，不论进行到哪个阶段，项目期间每天都需要和前后端同步一下进度，避免延期的风险。
• 故障处理，在程序上下后，可能会因为客观或者代码的原因出现一些BUG，不同的故障处理方案不同，但是注意复盘和故障记录，避免下次出现相同的BUG。

故障等级定义：

P0 ：
1.全局问题，影响所有用户，例如系统必现崩溃，主要功能不可用，严重影响用户正常交易。
2.涉及到用户资金损失的问题。
解决时间：2小时内。
反馈时间：0.5小时。
反馈方式：comments自动邮件方式+即时通信：例如QQ\微信\钉钉\电话

P1：
1.全局问题，影响所有用户，例如系统次要功能不可用，系统偶现崩溃且崩溃率超过50%。
2.局部问题，影响超过20%的用户，例如系统主要功能不可用，系统必现崩溃。解决时间：待定不过夜。
反馈时间：1小时。
反馈方式：comments自动邮件方式+即时通信：例如QQ\微信\钉钉\电话

P2：
1.局部问题，影响用户10%-20%，例如系统次要功能不可用，或者系统某一个逻辑不可用，系统崩溃率20-50%。
解决时间：待定48小时。
反馈方式：comments自动邮件方式。

P3：
1.局部问题，影响用户10%以下，例如系统次要功能不可用，系统部分逻辑不正常，仅在某一单一机型或单一用户出现的问题。
解决时间：待定下个版本发布。
反馈方式：下个版本的需求计划中体现。

P4：
1.系统文本错误，系统样式错误，系统交互友好性等不影响用户正常使用的功能。（包含全局性质）
解决时间：下个版本上线时。
反馈方式：下个版本的需求计划中体现。

注意：P0\P1级别问题在规定时间内无法解决的，需要该问题的研发同学在问题comments内说明无法在规定时间内解决的合理的解释，并告知该问题具体的解决时间点同时邮件说明。