产品设计开发评审程序之流程图

新产品开发评审流程标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-1主题内容和适用范围1.1本标准规定了公司新产品评审管理的流程。

1.2本规定适用于本公司新产品评审的管理过程。

2引用标准无3定义无4职责4.1技术部负责本流程的制定、修改工作。

4.2各部门根据此流程，在流程运行中执行各自的工作。

5新产品评审流程:新产品评审流程图：新产品评审流程:供销部接到客户需要开发产品的信息后，填写《新产品开发技术信息表》（附录A）,将客户图纸，数模与技术要求等信息交给技术部，并要求技术部提供有关信息。

（如需要技术部提供的信息有1.根据公司的软硬件情况，是否可以开发出合格的此产品；2.产品生产价格；3.模具开发价格，4.提供有关信息的时间等；）技术部收到供销部转来的客户图纸，数模与技术要求后进行技术的可行性分析，并召开产品开发评审会对产品的技术的可行性，生产价格，产品的开发周期等进行评估,并填写《产品开发评审单》转交供销部；供销部接到技术部对产品的评估信息后，综合市场等各方面的因素后，得出公司对此产品的价格与产品开发周期等信息，报给客户，供销部对产品报价进行跟踪；当客户同意公司所报的产品价格与产品开发周期后，供销部与客户签订产品开发合同，并给技术部发出开发指令；当客户不同意公司所报的产品价格与产品开发周期后，供销部对客户的项目状态进行跟踪，争取最大限度的拿到此订单。

技术部收到供销部的开发指令，与客户正式的产品图及产品数模后，严格按合同要求制定模具开发计划，进行模具开发并按期生产出合格的样件，样件经公司品质部检验合格后，交客户检验；样件经公司与客户检验合格后，模具移交给生产部锻压车间。

生产部锻压车间接到模具与相应得技术资料后，根据订单要求安排生产。

6 质量记录附录A新产品开发技术信息表附录B产品开发评审单表1评审人员的组成与职责√—表示参加评审△—必要时参加。

设计和开发评审程序1 范围本标准规定了产品设计评审的主要内容、组织治理和评审程序要求。

.本标准适用于工厂产品的研制设计、仿制设计、改型和改进设计的设计评审。

.2 标准性引用文件GJB1310A-202X 设计评审GJB9001B-202X 质量体系治理要求3 术语和定义以下术语和定义适用于本程序设计评审为确定设计到达规定目标的适宜性、充分性和有效性所进行的活动。

.4 职责4.1 科技质量部负责系统、分系统级设计评审的组织，系统、分系统、配套设备和部件级评审意见落实及跟踪治理工作；4.2 设计所负责配套设备、部件级的组织及评审样机、资料的打算工作。

5 程序5.1 设计评审流程图见附录A：5.2 一般要求设计评审是在研制过程决策的关键时刻，全面、系统的检查设计输出是否满足实际输入的要求，觉察设计中存在的缺陷和薄弱环节，提出改进措施建议，加速设计成熟，降低决策风险。

设计评审能影响设计决策，但不替代设计决策，不改变规定的技术责任制。

工厂应依据武器系统研制总要求、协议书、研制任务书和〔或〕合同要求，严格按照产品研制程序所划分的研制阶段及产品功能级别实行分级、分阶段的设计评审。

必要时，进行可靠性、维修性、保证性、测试性、平安性、环境适应性以及计算机软件、元器件、原材料等专题评审。

设计评审的结论是产品研制治理决策的重要依据。

产品研制未按研制方案规定进行设计评审或设计评审未通过不同意转入下阶段工作。

厂级设计评审系统、分系统由科技质量部组织实施，配套设备、部件级由设计所组织实施，科技质量部和上级主管部门负责监督。

设计评审的参加者应包含与所评审的产品设计阶段有关的职能部门的代表，非直接参与设计工作的同行专家。

合同要求时，应邀请顾客代表参加。

设计评审作为产品研制程序中的组成局部，应纳入研制方案，从时间、经费、工作条件等方面予以保证。

设计评审应有完整的记录，评审结论应形成文件。

设计评审的有关文件及评审结论应及时归档。

设计评审中应充分发扬技术民主，保护不同意见。

