用例评审
测试
提交测试的版本要求：此阶段应完成80%以上的需求开发，测试以PRD为准。测试完成后，收集反馈，修复BUG，优化流程。
输出：系统测试总报告
任务完成准时率成果达成率代码规范执行情况技术资料完整性
评审结束后，PM出具最终PRD方案，必须由需求方确认，重要需求提出人需要签字。
测试版本
产品上线后，需要进行内测，内测的结果会影响相关人员的考核结果，内测结束，达到要求的（需求提出者和PM都同意的情况下）进行推广。
用户反馈
项目开发流程及结果要求
需求
需求讨论（评审）
目标
任务/项目1
产品迭代规划
参与人员：1.项目经理、PM2.部门内其他项目有关人员3.部门外需求提供方4.若项目较大，需邀请总经理参与。PM完成需求评审后，并且PM需告知完成PRD的时间
终稿之后，对界面设计阶段的最后结果配合技术部门实现界面设计的实际效果
设计稿件
测试用例
内测
N次
输出：缺陷列表，阶段性测试报告
结果要求
需求确定（文档）
报告
1.原型要求能够表达本期需求的所有想法2.记录和整理大家的建议，修改原型，再次讨论，指导完成输出：意见集合
UI设计师应了解产品的市场定位、产品定义、客户群体、运行方式等。收集相关资料分析目标用户的使用特征、情感、习惯、心理、需求等根据可用性分析结果制定交互方式、操作与跳转流程、结构、布局、信息和其他元素评审之前 在内部群提前展示一下，综合一下大家的建议
需求来源：1.业务部门提出需求，包含总经理、销售部、市场部以及其他部门。2.UI或PM研究用户，提出需求。此步骤需提供用户习惯报告，体验目标，用户访谈、调研，流量数据统计等作为依据，不得凭空想象。3.用户反馈需求分析：1.将有关 市场机会、竞争力、需求可行性、生产需求、对上一代产品优缺点的反馈 的信息综合起来，确定新产品的框架。2.PM接到显性需求后，应仔细透彻地分析需求方的真正意图。有时候需求方的想法不一定正确，也有些是突然的想法并不可行，PM需进行判断；当这种情况出现时，PM有权提出自己的解决方法，包括否定需求。因判断失误造成需求冲突、重复开发等情况，责任由PM承担。
需求文档
冒烟测试——回归测试——功能测试——性能测试——文档测试的顺序执行如果测试工程师与修改人员对状态为“非BUG”或“暂不解决”的缺陷无法达成一致，则测试组长与项目经理进行审核决定。
概要设计
创意
本轮测试结束后，测试工程师根据《系统测试报告模板》进行编写《系统测试报告》
输出：UI设计稿
编码
明确测试内容与重点测试方提交《测试计划》根据每一步测试计划编写全部的测试用例
详细设计
开发周期（周期）
设计
任务/项目2
时间周期
研发
评审
需求调研（采集）
稿件
考核点
用例编写
程序员对文档有疑问或不理解，需与PM进行沟通，了解其真实涵义，不得以任何理由私自更改已确定的PRD、GUI方案。确有功能需做调整，程序员需与PD、需求方共同协商完成。改动应出具文档，由需求方、技术经理、PM签字后生效。
需求整理（分析）
素材
正式版本
在编码之前，程序员应视其系统需要，进行概要设计、数据库设计，并进行内部讨论和评审。
以邮件或者其他明确的方式告知测试组进行测试:开始测试时间、测试版本号、本期改动受影响的模块
任务完成准时率设计方案一次通过率设计制作出错率资料完整性测试反馈满意度客户满意度
此阶段需告知产品开发的预估难度及具体完成工期。
提交测试
测试用例需要覆盖所有的测试需求输出：测试用例文档、测试计划
上线
提交缺陷总数有效缺陷数严重缺陷所占比例工具掌握能力测试报告质量客户反馈问题未测达率
输出：简易的PRD文档用于沟通的产品原型
流程备注
发布版本必须由产品负责人确认，持有测试组最终的测试报告并测试负责人确认，项目经理确认。此阶段产品经理应告知其他个部门新产品改进的功能，如需内部测试，需在内部群通知大家。
迭代N工作流程
迭代N开发流程
产品准时完成率需求明确性结构合理性客户反馈满意度
1.确定各项目阶段的研发周期和难度预估输出：最终PRD文档
战略/规划
迭代任务分解
流程
顺序任务执行
代码规范：（详细阅读代码规范文档）1.可读性2.易扩展3.易维护
公司战略
