前言：
为优化移动开发技术小组的开发流程及效率，根据当前现状，制定开发流程规范，以达到明确职责，提高效率的目的。
App项目现状
1.逻辑细节不明确。
2.UED保真度不高。
3.口述需求后即进入开发环节，导致开发周期显示较长。
4.App整体满意度不高。
研发流程现状
1.逻辑不清晰，无PRD文档，在研发中耗费较多精力在逻辑讨论上，思路总是会被打断。
2.文案不清晰，无PRD文档，导致iOS和Android两端文案展示不统一。
具体现状：
1.只有原型，无PRD文档
2.文案和业务、交互逻辑缺失。
3.没有确认产品文档最终稿确认时间点。
4.无明确连续2个时间段的迭代计划。
5.开发中需求变更频繁，或有新增需求。
3.UED不细致，标注说明不够详细，研发细节差异较大，UED保真度不高。
具体现状：
1.UED保真度不高。
2.开发过程中需要UED不断跟进，耗费UED人力。
4.研发内部缺少评审环节，导致逻辑不清晰，不利于团队维护和技术能力提升。
具体现状：
1.缺少评审环节，项目安全性和规范性不高。
2.缺少代码评审，项目逻辑性不够明确。
3.团队其他成员不了解项目，不利于维护和共享。
5.研发内部缺少交叉自测环节，iOS和Android太过分离，统一性不高，质量不高。
具体现状：
1.提测后，研发等候时等待测试反馈。
2.提测后，研发内部没有自检。
6.没有总结，无法根据实际情况分析进行改进，团队效率无法提高。
具体现状：
1.上线之后，研发并没有对项目进行总结。
2.上线之后，研发并没有提出问题点以及相关优化建议，不利于项目长期发展。
7.无明确制定研发流程，职责不明确，流程问题点无法定位，团队效率无法提高。
具体现状：
1.无研发流程规范。
2.其他团队成员不知悉项目开发流程。
依据以上现状，现移动端技术管理中心制定App研发流程，请项目所有涉及人员遵守支持，以达到互不推脱，明确职责，互相监督、互相促进，共同提高团队效率。
App正常规范流程图
App研发正常流程规范
- 产品评审
产品负责人发起会议
1.评审时间
产品迭代前，产品负责人把控具体时机
2.参与人员
产品、各端研发负责人、设计相关负责人
3.评审内容
1）要求产品人员需求评审前必备：原型，PRD文档。
2）要求PRD文档：文案、逻辑注明明确。
4.评审会输出
1）输出评审最终稿，文案和逻辑注明明确，产品研发同时能够理解和知晓。
2）设计评估出相应的设计工作时长。
注：
1）开发需求中若变更以及新增需求，需重新评审以及评估延期时间。（研发也以此考核产品人员，并记录反馈，分析优化。）
2）输出评审时长和评审次数，以此来评定PRD文档输出的细致性。
3）明确产品PRD文档输出时间点
2. UED
1. 内部流程
用户研究 -> 交互设计 -> 视觉设计 -> 产品确认
2. 参与人员
产品、UED相关人员
3. 开始设计
4.输出
1）交互设计方案和说明。
2）视觉设计方案、标注、切图。
3.需求讲解
产品负责人发起
1.发起时间
迭代上线后的某天。
2. 参与人员
项目所有人
3.讲解内容
1）原型、PRD文档
2）交互设计说明和方案
3）视觉设计方案、标注和切图
4.产品研发
1.接口评审
1）根据需求和设计图，要求的相关接口信息。
2）根据优先级，讨论好主要接口的约定字段，并录入femock。
3）研发相关人员参加
2.研发概要设计
1）开发前必须经过团队设计思想、开发思路评审。
2）在开发起始节点的第一天发起。
3）各端负责人发起，全员参加。
4）输出：设计评审文档以及逻辑流程图。
3.编码实现
4.代码审核
1）参考设计评审的思路，进行代码校验。
2）各端负责人发起，全员参加。
5.产品测试。
1）iOS与android位置互换，交叉测试，保证双方开发功能点的统一性。
2）bug修改。
3）测试进行全面测试。
6.产品上线
1.上线邮件
1）注明需求讲解的时间结点。
2）注明研发时长。
3）注明测试时长。
4）注明Bug数。
5）注明本期干扰正常开发的问题点。
6）注明本期项目重构优化的功能以及优越性。
7.定期上线总结会。
有产品定期发起会议总结
1）软件的反馈和运营状况。
2）当前的发展防线。
3）迭代过程的问题总结。
4）问题避免和改进。
以上是移动端技术管理中心暂定的流程规范，在实施过程中，根据具体的实施流程以及发现的问题，经讨论后可随时做优化改进。规范的流程和高效的团队合作，离不开大家的大力支持。请大家多多参与并给出宝贵建议。
App研发特批流程规范
因特殊原因，基于现有需求直接指定上线时间的项目，采取反推方式。
1）了解需求背景粗略评估测试时间
2）研发粗略评估研发时间
3）ued粗略评估时间
4）剩余时间产品快速规划、制定原型、需求讲解
注：评估时间占比 测试30%以内 研发40%以内 ued20%以内 产品10%左右
FAQ
- 谁负责研发流程的时间、节奏把控？
答：产品负责人。产品负责人把需求规划的越早，产品评审提前的越早，越有利于所有人员的充分利用。
例：按照流程执行的前提，如果产品评审在开发上线后进行，则评审和UED时间将会使研发人员和测试人员时间安排不饱和。同时，迭代上线周期过长。
通过预估UED时间，提早安排评审，进行设计，在开发上线后的接着进行需求讲解，会达到所有人员的工作最大饱和度。同时缩短整个迭代的上线时间。 - 需求讲解后，开发人员以什么为标准去开发？
答：文案、逻辑、页面跳转，以PRD文档为准。
UI、交互体验以交互方案、设计标注为准。
交互、设计标注需在UED阶段，有产品确认，并有产品保证原型和UED的统一性。 - 开发过程中，产品需求发生变更，如何解决？
答：如果产品需求发生变更，则根据变更内容进行预估，如果半天内能解决的，加入本次开发进行变更。
如果需1天以上解决的，则根据安排，决定是否延迟上线时间或将需求推迟下期上线进行安排。
变更需更新PRD文档，给出变更原因和变更记录，根据变更内容决定口头下发还是开会下发给研发、测试人员。 - 不同部门提出的需求，谁负责下发？
答：如设计部门，运营部门提出需求后，需统一由产品整理，再反馈到相应部门做确认，再有产品按流程进行下发。 - 需求讲解流程是什么？
答：第一步：说明需求背景，为什么做该需求。
第二步：说明需求实现，该需求如何做。。
第三步：如果需求实现没有整理清晰，需说明并告知先做成什么程度。
第四步：说明需求未来的可能性改动。 - 需求讲解的时机？
答：讲解时机：上午或下班后。
讲解前准备：需提前一天发出邮件说明PRD和设计稿给所有人，供提前预习，以便讲解时及时做反馈。 - PRD文档中，研发需要产品做什么？
答：1.注明功能逻辑，条件判断。
2.发起页面展示的来源、返回到哪个页面等交互。
3.给出网络提示异常文案，不符合条件的异常文案，空数据展示文案，页面默认展示文案等。 - App需求概要设计，都设计什么？
答：1. 概要设计以需求功能点划分，具体分为页面+逻辑。
2. 页面的组成方式。
3. 逻辑的实现过程和判断逻辑，以及页面间传输数据约定字段，以及异常的处理过程。 - 研发需求如何加入产品需求？
答：1.建立研发内部优化需求池。
2.研发期间内部安排时间计划。
3.研发、测试期间，建立代码分支进行优化，优化完成并自测后，提到下期产品需求中，方便测试。 - 何时给出评估具体时间。
答：概要设计后，根据概要实际内容进行评估。 - 何时讲解Checklist？
答：上午或者下班后。