新产品开发流程图产品科(包括图样设计,成品编码,原材料开发)研发部工程部生产部IE业务部采购价格科重新打样小批量试产样与客户确认价格根据客户所提供的信息要求进行产品外观设计Yes木架结构设计核算最终成本工作中心建立Yes1.成品临时编码2.原材料临时编码(针对客户的开发)No缝套设计YesYes成品样品试作采购对原物料进行大货采购Yes根据产品科提供的产品外观设计进行产品内部结构设计No采购下单购买样品所需材料No 收到产品科所提供的产品设计图接到产品科提供的需求相关信息建入系统中(研发用)制作产品图样(外观图)木架样品制作缝套样品制作缝套样品评审No客户确认价格Yes 移交工程资料给工程部工程试产样品制作拿到供应商所提供的样品客户下单开发新的供应商或已有供应商按要求进行打样(主要为皮，面料)与客户确认图样确认采购样品是否合乎要求签订标样留存木架样品评审成品样品评审No工程试产样评审提交总经理核准Yes 更新BOM 系统及PLM系统材料报废率测定皮/布/板材……取得样品材料总经理核准Yes样板设计木架部件设计工程资料重新整理1. 面套排版图优化2. CNC 排版优化3. 海棉/丝棉排版优化4. 相关资料处理总经理核准Yes 各工段预估标准工时成品/原材料开发编码转换成ERP 正式代码PLM 转成正式代码YesNo计划部门安排大货生产No工程资料归档(上传到PLM)整理工程资料木架3D 图/面套样板图/材料明细表/各种操作流程SOP/海棉丝棉纸板图从客户接到产品信息(有样品照片)从客户收到产品信息/要求(无样品照片)建立初步BOM资料建立初步标准工时在系统中建立最终BOM更新工时系统样品成本预估价格谈判总经理核准NoNo生产问题检查没问题有问题1. 成品开发临时编码2. 原材料临时编码(针对公司自己开发)公司内部全新产品开发(效果图)收到产品科新品图样Yes确认是否接单开发YesYes通知客户，不接该单设计NoNoYes有定单，成品及原材料的编码转换成公司正式编码样品投放市场建立最终标准工时进入系统维护限价Yes进入ERP 财务限价Yes ERP 生成销售订单启动MRP 运算相关信息建入系统中(研发用)新产品开发流程图解释说明产品科(包括图样设计,成品编码,原材料开发)研发部工程部生产部IE业务部价格科采购1.对于接到客户的需求，需要详细记录，以提供更多的信息给厂内相关人员2. 如果与产品科人员讨论后不接单，需要向客户说明原因3. 当产品科依需求设计好图样，需要与客户确认是否满足其需求，如果OK，需要签定图样，以免事后客户做变更。

产研流程规范一背景目标1.1.背景为了提升团队协助的效率，避免不必要的返工，提高产品质量输出的稳定性，需要进行产品研发流程规范的明确和持续更新改进；1.2.思路逻辑：事前/事中/事后的视角，源头/过程/结果视角，协作/执行/管控视角原则：整体顾全大局，内容精炼萃取，规范具体落地，持续补充优化1.3.重点抓评审，抓版本控制，抓发布，抓线上监控和反馈二产研协同流程2.1 流程图2.2 评审2.2.1 产品方案评审（含交互）1.要求：评审前：准备充分，完成细节讨论；提前邀约，对应的产品人员，开发和测试全部参加；评审过程：大家积极投入，所有过程中的问题记录清楚；评审后：如果不通过，明确下次评审时间；如果通过，根据评审中提出的问题做修改，发出修改后的内容给参与评审及相关人员；2.内容：【产品方案评审必须包含】o背景价值说明（确保有用户价值背书）o完整需求流程（尤其是迭代需求，需要串联之前流程，标记所有影响点）o权限说明（确保无权限问题遗漏）o功能详细规则（如状态规则定义，字段规则定义）o特殊场景描述（如有的话）2.2.2 技术方案评审1.要求：复杂的需求必须有技术方案文档（包括概要设计，数据库设计等），并且进行评审；必须邀约核心相关人，主要是开发技术负责人，需求相应的开发人员；要有评审纪要，必须明确结论和修改动作；如果是对原有逻辑有修改，技术方案必须要加上原来数据如何处理的方案。

