项目checklist模板
2024版清单检查项Checklist
20XX 专业合同封面COUNTRACT COVER甲方：XXX乙方：XXX2024版清单检查项Checklist 本合同目录一览1. 清单检查项概述1.1 清单内容1.2 检查项分类1.3 检查项标准2. 双方义务与责任2.1 甲方义务2.1.1 提供清单信息2.1.2 配合检查2.1.3 支付费用2.2 乙方义务2.2.1 进行检查2.2.2 提出问题2.2.3 提交报告3. 检查流程与时间安排3.1 初步审查3.1.1 审查内容3.1.2 审查时间3.2 现场检查3.2.1 检查内容3.2.2 检查时间3.3 问题反馈3.3.1 反馈内容3.3.2 反馈时间3.4 整改落实3.4.1 整改要求3.4.2 整改时间4. 费用与支付4.1 检查费用4.1.1 费用标准4.1.2 费用支付方式4.2 其他费用4.2.1 费用项目4.2.2 费用支付方式5. 合同的解除与终止5.1 解除条件5.2 终止条件5.3 解除与终止的后果6. 违约责任6.1 甲方违约6.2 乙方违约6.3 违约赔偿7. 争议解决7.1 协商解决7.2 调解解决7.3 仲裁解决7.4 法律途径8. 保密条款8.1 保密内容8.2 保密期限8.3 泄密后果9. 法律适用与争议解决9.1 法律适用9.2 争议解决10. 合同的生效、修改与解除10.1 合同生效条件10.2 合同修改10.3 合同解除11. 其他条款11.1 通知与送达11.2 合同的副本11.3 附件12. 甲方（乙方）签字盖章12.1 甲方签字盖章12.2 乙方签字盖章13. 日期14. 附件清单14.1 附件内容14.2 附件数量14.3 附件交付时间第一部分：合同如下：第一条清单检查项概述1.1 清单内容本合同清单检查项包括甲方提供的所有清单信息，包括但不限于货物、服务等。
1.2 检查项分类1.3 检查项标准检查项标准按照我国相关法律法规、行业标准和乙方制定的检查标准执行。
新项目Checklist
New Product Development Tollgate Checklist Feasibility For Quote (stageⅠ)可行性阶段一Proto Type(stage Ⅱ)打样（阶段二）Pilot Run (stage Ⅲ)试生产（阶段三）Mass(1 Year review)（stage Ⅳ)量产（阶段四）RFQ No. Receive date/接收日期Customer Address/客户地址Customer/客户Required date/客户需求日期Q-1 ApprovedSupplier:通过质量认证的供应商Project name/项目名称Production use/产品用途Payment Term/付款条款Project Life/机种寿命Shippingrequirement/运输方式Delivery Term/送货条款Customer Importance/客户等级:high，middle，low Business form/贸易方式：直接/间接/当地Package Model/包装模式：循环/一次性Review Items评审项目ⅠⅡⅢⅣReview Result评审结果Comments评价注解1.Customer drawing, BOM(e.g.: Special Technical requirements)客户图纸，BOM（如：特殊技术要求）OK通过Can’t Meet不能通过Improvement 需改善N/A不适用2.Product’s Requirements: PPAP, Surface treatment, Color Sample, Packaging, Transportation, Method….产品的要求：如PPAP，表面处理，色样，包装，运输，方法等OK通过Can’t Meet不能通过Improvement需改善N/A不适用3.Supplier’s Risk(including appointed Suppliers)供应商风险含指定的供应商OK通过Can’t Meet不能通过Improvement需改善N/A不适用4. Material Risk(e.g.: Supplier by Customer)物料风险如客户指定的供应商OK通过Can’t Meet不能通过Improvement需改善N/A不适用5. Product Certification Requirements(e.g.: ROHS,GP,UL) 产品认证要求OK通过Can’t Meet不能通过Improvement 需改善N/A不适用Continue to Next Stage继续下阶段Another Review Required and Date需重新review及时间Terminate the Project终止该项目Notice to Client通知客户New Product Requirement Checklist Details新产品评审要求细则#1- Drawing / Print:Need to confirm the latest revision level drawings available. Require all assembly, sub-assembly and individual component drawings are provided from customer.图纸：需要确认并获得最新版本的图纸，要求客户提供所有组件，分部组件和子件的图纸#2- Critical Material: Need to identify material requirements for the project to confirm availability in China and available material substitutions; this should include any supplied material as well as the manufacturer (such as steel mill, paint manufacturer or OSP) of this material.关键材料：需要识别该项目的材料要求并确认在国内可购买以及有可用的替代材料，此要求除了制造商如钢厂，涂料厂商或外协厂商外，还需包含其它原材料及物料#3- Customer Standards & Specifications:Acquire all customer standards, specifications and requirements for the part numbers being considered for quoting purposes. Ask for the following customer documents: Supplier Quality Manual, Specifications listed on drawing / print, PPAP, Material Certificate Requirements or any third party test requirements.客户标准及规格：对正在评估报价的项目料号取得客户标准，规范和要求。
实施项目里程碑评审checklist
通过
是否有明确的功能测试周期
有明确的功能测试周期且合理
是否有明确的测试范围
有明确的测试范围
相关开发文档是否已提交至测试组：功能需求分析说明书、概要设计说明书、网络结构拓扑图、业务流程图等
相关开发文档已提交至测试组：功能需求分析说明书、概要设计说明书、网络结构拓扑图、业务流程图等
确定行方是否有指定模板格式，优先使用行方模板，如没有使用内部模板
3
代码侵入性
开发改造对产品原功能
代码的程度
开发改造代码结构设计是否合理，侵入性是否能够剥离或优化
4
代码健壮性
异常情况考虑
对可能出现的异常情况进行了判断、捕获和处理
5
业务逻辑准确性
代码的处理逻辑、计算逻辑正确性
代码的处理逻辑、计算逻辑正确，能够符合需求需要
6
代码规范
代码抽象程度
公共代码进行了抽象
7
代码开发规范
相关开发文档已提交至测试组:性能需求分析说明书、概要设计说明书、网络结构拓扑图、业务流程图、接口设计文档等
10
性能测试方案/用例模板确定
确定行方是否有指定模板格式，优先使用行方模板，如没有使用内部模板
《性能测试方案》、
《性能测试用例》等有明确的模板
11
输出性能方案/测试用例
是否按照模板格式编写性能测试方案/测试用例
明确测试目标
有明确的测试目标
明确测试阶段
有明确的测试阶段，例如：SIT、UAT等
明确测试环
境
明确的测试环境配置情况
有明确的提交成果物
测试方案中，有写明确的成果物
2
性能测试checklist
如果有朋友想到更多的检查项，也希望可以留言大家一起讨论。
1. 开发人员是否提交了测试申请？2. 测试对象是否已经明确？3. 测试范围是否已经明确？4. 本次不被测试的范围是否已经明确？5. 测试目标是否已经明确？6. 何时开始性能测试？7. 何时终止一轮性能测试？8. 性能测试需要做几轮？9. 所需的测试环境是什么？是否已经到位并配置完成？（包括硬件、软件、网络等）10.所需的测试工具是什么？是否已经到位并保证可以正常使用？11.被测系统的版本是否已经明确？是否已发布？从哪里可以获得？是否已经部署成功？12.被测系统的相关功能是否已经正确实现？13.压力点是否已经明确？响应时间的计算方式是否已经明确？14.本次测试工作参考的文档有哪些？15.场景是否已经设计完成并记录在场景管理文档中？16.每个场景是否有明确的测试意图、前置条件和详细的设置？17.脚本是否已经录制并调试通过？18.是否已经明确了哪些地方需要参数化？19.是否已经明确了各个参数的取值方式？20.是否已经为参数化的部分准备了必须的数据？21.是否已经准备了相应历史数据量？22.是否已经准备了相应的数据恢复方法？（例如准备一个SQL语句用来恢复数据环境）23.在Controller中对多VU、多次迭代的情况是否已经调试通过？24.在Controller中Result的路径设置是否正确？25.在Controller中检查脚本选择是否正确？26.在Controller中检查VU数量设置是否正确？27.在Controller中检查集合点是否禁用/启用?28.在Controller中检查VU加载策略是否设置正确？29.在Controller中检查迭代次数是否设置正确？30.在Controller中检查迭代间隔设置是否正确？31.在Controller中检查日志是否禁用/启用？32.在Controller中检查Think_Time是否回放？33.在Controller中检查是否为UNIX服务器和Load Generator机添加了资源监视器并确认可以收到性能数据？34.在Controller中检查是否为其他必要的资源添加了资源监视器，并确认可以收到性能数据（例如Oracle，WebSphere）？35.在Controller中检查Load Generator机是否可以连上？36.检查场景管理文档中是否添加了新的“场景执行情况”，并记录了运行前的数据？37.在Controller中执行场景前，检查是否在Linux客户端中运行了vmstat和top，监视执行过程中的Linux服务器资源消耗情况？38.在Controller中执行场景完毕后是否马上去系统中进行检查数据的一致性，并填写“场景执行情况”中的运行后情况？39.场景完执行完后是否将vmstat和top的数据copy到记事本中，并保存到相应的结果目录下？40.整个系统的测试工作执行完毕后，是否进行了性能图表的分析和测试报告的提交？。
项目管理方法-检查清单模板
检查清单在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由项目管理室那样的支持项目管理的组织在项目审查和监督的成功案例和失败案例的基础上作成。
检查清单或者模板是组织的最佳实践，通过这些经验的积累可以提高项目管理的效率，有助于防止失败。
检查清单用于确认作业或工程是否存在遗漏。
模板作为产出物的雏形式样，具有WBS、网络图、需求变更书、进展报告书、合同标准文件等形式。
通过雏形的灵活运用，经验较浅的项目管理者可以明白必须做些什么，并能在其他项目中重复利用。
软件开发项目管理检查清单：天气晴雨表检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。
下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加详细。
通过这个清单，可以发现项目管理存在的问题，并采取措施加以改善。
需求式样晴雨表? 是否存在稳定的、完整的、书面的需求式样？? 是否已经就需求事项煞费苦心地与顾客进行了沟通和确认？? 是否存在需求式样尚未确定就以“暂定式样”开始作业而事后返工的情况？? 是否为了确认顾客的需求而对“需求式样书”进行了审查？? 是否根据顾客提供的产品式样书而直接进入了设计作业？? 是否在作业途中不断变更或追加需求式样？? 是否按照项目编号规则对每项需求赋予了惟一的编号？? 是否已经明确顾客方的项目推进体制以及最终决策者？? 是否摄于顾客的特权优位性而不经讨论地接受顾客的需求变更？? 是否在远远超越自身能力而根本无法完成的情况下不能清楚地说“不”？? 是否在作业已经进入测试阶段后还发现需求式样理解有误？? 是否以单一窗口接收顾客的需求，确保一窗口输入？? 项目组成员的作业是否基于最新需求信息，而不是已经失效的历史信息？项目计划晴雨表? 是否将估算视为一种特殊的技能，并将估算当作一个小项目？? 是否定期对项目计划实施重新估算并根据实际情况加以调整？? 是否对作业文档等成果物的“量”进行了估计？? 是否以适当的单位进行了作业量的估计？? 项目作业是否具有详细的日程表？? 日程表确定之后，如果和实际情况出入较大，是否进行了调整？? 是否接受了不切实际的开发日程，而其结果是，日程表仅仅成为一种形式？? “工作量”和“难易度”是否会因为担当者的不同而出现巨大变动？? 是否因为实际进展超前于计划而没有思考项目计划本身存在的精度问题？团队管理晴雨表? 是否存在明确的软件开发行动单位：团队？? 是否虽然叫作团队，但是并没有认识到协作而是专注于工作任务的分担？? 管理者是否仍然承担以前作为技术者所承担的具体开发作业任务？? 项目管理者是否仅仅根据自己的经验而将需求式样直接分派给“个人”？? 项目管理者是否总是认为项目没有什么值得注意的问题？? 团队成员是否知道项目作业内容的相互关系及其优先级？? 是否在项目启动之后仍然还有项目组成员感到无所事事？? 是否经常有特定的项目组成员总是加班到深夜？? 团队成员是否知道并遵守统一的作业规范？? 是否从作业流程上、从团队协作上追究过程序缺陷的真正原因？? 团队成员是否在相互察看成果物后产生提高自己的作业水平的意识？? 当问题难点解决之后，是否向项目组成员介绍解决该问题的思维和方法？? 项目组成员的出勤时间是否经常相差很大而不寻找原因？? 项目组成员在遇到技术难题时是否与项目组其他成员沟通并寻求支援？? 项目组成员在讨论问题时是否出现无条理的、非建设性的讨论？作业流程晴雨表? 是否存在专注于组织整体的开发作业和项目流程的人或者小组？? 是否存在项目开发作业的标准作业流程？? 是否存在记述顾客需求式样的文档标准？? 是否存在设计书的文档标准？? 是否不经过设计阶段而直接进入编码阶段？? 设计阶段是否实施了以设计为对象的审查？? 编码阶段是否实施了以代码为对象的审查？? 中途式样变更后，是否未经其影响范围的分析就直接分配给担当者？? 是否未经单体测试就直接开始综合测试？? 是否时至最后才发现此前隐藏的诸多问题？? 是否无视已经发现的问题而继续推进作业？? 是否多次重复出现以前相同的错误而没有吸取教训？? 是否没有专门的测试人员而在交付之前还是由开发者自己实施测试？? 对式样需求是否确立了适当的测试项目？? 测试是否几乎没有自动化手段？? 过程改善方面是否存在可以商量和咨询的人员？? 是否鼓励各开发小组写作事后分析报告，至少能就项目进程开会讨论？? 是否组织正式的活动，就软件开发与质量控制流程的相关问题相互切磋？项目配置晴雨表? 是否在发现潜在的缺陷时难以确定其对现有模型的影响范围？? 是否只有担当者知道而没有向所有成员公布缺陷的修正范围和修正方法？? 是否因为修改一个程序缺陷而引发多个新的缺陷？? 担当者是否能在任何时间对源程序做自由的变更？? 开发期间是否定期对制作过程中的文件和程序进行备份？? 是否确立了资源备份在非常时期的因应方式？? 需求式样书和设计书等正式文件是否存在“确认”手续？? 项目文档是否一直保持最初的状态，即使在式样变更后仍然没有变化？? 是否在项目后期难以想起中途式样变更的“理由”？? 对于程序缺陷和式样变更，是否能追踪其修改点？? 对于开发环境目录中的旧代码是否难以判断其能否删除？? 开发文档是否会出现链接到旧版本的情况？教育培训晴雨表? 是否描绘出现在的开发组织多年后的“风姿”？? 在组织上，是否对现在的人员实施技术性教育和培训？? 是否确立了员工教育培训的计划和目标？? 是否将技术学习视为个人任务而没有组织上的“方向”？? 项目开发人员所持有的软件开发文献的平均数量是否在1册以下？? 项目作业休息时间是否毫不涉及崭新技术方面的话题？? 项目组成员是否不知道软件工程的意思？? 是否不了解“凝聚度”、“结合度”等词汇的意思？? 是否难以说出5个以上的软件质量特性及其副特性？项目审查晴雨表? 参与者是否了解审查的整体流程？? 是否带着目的而非盲目地实施审查作业？? 是否仅仅局限于代码审查而不顾及其他？? 审查者是否只关注形式而非实质？? 是否明确审查对象物，针对“物”而非“人”？? 是否记录审查结果并追踪缺陷修正结果？? 是否将审查的反馈结果导入下一项目中？? 审查会议是否演化成为问题解决会议？其他? 是否采取了数据备份以及病毒防范等措施？? 对电子邮件的应对是否总是滞后？? 是否感到电子邮件的应对很繁琐？。
checklist模板
checklist模板Checklist模板。
在日常生活和工作中，我们经常需要使用checklist来帮助我们完成任务、检查工作进度或者确保工作质量。
一个好的checklist可以提高工作效率，减少错误发生的可能性。
下面是一个简单的checklist模板，可以根据具体情况进行定制，帮助你更好地完成工作。
1. 任务名称，（在这里填写你需要完成的任务名称）。
2. 任务描述，（简要描述一下这个任务的内容和要求）。
3. 任务截止日期，（填写任务的最后完成日期）。
4. 任务执行人，（填写负责执行这个任务的人员）。
5. 任务分解：步骤一，（列出完成这个任务需要进行的具体步骤）。
步骤二，（列出完成这个任务需要进行的具体步骤）。
步骤三，（列出完成这个任务需要进行的具体步骤）。
...6. 任务检查点：检查点一，（列出需要检查的关键点）。
检查点二，（列出需要检查的关键点）。
检查点三，（列出需要检查的关键点）。
...7. 任务完成标准：标准一，（列出任务完成的具体标准）。
标准二，（列出任务完成的具体标准）。
标准三，（列出任务完成的具体标准）。
...8. 任务备注，（在这里可以填写一些需要额外说明的内容）。
使用这个checklist模板，你可以清晰地了解到需要完成的任务内容、任务的截止日期、任务的分解步骤、任务的检查点和任务的完成标准。
这样一来，你就可以更加有条理地完成任务，并且确保任务的质量。
在填写任务分解和任务检查点的时候，要尽量具体和详细，这样可以确保你不会遗漏任何重要的步骤和检查点。
同时，在填写任务完成标准的时候，也要尽量量化和明确，这样可以让执行人员清楚地知道任务完成的标准是什么，避免出现模糊不清的情况。
在执行任务的过程中，要不断地对照checklist进行检查，确保自己按照要求完成了每一个步骤和检查点。
如果发现有任何问题或者偏差，要及时进行调整和纠正，避免影响任务的最终完成质量。
最后，在任务完成之后，还可以对照checklist进行一次全面的检查，确保任务的每一个标准都得到了满足。
建筑主体验收checklist
41
不平、缺漏、破损现象，油漆完好，无生锈情况；收边收口完好；盖板
上有鹅卵石的不能掉落在排水沟内。
42
设备基础
基础表面平整、无凹凸、钢筋外露现象，基础颜色采用中洛黄色，减振 台表面刷灰色漆。
□符合□不符合□其 他
□符合□不符合□其 他
□符合□不符合□其 他
□符合□不符合□其 他
□符合□不符合□其 他
窗
。
3、密封胶条安装牢固、无断裂、砂眼等缺陷，开关灵活，无碰擦、异
23
响、密闭、框与扇及扇与扇平行，无大小头、开启方向正确，无碰伤、
凹坑、污染、无明显拉毛，压条无缺损，密封胶无脱槽、卷边。
24
1、电动窗帘外观合格，无反向安装情况，无损坏、固定牢固。帘片孔 径、厚度检查。
25
2、产品数量与施工单位提供的设计图纸数量相符。
54
1、安装牢固，油漆完好，无锈蚀、污染。
55
围墙 2、与绿植保持合理距离（防止周界系统误报警），不低于2米。
56
3、防雷接地完好。
地下室出入口防雨水倒灌：
1、在地下室出入口（包括机动车、非机动车及人行出入口）不仅要防
止路面的雨水进入地下室，还要防止出入口两边的绿化用地、人行道的
雨水进入地下车库，需要配套倒坡、挡土墙、截水沟等来防止暴雨时积
□符合□不符合□其 他
12
12、避雷带：无缺漏，连接良好，提供防雷检测报告。
□符合□不符合□其 他
13
13、屋面隔热层无破损、板面起翘现象。
□符合□不符合□其 他
14
14、车库净标高满足设计需求。
核查车库净高 较低点位置高
度
□符合□不符合□其 他
15
CK (项目名称)项目评审Checklist
R3.项目终验
从业务需求满足、架构、供 应商支持、IT服务、项目管 理规范性等方面，对项目做 最终验收。
评审纪要输出人 备案
项目评审指标（check-list)
A类：PMO B类：IT项目经理
PMO
《P2.立项阶段评审指标》
A类：PMO B类：IT项目经理
PMO
《P3.方案选型评审指标》
项目经理
PMO
1、业务:项目总监、业务项目经理、集 团对口职能部门 2、IT:专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、运维 1、集团管理部门:集经、集财 2、业务:项目总监、业务项目经理、集 团对口职能部门 3、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、IT财
阶段
阶段评审目的
评审小组成员
1、集团管理部门:集经、集财 2、业务:项目总监、业务项目经理、集 团对口职能部门 3、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、IT财 1、集团管理部门:集经、集财
P2.立项阶段
项目目标、需求明确、清晰 、可行
P3.方 2、业务:项目总监、业务项目经理、集 合美的IT架构要求，达到可 团对口职能部门 招标要求 3、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、IT财、商务 1、业务:项目总监、业务项目经理、集 需求经过充分调研，项目组 团对口职能部门 对业务需求理解清晰、准 确，得到业务的评审、确认 2、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 1、业务:项目总监、业务项目经理、集 团对口职能部门 总体方案能满足业务的需 2、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、运维
2024版清单检查项Checklist
2024版清单检查项Checklist 合同编号：__________甲方：乙方：鉴于甲方是一家具有合法经营资格的企业，乙方是一家具备相关服务能力的个体或企业，甲乙双方本着平等、自愿、公平、诚实信用的原则，经友好协商，就甲方委托乙方提供清单检查项Checklist服务事宜，达成如下协议：一、服务内容1.1 乙方根据甲方的需求，提供一份详细的清单检查项Checklist，包括但不限于项目名称、检查项、检查标准、注意事项等内容。
1.2 乙方应确保清单检查项Checklist的准确性和完整性，确保甲方在实际操作中能够按照Checklist进行有效检查。
1.3 乙方应在甲方要求的时间内完成清单检查项Checklist的编制，并提交给甲方。
二、服务费用2.1 乙方向甲方提供清单检查项Checklist服务的费用为人民币【】元整（大写：【】元整）。
2.2 甲方应按照本协议约定的金额和时间向乙方支付服务费用。
三、保密条款3.1 乙方应对在提供清单检查项Checklist服务过程中获得的甲方商业秘密、技术秘密、市场信息等保密信息予以保密。
3.2 保密期限自本协议签订之日起至双方终止或解除本协议之日起【】年。
四、违约责任4.1 乙方未按照约定时间完成清单检查项Checklist的编制，甲方有权解除本协议，并要求乙方支付违约金。
4.2 甲方未按照约定时间向乙方支付服务费用，乙方有权解除本协议，并要求甲方支付违约金。
五、争议解决5.1 对于本协议的解释或履行发生的任何争议，双方应通过友好协商解决；协商不成的，任何一方均有权将争议提交我国有管辖权的人民法院解决。
六、其他条款6.1 本协议自双方签字（或盖章）之日起生效，一式两份，甲乙双方各执一份。
6.2 本协议的有效期为【】年，自合同生效之日起计算。
甲方（盖章）：乙方（盖章）：签订日期：【年】年【月】月【日】日。
Checklist推荐模板
Checklist推荐模板
Checklist推荐模板
申请人:
出生年月：
申请目标（中文）：XXX大学XXX系XXX方向
Applying to：
电子邮件：
内含材料及顺序：CV，策划构思，推荐信，自我陈述，研究计划要求示例
第一人：（负责CV）
1.诚信签名表
2.CV
3.术语对照一览表（必须另起一页）
第二人：（负责总策划）
1.诚信签名表
2.成果展示
第三至五人：（负责推荐信）
1.诚信签名表
2.成果展示：
第六人：（负责PS）
1.PHS：Motivation, Unique, Diversity
2.SP：Purpose & Focus, Background (Academic & Research )
第七人：（负责RP）
1.研究现状
2.想法由来
3.研究重点：
4.研究计划/步骤：前期准备，研究经验，具体步骤，创新点，意义/贡献
5.预期问题/挑战及可能的解决方案
6.参考文献。
清单检查项Checklist
清单检查项Checklist合同编号：__________合同各方：甲方：（全称）地址：联系方式：乙方：（全称）地址：联系方式：鉴于甲方与乙方拟就某项业务进行合作，为确保双方的权利和义务，经甲乙双方友好协商，特订立本合同，以便共同遵守。
第一条合同标的本合同标的为甲方提供的如下服务/商品：1.1 服务/商品名称：1.2 服务/商品数量：1.3 服务/商品质量标准：第二条双方义务2.1 甲方义务：（1）按照合同约定提供服务/商品；（2）保证服务/商品的质量符合约定的标准；（3）提供必要的售后服务；（4）按照约定时间交付服务/商品。
2.2 乙方义务：（1）按照合同约定支付服务/商品费用；（2）提供甲方服务/商品所需的必要条件；（3）协助甲方进行服务/商品的安装、调试等工作；（4）按照约定时间接收服务/商品。
第三条合同价格3.1 本合同价格为人民币（大写）：__________元整（小写）：__________元。
3.2 甲方应按照本合同约定的时间、数量、质量提供服务/商品。
3.3 乙方应按照本合同约定的时间支付服务/商品费用。
第四条交付及验收4.1 甲方应按照本合同约定的时间、地点将服务/商品交付给乙方。
4.2 乙方应按照本合同约定的标准对甲方提供的服务/商品进行验收。
4.3 验收合格的，乙方应在验收合格后__________日内向甲方支付服务/商品费用。
第五条售后服务5.1 甲方应提供必要的售后服务，包括：（1）服务/商品安装、调试；（2）定期维护；（3）解答乙方在使用过程中遇到的问题。
5.2 售后服务期限为：__________年。
第六条违约责任6.1 任何一方违反本合同的约定，应承担违约责任，向守约方支付违约金，违约金为合同金额的__________%。
6.2 违约方应承担因违约产生的其他损失赔偿责任。
第七条争议解决7.1 本合同的签订、履行、解释及争议解决均适用中华人民共和国法律。
7.2 双方在履行合同过程中发生的争议，应通过友好协商解决；协商不成的，任何一方均有权向合同签订地人民法院提起诉讼。
项目过程Checklist
6UC评审中发现的问题是否进行及时跟8设是否形成系统设计文档,纳入11编15Codereview发现的问题是否进行及时工程过程序号检查点检查项审计检查级结果别问题描述检输出纠纠查或其正正时它证结时间明果间是否关闭1需求分是否进行功能需求（FRD）确认高析2是否进行Demo评审（如涉及Demo）高3是否进行UC评审高4UC评审会上是否确定需求基线时间高UC评审结束后是否形成《需求评审报5告》，通知项目组各方成员确认，并中纳入confluence上项目文档库踪和验证，已妥善解决（SQA抽查）高UC评审通过后UC文档是否按时入库基线1.基线时间在需求评审会议上项目组7一致确定高2.基线时间不能晚于设计完成时间3.基线时间的调整必须经项目组全体成员确认达成一致计confluence上项目文档库高9是否进行设计评审高技术评审结束后是否形成《设计评审10报告》，通知项目组相关人员确认，中并纳入confluence上项目文档库码是否进行TC评审高TC评审后是否形成《TC评审报告》，12通知项目组相关人员确认，并纳入中confluence上项目文档库13提交测试前是否进行Codereview高Codereview结束后是否形成14《Codereview记录》，通知项目组相关人员确认，并纳入confluence上项中目文档库跟踪和验证，已妥善解决(PM把关)高19是否填写《开发提交测试清单》，在20测22回归测试前是否全部closed功能测试23回归测试前是否提交客户验收测试，回归测试前是否提交代码安全审核，24进入预发布前，全部closed测试中发25发28正式发布前是否所有缺陷都已30正式发布是否出现二次发布或发布回31项目组相关成员是否对发布结果进行16 17提交测试前是否提交DBA进行SQL审核，并对审核出的问题进行改进与跟高踪解决提交测试前是否向SCM申请测试分支合并代码并解决代码冲突（QA配合检高查）18提交测试前是否完成测试环境搭建高转测试时提交给测试高试发现的所有问题是否按规范录入QC平台的项目缺陷库中高21是否按时发送《测试质量报告》高中发现的所有Bug（Deferred除外）高并在QC中记录验收测试发现的问题中并输出《代码安全审核报告》高回归测试之前，'代码安全审核报告'中所有'项目相关'安全漏洞已修补；若未修补的，已约定计划完成时间（在本项目内）；高若未修补且无计划完成时间的，必须要有开发主管的确认邮件现的所有Bug（Deferred除外）高布截止到项目发布前一周是否已制定完成发布计划（B类项目截止在发布前三高天完成）截止在项目发布前三天已完成发布计26 27划评审，并通知到项目组相关人员与会（PM,PD，开发，测试，DBA,SCM,SQA）项目发布时间与小需求发布时间冲突时，是否进行发布时间协调尽量避免相同应用同一天发布项目和小需求高高（截止在项目发布前三天完成）Closed(Deferred除外）高滚（SCM统计）高验证（SCM把关）高33项目发布后一月内是否已完成需求归34项目发布后两周内是否已完成TC归档号点检查项审计检查问题检查3项目Kickoff PPT是否输5项目详细开发计划是否输7项目估算（开发、测试）8控制项目周报是否每周五下班10项目需求变更记录跟踪表11项目风险控制（周报中包发若有项目相关的Deffered缺陷是否已29布安排好后期处理计划（正式发布后三高后天内）项目发布后的两周是否对故障与32Deferred问题(项目范围内)进行跟踪高与解决档入产品文档库（SQA抽查）中入公共用例库（SQA抽查）中管理过程序检查级别结果描述时间项目立项通知输出或其它证明纠正纠正是否结果时间关闭1立项21.通知对象是否涉及所有相关方2.通知内容是否完整项目Kickoff1.会议通知是否涉及所有相关方2.会议内容是否包含项目高高里程碑计划，项目风险识别出，及时上传文档库中4计划项目里程碑计划是否输出高出高6项目测试计划是否输出高是否输出高前提交高项目进度周会是否定期召9开（Kickoff约定沟通机中制）是否输出，内容填写完整高高含）15 资源12 结项 项目总结会是否召开高 13 项目总结报告是否输出 高14 项目过程度量数据表中统计 项目组 RPM 上每周按时项 目相关工时填写 高。
设计和项目checklist
项目周会 Check List（草案）
投模决策 模具制造
ESL1 ESL2
小批 pilot 量产
项目周会 Check List（草案）
市场调研、成本分析 项目研究计划表：设计工程师研究计划（样机研究，标准研究，功能结构评估） 专利搜索报告 标准研究计划表：品质工程师标准研究计划（标准释放，对比，解读，培训）、 测试资源评估清单：测试资源评估表准备（测试工装，仪器，设备，耗材） 可行性分析报告释放计划 意向书：明确 目标市场/目标成本/目标客户/主要性能参数/项目计划 客户流程确认（CPA，KFPS，各阶段样机需求计划） 实验大纲编制，讨论，释放计划
意向书 实验汇总表 拆机分析报告
ESL2物料到料清单：ESL2物料监控，到料测量确认 项目改进计划表更新：整机装配问题汇总，改善计划表更新执行监控 项目改进计划表更新：Artwork及ID参与确认相关外观及造型的问题点recheck. 装配工艺表：装配工装，检具，设备改善结果验证 测试设备清单：测试资源改善验证 ESL1品质评估报告：ESL1品质评估计划，测试情况监控跟踪（特别关注：使用，耐久，寿 命，温升,EMC） 项目改进计划表更新：ESL1阶段问题点改善结果确认 小批申请单释放 认证摸底，认证样机准备（特别关注：噪音，温升，耐久） FFU摸底，客户特殊测试要求摸底，FFU样机准备 小批检指，图纸发行计划，检具移交IQC计划 BOM进系统计划（物料清单爆炸图释放计划，商务档案释放计划） 试制完成2天内将包装样机安排寄出
PM
投模决策后5个工作日
包装 投模决策前5个工作日
RD
投模决策后5个工作日
RD
EOS后3个工作日
QA
项目上线自查文档(Check_list)
15UI、交互测试来自16产品原型、流程图、PRD
17
产品 上线通知
18
产品上线后检验
产品上线自查清单（Check_list）
详细内容
IOS：AppStore Android：小米、360、华为、oppo、应用宝.... 尺寸、logo、根据各个应用时长规格要求确定 闪现审核时要把苹果相关物品和宣传内容进行屏蔽 通用模板 通用模板 代码是否符合上线标准 部署服务器、域名解析等 各个发布渠道要有单独的渠道包 功能相关接口要先上线 确保版本号的连续性 数据统计、推送等服务 与产品需求保持一致 常用机型和系统 根据需求 UI设计师也要参与UI验收 所有文档都与线上功能保持一致 确定上线内容、通知对象等 产品经理自行检验、需求方检验反馈（检验内容：交互、逻辑等）
产品上线自查清单（Check_list）
序号 事项分类
事项说明
1
确定产品发布渠道
2 3
运营
应用商店介绍图 IOS版本的媒体内容管控
4
应用提交文案
5
新版本产品功能介绍
6
代码review
7
上线部署
8 9
技术
渠道包打包 接口上线确认
10
版本号管理
11
第三方服务确认
12
功能测试
13 14
测试
系统兼容测试 冒烟测试、回归测试
跟进人 张三
赵六 小红 小清
责任人 是否完成 张运营
赵技术 小白 小蓝
备注
项目测试管理CheckList_V1.0_xxx
项目测试管理CheckList Prepared by Date 2009-10-26
编制日期
Reviewed by Date
审核日期
Authorized by Date
批准日期
All rights reserved
版权所有违版必究
1、内容填写说明
A、项目基本信息由测试用例设计者填写。
B、自检，根据检查结果在自检结果“是、否、免”相应栏中作“V”标记；是：满足要求，否：不满足要求，免：内容不涉及此项目；在“否、免”栏作“V”标记，必须在自检说明中填写原因。
C、审查，确认自检结果是否正确，如与审查项目一致：在互检结果“是”栏作“V”标记，否则：在审核结果“否”栏作“V”标记，并在审核说明中填写原因。
D、“自检结论及问题说明”由测试用例设计者填写，在此栏说明该项目检视的要点，方便审核者检查。
“审核结论及问题说明”由审核者填写，在此栏列出审核结果中为“否”的所有问题。
E、最终QA将此文档提交给运作支持部，进行数据备份，整个过程由运作支持部跟踪。
华为项目工程师现场服务规范检查Checklist(全国)数据反馈模板
华为项目工程师现场服务规范检查Checklist(全国)数
地区
项目
内容(3-5条款细则)
关键点
不无故失约（如不能准时到达：应在与用户约定时间的前5 －10分钟同用户取得联系；提前表示歉意，重新确定到达 时间；驻场工作时间同客户单位考勤时间,应确保比客户单 位上班时间早5-10分钟到达。）；不置用户需求不理。 不在用户数据未确认备份，未在维修单签署免责条款前提 下对硬盘进行任何操作；不泄密。 不在用户未许可情况下改变用户机器设置；不在维修单上 代用户签字。 不与用户争执；不在未经许可情况下调用和查看用户信息 、使用用户通讯设备；碰到客户业务相关数据或者客户输 入密码时要有意识地回避。 接到派单要联系（30分钟内主动预约：了解故障现象，约 定时间地点）。 检查维修工具是否齐全（含NDOS/SME项目特有和通用光盘 、笔）。 检查所需备件是否齐全 检查名片及单据是否齐全 自我准备：整理着装（含卡证是否佩戴正确）、仪容、思 路、话术。 主动向客户问好并说明身份和来意，并约见客户。见到客 户时应面带微笑，自信、清晰地进行自我。介绍时出示胸 卡，“您好，我是阳光雨露服务工程师xxx”(如是很熟悉 的客户自我介绍环节可根据情境简化处理) 。进入客户方 安排的驻场工位，不得大声喧哗，保持桌面整洁，遵循客 户办公场所的环境要求。 故障复现（仔细确认故障情况），征得客户允许情况下开 始服务操作，确保故障没有进一步扩大。 数据安全方面，动手之前应了解用户数据的存储及备份情 况、并做好相关免责声明，并在维修单确认签字等。 填写维修单，准确记录服务过程。 维修过程使用的部件摆放有序。 服务完成后配合用户复验机器（服务完成必须验机，有条 件当直接用户、间接用户面的，主动配合客户验机，确认 问题已解决） 整理现场（清洁机器由工程师视情况而定）维修完成后， 机器复原。如：因维修需要，剪开的扎带重新扎好、机器 恢复到原来的位置、清理维修现场。） 请用户签字确认服务完成。 双手递上名片，礼貌道别（留下联系方式）。 维修黄联留给用户。 微笑服务，介绍小常识，询问需求，把握项目外商机。
项目checklist模板.xls
若前期评审有错，以最后一次改进时间为准 。如果客户没有把改进的MD发来，此处留 空并且跟催。完成标志是必改项为0 保存校准参数的方法等。
需要签署封样的，例如中宝的，留有签署封 样的文件
整机软件调试是否OK。待机电流，用户手 册，CQ中的A类BUG。
量产前的天线测试报告，是否为开模样品 。否则不予确认。只给针对样品的报告数 据
客户ID是否完成评审、备案。有否和其他 客户冲突接近
客户MD是否完成评审
是否告知客户我司的单机下载工具 是否告知客户我司的多串口下载工具 客户 相关 客户的供应商是否审核完整，包括屏，摄 像头，天线，电池厂家，FPC厂家。目前 要求这5类。大客户的话，喇叭也要求
XY项目备忘
分类
分类项
情况
最后更新/操作时间
原因备注
项目信息表是否及时更新 原理图和摆件评审
原理图评审时注意核对功能需 求，包括哪些资源是复用的而导 致有些功能只能两选一等
LAYOUT评审，后续GERBER文件的更新，变 更是否描述清楚，是否写明了板子的内存 种类，拼板大小在文件名中
BOM归档后的差异料跟踪
生产资料核对，钢网的制作安排。有否因 为特殊机型需求，区别钢网，堵住某些开 孔等
过程 PR1试产前，软件的安排准备
PR1试产前，外围料安排准备，LCD，摄像 头，按键板等供调试用
问题 的提前预防和监督。使得V001对测试部而 言有意义。
PCBA的调试结论是否给出，作为量产投板 依据
制程认证CHECKLIST模板(2024版)
制程认证CHECKLIST模板(2024版)合同编号：__________鉴于甲方为乙方提供制程认证服务，为确保双方的权利和义务，经甲乙双方友好协商，特订立本合同，共同遵照执行。
第一条服务内容1.1 甲方应按照本合同约定的范围和标准为乙方提供制程认证服务。
1.2 乙方应按照甲方的要求提供相关资料，并积极配合甲方进行制程认证。
第二条服务范围和标准2.1 甲方应对乙方的生产制程进行全面审查，包括但不限于生产设备、工艺流程、人员素质、质量控制等方面。
2.2 甲方应按照相关法律法规和行业标准，对乙方进行制程认证，确保乙方的生产制程符合要求。
2.3 甲方应在认证过程中提供必要的指导和帮助，协助乙方改进生产制程，提高产品质量。
第三条服务期限3.1 本合同自双方签字（或盖章）之日起生效，有效期为____年。
3.2 甲方应在合同有效期内完成制程认证工作，并出具认证报告。
第四条费用及支付4.1 乙方应支付甲方制程认证服务费共计人民币____元（大写：____________________元整）。
4.2 乙方支付服务费用后，甲方开始进行制程认证。
4.3 甲方开具正规发票，乙方按约定时间支付服务费用。
第五条保密条款5.1 双方在合同履行过程中所获悉的对方商业秘密、技术秘密、市场信息等，应予以严格保密。
5.2 保密期限自本合同签订之日起算，至合同终止或履行完毕之日止。
第六条违约责任6.1 任何一方违反本合同的约定，导致合同无法履行或造成对方损失的，应承担违约责任。
6.2 甲方未按约定时间完成制程认证的，应向乙方支付违约金，违约金为服务费用的____%。
6.3 乙方未按约定时间支付服务费用的，应向甲方支付滞纳金，滞纳金为应付款项的____%。
第七条争议解决7.1 本合同的签订、履行、解释及争议解决均适用中华人民共和国法律。
7.2 双方在履行合同过程中发生的争议，应通过友好协商解决；协商不成的，可以向有管辖权的人民法院起诉。
TP项目评估CHECKLISTword版
4.90/6.70
左边框
3.69/是
右边框
3.69/是
非FPC出线端边框
5.5mm
玻璃（材料型号/厚度）
7.0"以下：0.70mm
7.0"(含）以上：0.95mm以上
旭硝子，0.70
上OCA（材料型号/厚度）
黑色面板：
7.0"以下：0.10mm
7.0"(含）以上：0.075mm
白色面板：
400*340
排版模数
依材料尺寸
12
上ITO排版利用率
70%以上
73.50%
下ITO开料尺寸（L * W）
依Sensor OD
无
下ITO排版利用率（仅做报价参考，不做规格评估）
/
/
Cover倒角
1、正反面倒角C0.15;
2、正面倒角C0.30，反面倒角C0.10（需确保倒角后，其直边需≥0.30
正反面倒角C0.15
7.0"以上：0.175mm
7.0"(含）以上：0.175mm
0.125mm
上ITO
材料型号/厚度
JSR,0.125mm
面阻抗/蚀刻痕（有/无）
150Ω，无
下OCA(材料型号/厚度)
0.05mm
无
下ITO（若为G+F结构，则无下ITO）
材料型号/厚度
无
面阻抗/蚀刻痕（有/无）
无
TP总厚度及公差是否满足需求（客户需求尺寸）
无
质量协议
有
环保要求
有
结构评审
产品结构
G+F or G+F+F or Other
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
原因备注
原理图评审时注意核对功能需 求，包括哪些资源是复用的而导 致有些功能只能两选一等
客户I 是否完成评审 备案。 是否完成评审、 客户ID是否完成评审、备案。有否和其他 客户冲突接近 客户MD是否完成评审 是否完成评审 客户 是否告知客户我司的单机下载工具 是否告知客户我司的多串口下载工具 客户 相关 客户的供应商是否审核完整，包括屏，摄 客户的供应商是否审核完整，包括屏， 像头，天线，电池厂家，FPC厂家 厂家。 像头，天线，电池厂家，FPC厂家。目前 要求这5 大客户的话， 要求这5类。大客户的话，喇叭也要求 客户第一次小批量装机的跟踪， 客户第一次小批量装机的跟踪，是否排出 中试支持。 中试支持。 客户打算加入的SP沟通 客户打算加入的SP沟通 SP 外场测试是否需要，和聂浅进行沟通。 外场测试是否需要，和聂浅进行沟通。
XY项目备忘
分类 分类项 项目信息表是否及时更新 原理图和摆件评审 LAYOUT评审，后续GERBER文件的更新，变 LAYOUT评审，后续GERBER文件的更新， 评审 GERBER文件的更新 更是否描述清楚， 更是否描述清楚，是否写明了板子的内存 种类， 种类，拼板大小在文件名中 BOM归档后的差异料跟踪 BOM归档后的差异料跟踪 生产资料核对，钢网的制作安排。 生产资料核对，钢网的制作安排。有否因 为特殊机型需求，区别钢网， 为特殊机型需求，区别钢网，堵住某些开 孔等 过程 PR1试产前，软件的安排准备 试产前， PR1试产前，外围料安排准备，LCD， PR1试产前，外围料安排准备，LCD，摄像 头，按键板等供调试用 第一次发布正式版本前， 第一次发布正式版本前，对软件共性问题 的提前预防和监督。使得V001对测试部而 的提前预防和监督。使得V001对测试部而 言有意义。 言有意义。 PCBA的调试结论是否给出，作为量产投板 CBA的调试结论是否给出， 的调试结论是否给出 依据 整机软件调试是否O 整机软件调试是否OK。待机电流，用户手 待机电流， CQ中的 中的A BUG。 册，CQ中的A类BUG。 量产前的天线测试报告， 量产前的天线测试报告，是否为开模样品 否则不予确认。 。否则不予确认。只给针对样品的报告数 据
若前期评审有错， 若前期评审有错，以最后一次改进时间为准 如果客户没有把改进的MD发来，此处留 发来， 。如果客户没有把改进的 发来 空并且跟催。完成标志是必改项为0 空并且跟催。 完成标志是必改项为 保存校准参数的方法等。 保存校准参数的方法等。
需要签署封样的，例如中宝的， 需要签署封样的，例如中宝的，留有签署封 样的文件