原文：APP标准研发流程梳理
APP研发管理是我这两年的工作重心，不久将挑战下个职业阶段，在此前对它再做一次梳理做个强化
核心思路：根据团队的结构，制定流程的执行标准，并根据团队变化及时调整，同时保留一定的灵活性，在红线以外应当给足各直接参与者自主抉择的权利。
绝大多数软件研发都要经历产品设计、研发、测试、发布这四个阶段。这是研发流程的骨架，需要配合设计执行阶段的流程标准，制定各阶段的衔接标准，才能让整个产研流程顺畅的运转，就像一个大型机械中的大齿轮与小齿轮的关系，任何一个环节阻塞低效，都会直接拖累产研这台大机械的运转效率。
APP 研发过程存在它自身的特殊性，针对这些特殊性的细节把握如同给齿轮打润滑油，非常重要。
处理需求来源：
-
产品部需求
-
运营部需求
-
客服部需求
-
技术迭代需求
-
APM收集的问题
-
上级、老板需求
一则产研流程既要保持一定的灵活性，也要保护一线员工的工作少受干扰。授予一线成员直接拒绝需求的权利，同时规定临时需求估时超过2小时的不允许接，引导至直接主管对接。通常他们都有明确的排期，再加上对优先级判断的信息不足，“帮个小忙”往往会严重影响他们本身的工作进度，或者造成不必要的工作负荷。
第二个是需求上游不一定能准确识别需求的紧急程度，汇总之后需要从全局审视优先级再行审视，优先级判断不足的辅助快速上升获取资源。有时他们提的不是需求而是一个解决方案，比如加个按钮加个提示，这些都需要引导至对应产品接收。
需求内审：
不管是产品部，技术中台，运营团队提交给研发的需求都要进行内审。从自身需求目标出发，与需求涉及其他业务功能负责人或团队进行对齐信息，一是把关功能设计是否可行，二是合并版本。比如订单侧要新增需求要与商品、财务、仓库等上下游团队对齐，数据埋点需求要适应新业务变动，尽量跟随需求同期上线。
需求初审：
最开始收到需求后，会马上拉群组织需求评审，测试、研发、UI设计等项目成员一起参与。随着项目变大，人员大增，有的需求评审就需要十多个小时，评审可能会导致需求做较大调整，还需要重复评审，在正式投入前消耗较多时间。
经过不断的总结复盘，建立了初审环节，降低正式评审时的工作量：
- 产品需要提供整个团队的需求清单与全局唯一优先级
- 正式评审前组织大前端、后端小组长评估大体上的技术方案，过滤大部分存在风险或不合理的需求设计，产品会后重新设计
- 方案确认后各小组长粗略评估工时，结合优先级，确认本次可评审的范围，是否做版本拆分
需求评审：
此环节的关注点：提高会议质量，降低不必要的人力消耗
- 在会议开始前，大需求最少提前2天将需求文档等资料发至项目组成员
- 对需求文档中发现的问题与疑问优先在文档上评论，未解决的在会上按需求讲解顺序提问，避免开大锅会
- 会议过程中提出的未确认的问题，产品记录会议纪要，会后同步至项目大群，与之后的项目问题统一进行状态更新维护
- 针对部分参与人员涉及的模块足够独立，上下游依赖程度低，可在会前定好可只参与相关部分时段
- 产品要先负责UI设计的审阅，确认过后再交给研发。UI设计稿最好是在需求评审时一并提供，研发评估需求会更准确
技术评审：
这部分通常会花1-2天的时间，但不是必须的。
这里尤其要注意的是部分团队首次合作时要做好通用的技术方案设计，比如后端有C，PHP，GO，JAVA等不同的服务，但前端开发需要促进统一的接口交互规范：
- 要准备的服务器环境，测试环境、预发环境、生产环境
- 接口API规范、接口文档规范、接口通用根数据模型、兼顾强类型与弱类型的字段类型设计
- 后端开发要接口先行，针对新增接口，要做进行接口评审，避免造成瀑布式开发
预估工时：
仅拿APP来看，即使是能力不错的核心业务负责人，也容易出现工时预估准确度的问题。尤其是前端多少存在面向UI开发的固化思维，往往是越熟悉的模块估时越是过于乐观，造成进度风险。
所以在APP侧我们要求：
- 估时以是谁负责谁估时为准
- 预估工时前要梳理开发计划RoadMap，涉及老代码要具体到类与接口。（这一步是为了将熟悉代码，梳理代码结构的时间前置，提供估时的准确度）
- 根据工时模版表，将UI开发与联调任务计数与估时分开（表格将自动算估时情况，计算各模块实际进度）
- 各端小组长审核估时，通常是在总估时的基础上根据难度系数的判断乘一个系数
项目排期：
这一步的核心是作为项目负责人要统筹协调各端的开发联调时间节点，根据项目实际情况确定各模块是一起提测还是分阶段提测，确认提测时间、提测顺序的安排。
研发：
- 每天在项目管理平台更新任务进度，填写工时消耗
- 碰到项目问题要及时抛出到大群，并@直接主管与项目负责人，避免单聊导致问题处理滞后
- 开发不可以擅自接私活或私下需求变更任务，要上升到项目团队
- 提测包由CI自动构建，避免绕过代码审查，lint检查等安全措施
冒烟：
此部分完全由测试主导，把控冒烟是否要求开发到场协助，是否可以分批冒烟。针对特殊项目情况，调整冒烟颗粒度
- 硬性制度：冒烟不通过将面临严重的绩效惩罚
提测：
测试过程要求：
- Bug重复扭转时未解须写明原因
- 影响流程的Bug开发必须日清，无法完成则需要上升到项目团队
- 测试每日在大群汇报测试进度，是否面临阻塞问题，对后续测试工作的影响说明
- 尤其要注意版本更新兼容性测试，此功能一坏对APP来说就是灭顶之灾
上线：
APP的上线过程要保证版本信息与安装包的安全高效的传递，要保证测试做正式验收的包传递到运营小伙伴时中间要线上全自动化，不能有人为参。 由产品发起简道云APP上线流程，填写发布版本与渠道等信息。流程将经过测试正式验收，运营上架市场，关键节点将会自动通过企业IM同步至相关负责人。
针对体量大的APP通常都需要先走灰度观察APM情况，用户数据情况，没有异常再进行全量发布。面对异常要先发布回滚版本覆盖灰度的用户，并制作修复版本重新走研发流程。
线上版本补救：
APP基于其本身的特性，不能像Web一样快速补救，因为受限于缺乏日志，用户网络场景，联系用户成本高等条件APP排查线上问题通常都比较困难。
这里需要遵循一个重要的方案选择顺序：
- 是否支持容灾
- 从运营侧关闭入口或替换内容，优先止损
- 服务端能不能兼容解决，不需要APP发版本
- APP 热更新（普通公司IOS基本用不了）
- APP 新增版本覆盖修复
项目复盘：
一个项目复盘能发现点对点人与人的问题，从个人角度出发解决难度大，无法保证执行效果
多个项目复盘汇总这些点，就会看到系统性的问题，解决系统问题发力点在系统流程制度上，通过优化流程来提高各节点执行过程的质量，从而达到提高结果质量目的。
浏览橘子树其他文章：橘子树的个人写作记录