2.2.3 测试用例评审1.要求：评审前：准备充分，提前发出评审内容；提前邀约，对应的产品人员，开发和测试全部参加；评审过程：大家积极投入，所有过程中的问题记录清楚；评审后：如果不通过，明确下次评审时间；如果通过，根据评审中提出的问题做修改，发出修改后的内容给参与评审及相关人员；2.内容：使用思维导图将测试点全部清晰的列出，便于评审2.3 进入测试的标准A.开发提测1.要求：提测必须要有提测邮件，冒烟测试（冒烟测试用例由测试提供）已通过；2.内容：【提测模块内容说明】说明：即提测功能模块，尽可能的与需求文档中模块名称保持一致；【提测版本信息、代码分支路径信息】说明：开发需提供提测的安装包的地址，版本信息等；【测试注意事项】说明：从开发实现的角度，说明模块已存在的问题/可能存在的问题，影响范围说明，测试应注意的验证点等；【环境】说明：测试环境已部署好，或者提供部署脚本，由测试自己在测试环境部署；【开发自测结果说明】说明：冒烟测试执行的结果，附执行记录；【接口文档（可选）】说明：如果是接口测试，需提供接口文档；B.视觉走查提测后涉及视觉改动的必须通知设计走查；C.产品走查提测后必须通知产品人员走查，看具体实现是不是符合产品设计的想法；D.测试验收在测试环境中跑冒烟用例，未全部通过，打回，全部通过后可以进入测试（冒烟用例不用重复测试）；2.4 变更控制已经进入开发阶段的需求，本次迭代不允许变更，需求变更放到下一迭代，如果是紧急的，必须在本次迭代变更的，需要项目负责人和公司领导审批；2.5 版本控制（对产品质量的稳定极为重要）1.新的迭代从主干拉出开发分支进行开发，可以根据需求的情况从开发分支中再拉出多条子分支来开发，每条子分支上的需求经过测试通过后，合入开发分支（开发分支定期需要从主干rebase一下避免后面合入时冲突太多，子分支也从开发分支定期rebase）2.同一迭代的需求全部合入了该迭代的开发分支后，在开发分支进行这一迭代的所有需求的冒烟测试，全部通过后，将开发分支合入主干，再拉出发布分支，使用发布分支提供给测试人员进行测试（本次迭代的发布分支拉出之前，主干不可以合入下一迭代的开发分支）3.发布分支上不再允许合入新需求，在发布分支上进行集成测试和回归测试，期间的bugs直接在发布分支上修改4.发布分支测试通过，发布前需要修复的bugs全部修复完毕，进行锁库，发布分支不允许提交代码（除非是项目组经过讨论要针对某些问题进行修复，或者是在锁库后才发现的严重问题需要修复，否则都不能提交）5.在这一迭代内容发布出去后，将发布分支代码打tag存档，发布分支内容合入主干后，销毁发布分支6.如果发布后需要将这一迭代的内容做很小的改动或是修复几个bugs，可以从tag存档中拉出一个新的发布分支，直接在上面修改，然后发出一个bug fix 的版本，版本发布后又将这次的发布分支代码打tag存档，发布分支内容合入主干后，销毁发布分支7.新一迭代的需求又是从上面的第1点开始循环往复2.6 环境管理1. 开发环境和测试环境分离，避免相互干扰，测试执行和验证bugs都必须在测试环境上2. 预发布环境与线上环境尽量保持一致，发布前可以在预发布环境进行上线前测试2.7 测试准出标准1. 所有主流程和分支功能的用例都测试通过，特别复杂的组合操作和非常小概率场景操作的用例未通过的需要项目组整体评估，评估为可以延期的才能满足标准2. 如有非功能性要求，要达到需求要求的标准（如性能要求等）3.一、二级bugs修复率应达到100%，三级bugs修复率应达到95%；（遗留bugs 需要项目组整体评估是否可以延期）（bugs级别参考Bug 描述规范）三发布流程规范3.1 发布流程1.要求：原则上汇总避免零碎小需求，拆分减少大项目，确保固定的项目节奏，具体的迭代周期根据每个项目的情况来定；3.2 预约机制1.要求：日常发布提前两天以上通知3.3 发布红线严禁不经测试发布严禁未经审批的发布严禁无人职守发布四线上监控和反馈4.1 线上监控a）系统监控运维系统监控后台的应用和服务的可用性，有问题发出报警消息通知相关人员；b）重要接口监控接口可用性监控，有问题发出报警消息通知相关人员；c）客户端异常日志上报客户端发生异常时，自动上报相关日志，定期跟踪处理；4.2 反馈问题处理1.反馈问题记录到bug系统中跟踪，标题加上【反馈】2.紧急问题，马上跟踪修复，测试验证，走bug fix版本发布流程3.非紧急问题，每个迭代挑选出高优先级的进行解决，跟随迭代发布4.3 问题复盘对于线上监控和反馈的问题，进行复盘分析原因，1.对于遗漏的场景或条件，新增或更新用例，尽量避免下次同类问题的出现；2.对于其他类型的原因（如没有按流程规范操作或配置参数问题等）针对性的做出改进措施，或者直接更新流程规范等，尽量避免下次同类问题的出现；。