从QA的角度说，流程的质量保证能极大的减少QA的工作量，提高工作效率。所以质量建设中流程建设也是极为重要的一环。在日常工作中一般将需求分为两块：日常需求与项目需求
日常需求包含：小需求，小技改需求，bugfix等
项目需求：一般开发工作量超过1周的需求则需要立项处理
从日常需求来看，需要的是快速处理快速上线，保证质量的情况下减少流程处理，一般每周会固定一个时间安排产品、测试tl、开发tl沟通优先级、资源与排期，确认排期安排产品开发测试沟通需求，并确认是否需要测试介入，并进入开发（测试）阶段，并通过bus发布，如紧急需求则走紧急发布，具体流程如下：
这种项目需要注意的是对于小项目影响面的评估尽量仔细，很多时候大项目反倒线上出问题的概率低，这种快速迭代的情况反倒容易出现问题，还有就是对开发自测的项目，有时间的话尽量快速的过一下做个兜底。大巴车上车时检查方需要多注意，包括继承的情况，合并的验证等，有问题及时反馈处理。
从项目需求来看的话，一般是：需求沟通->需求评审->技术方案评审->任务拆解->用例评审->冒烟&提测->验收发布->线上监控->复盘下每个阶段的情况
需求沟通：产品方发起，一般是简单的面谈或者企微、飞书等沟通，需要输出项目背景，业务方，开发和测试的tl给出资源，明确后拉起项目群
需求评审：产品方发起，一般以会议的形式展开，参与人有产品、开发、测试、运营（如有必要），产品方一般需要提前将需求文档发至群内，各参与方提前阅读文档并记录疑问点，产品在会议中简单减少prd，提出预期上线的时间，记录会议纪要与评审后需要确认的点和Actiong跟进。开发需要明确需求完整性和合理性，并反馈排期的工作量和计划。测试明确需求的完整性，需求是否与现有业务冲突，反馈预排期情况。评审通过输出最终版prd，不通过则需要进行二次评审。进入开发阶段后如果有需求变更则需要参与方确认是否需要二次评审，调整排期等，需求变更产品必须进行登记。
技术方案评审:开发发起，参与人开发、测试、开发负责人、产品，开发需要提前将技术方案发送到群内，各参与方提前阅读并记录疑问点。开发在会议中输出完整技术方案，记录会议纪要与评审后需要确认的点和Actiong跟进。开发负责人明确技术方案的规范和完整，设计是否合理与开发的注意点。测试需要明确技术方案的完整性，能否评估测试方案，与现有逻辑是否冲突，并依据方案提醒开发注意点。评审通过输出封板的技术方案，不通过则需要进行二次评审，进入开发后入需要技术方案调整，则开发需要同步开发负责人，并且参与方沟通是否需要二次评审。
任务拆解：参与人项目参与方，拆解任务的颗粒度尽量小于8h，可先执行筹备任务，开始节点明确依赖方
测试用例评审：测试发起，参与方：开发、测试、产品，测试提前输出测试用例与测试方案（视项目大小）到群内，确认排期、提测时间和发布计划，记录会议纪要与评审后需要确认的点和Actiong跟进。开发确认用例是否完整，是否有错误用例，方案理解偏差的情况，并提醒测试关注点：性能、安全、兼容、回归范围等。产品确认测试用例对需求覆盖完整度，是否理解错误。评审通过输出测试用例集，不通过则需要二次评审。
冒烟&提测：提前前测试创建冒烟执行集与测试执行集，开发完成冒烟测试集。完成提测文档；提测通过检查冒烟用例和提测文档，不通过则直接打回。体侧后测试执行冒烟，90%通过则冒烟通过开始功能测试，冒烟失败则直接打回
验收发布：由测试发起，参与人开发、测试、产品。与产品沟通发布时间确认产品验收结果，组织发布会议，并在发布后做线上验证
线上监控：开发需要观察线上稳定性，错误日志跟进，添加必要的业务监控配置，测试线上问题跟进，自动化跟进，产品业务结果收集，项目价值回顾
复盘：针对质量评分较低项目，PTM或者PM需要尽量组织复盘，PM提前收集项目成员对项目的感受和想法，进行汇总。会议结束后产出复盘纪要，改进Action和对应负责人
对于较大的项目经常会出现项目倒排，时间紧任务重的情况，需要根据实际情况合理的做出调整，在保证质量的前提下对部分流程进行简化处理，但是对关键流程必须要按标准实行
