APP标准研发流程

需求产出

策划的需求有几方面的来源：

• 绩效目标。比如在每个季度或者半年度开始的时候制定的目标。
• 线上用户客诉反馈。
• 近期数据表现，如某个功能数据下滑明显，则会进行专项迭代优化。
• 竞品研究。

需求内审

策划在正式将需求提交给研发之前，会在策划团队内部进行评审。策划团队人数多了后，也会进行分工，比如有负责营收的、有负责用户增长的、有负责商业化的等等，所以在将需求提交给研发团队前，有必要内部进行沟通对齐，毕竟所有需求上线后都在同一个App中，必然会有功能冲突的地方，策划之间有时并不清楚互相在做什么需求。这里也建议邀请研发参与，识别需求的技术可行性，或者有没有其他更好的方案，一般只要邀请一线研发负责人参与就可以了。

需求评审前的准备工作

最开始的时候，在需求评审前，研发并不需要做什么准备工作，但从实践经验可以得知，需求评审并不高效：

• 最开始研发、QA、视觉全员参与，但随着项目人员越来越多效率越来越低下，目前已经进化为研发组长全程参与，和需求相关的研发、QA、视觉参与。
• 有好几次评审了10小时+
• 经过评审的需求，最终并不一定会排上，因为研发资源有限，最终策划会根据优先级，对部分需求进行改动和下车的情况屡见不鲜，浪费了很多时间和精力。

经过不断的总结复盘，在需求评审评审前，需要：

• 策划需要将所有需求填写在Wiki表格中，并标明全局唯一优先级。
• 研发侧在需求评审前，大前端和服务端一起商定需求的技术负责人、研发人员，研发人员对需求进行粗略估时。
• 研发侧按优先级统计估时，根据研发人员的人力时间，这样可以大致确定可以评审到哪个需求为止。
• 策划和PM根据研发给出的结论，对需求调整后，再开始需求评审。一般会选择多评审些需求。所有需求评审完后，策划再全局调整。

需求评审

在需求评审时，需求相关的研发、QA、视觉等人员会对需求提出疑问，有些问题策划能当场给出答复，但还有很多问题当场是给不出来的，所以在需求评审时，需要：

• 专人记录评审问题，主要是一些外部依赖、需求改动点、策划当场未给出结论的问题等。
• 会后需求负责人及时跟进上述评审问题。

需求排期前

需求确认完后，还需要排期，排期是指给所有参与本次迭代的研发安排一个合理的开发时间，需求本身之间有关联性，研发也有互相依赖，比如服务端的提测时间要早于大前端等等。为了提高需求排期的效率，在排期前需要：

• PM确定版本时间周期；策划向外部依赖团队确认所有依赖需求确保可在迭代周期中排入；PM和视觉团队确认所有视觉稿在研发开始前交付。
• 研发侧，确定每个需求的技术负责人；项目技术负责人在项目管理平台上面创建迭代版本，并完成JIRA拆单；端组长拆解需求任务并录入项目管理平台。

需求排期

在需求排期时，也不用全员参与，排期的主要目的是确认最终有哪些需求能正式排入迭代开发，只要相关负责人在场就可以：

• 项目技术负责人、QA负责人、每个端组长、大前端组长共同参与排期。
• 如果是分批提测，由需要调整需求开发时间，目标是所有需求都是服务端早于大前端提测。另外，项目管理平台的功能也非常重要，如果这是靠人肉来核对确认的，则效率会非常低。
• 如果是整体提测，则问题相对来说比较少，但同时会带来其他问题，比如客户端是否还能分开发版等等。

技术方案设计及评审

在开始研发前，需要进行方案设计，这是一个比较好的流程规范，这个时间投入（一般花费两天时间）是非常值得的。需求的技术方案由需求技术负责人负责，需求技术负责人可以是服务端开发也可以是大前端开发，他需要设计并确认整个方案，并将方案同步到需求相关人员。方案设计完后，还要召集大家进行方案评审，大家可以对方案进行再次讨论。

视觉评审

视觉稿最好是和需求稿一起给出，这样在需求评审时，相当于也进行了视觉稿评审，就不用单独再拉视觉评审会议了。

如果视觉稿在需求评审后再给出，问题比较多，比如研发之前的估时就可能会不准确，特别是像动效这种需求，不同动效研发成本相差比较大。另外还要单独再召集大家对视觉稿进行评审，加重了流程复杂度，引起了更多问题。

研发

进入研发后，基本上只能按排期时给的估时来追赶进度了，如果估时不准确，则首先是靠研发自己解决，比如加班。如果是单纯的靠加班能解决也是万幸的，怕的就是需求本身理解有误、有遗漏或者是有变更，这种比较折磨人。所以，研发对估时一定要尽可能准确，估时一定得是需求的一线研发给出的，然后根据以往经验再乘以一个系数，因为开发人员除了完成需求外，还有很多的事情，比如会议、培训、请假等等，有些还是突发性的，所以要预留好时间。还有一些需要注意的：

• 不要擅自接私活，特别是变更类需求，要将问题上升到项目团队。
• 如果遇到了风险，需求技术负责人要将风险及时抛出来，将问题汇报给主管。
• 每天下班前，将需求进度填入进度表格。

提测

完成研发后，就可以提测了，提测前要通过冒烟，然后按照项目管理平台的要求进行提测即可。

灰度

APP不像Web产品，一旦发布就无法收回了，所以灰度发布对于APP来说是必需的流程。灰度需要有专门的平台支撑，可以先灰度5%，观察APP的崩溃率及一些性能数据，如果有问题就及时停止灰度，让研发修复问题，如果没问题，就加大灰度比例直到全量发布。

发布

如果灰度期间没有发现异常，那就可以将安卓应用市场中的渠道包进行替换（iOS就走苹果的提审流程），至此，新版本App正式上线。

线上版本修复

不管经过多么严格的测试，出问题总是难免的，如果是服务端问题，那修复后上线即可，这里主要是讨论客户端版本的修复流程。有些不紧急的线上问题，可以排到下个版本来修复，如果评估后需要紧急修复，那需要让研发修复问题，然后重新走灰度和发布的流程。

但实际上，客户端的有些问题是挺难排查的，可能日志也很缺乏，需要先收集日志才能排查定位问题。发生问题的用户挨个去联系也不现实，成本太高。此时可以先埋入日志代码，然后找个小的渠道将修复包替换上去，然后再观察日志数据后做下一步判断。

关于APP的研发流程就先介绍到这里，本文描述的流程很多是和项目团队、公司基建等等相关的，仅供参考。