新业务项目业务案例checklist

新产品试产质量checklist
新产品试产质量检查清单（Checklist）是一个重要的工具，用于确保在试产阶段产品的质量和设计的完整性。

以下是一个简化的新产品试产质量检查清单的示例：
1.产品规格和设计
产品是否符合设计规格和要求？
所有功能和部件是否满足客户和市场需求？
2.制造流程和工艺
制造流程是否高效且具有足够的灵活性？
工艺参数是否经过验证并处于受控状态？
3.材料和供应商
材料的质量是否符合要求？
供应商是否可靠且具备持续供应的能力？
4.产品质量和可靠性
产品是否通过所有必要的测试（如功能、性能、安全等）？
是否有可靠的数据支持产品的质量和可靠性？
5.产品和过程的可重复性
产品和过程是否具有足够的可重复性？
是否制定了明确的操作和检查程序？
6.产品包装和标识
产品包装是否适应运输和存储的需要？
是否有清晰的标识和标签？
7.环境和安全考虑
产品是否对环境友好？
是否已考虑所有相关的安全和健康问题？
8.试产报告和反馈
试产报告是否完整并准确记录了所有发现的问题？
是否收集了来自内部团队和外部利益相关者的反馈？
9.产品和过程的改进
是否确定了产品和过程的改进领域？
是否制定了改进计划并确定了责任人？
10.文档和记录
是否已收集并整理了所有必要的文档和记录？
是否有系统来跟踪产品和过程的改进？
这是一个基本的检查清单，具体的清单可能需要根据产品的特性和试产的阶段进行调整。

重要的是确保清单覆盖了所有关键的质量方面，并在试产过程中进行适当的更新。

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.客户标准及规格：对正在评估报价的项目料号取得客户标准，规范和要求。

5
* 定期会议的总结报告；
* 项目结束的总结报告；
* 延误项目的总结分析，补救
措施，甚至经验教训；
* 对象部品初期流动管理计划
5
书；
* 目标的设定要结合实际水
平，并要满足客户的要求；
* 要有缩短目标和实际水平之
间差距的行动计划及达成日
* 如何设定设备点检项目的规
5
则（包含设备说明书重要求
的，过去故障中总结分析认为
请回答当时贵公司的综合责任比率。
2，交货不良率 请回答贵公司在最近12个月内客户购入时
（ppm）
发生的相对于对象零件群的总购入数量的
购入不良数的实绩。
3，工序不良率 （废品率） （%）
请回答在对象零件群的主要工序（另外选 定3-4个工序），当月或上月发生的相对 于对象工序的总生产个数的废品个数（修 理品除外）的实绩。
确认状况
配点 得点 100%
* 认证类型；
5
* 认证时间（首次，监督审核）
* 证书范围；
* 证书有效期；
* 认证公司； * 将来的认证计划（更高要求 的，或安全，环境认证等；
* 如果有问到，可以说明取得主 机厂认证的资格信息；
（各类证书、复印件准备） * 认证机构对公司的整体评价；
* 与品质政策相一致的品质方
请准备至少连续3年的： * 品质目标； * 品质实绩数据； * 推移图； * 品质月度会议报告； * 品质月度会议会议记录； * 未达目标时的递减活动记 录，及递减绩效图表； * 定期会议中，各管理层指摘 问题的跟踪结果。
请准备至少连续3年的： * 品质目标； * 品质实绩数据； * 推移图； * 品质月度会议报告； * 品质月度会议会议记录； * 未达目标时的递减活动记 录，及递减绩效图表； * 定期会议中，各管理层指摘 问题的跟踪结果；

D4－根本原因 1.是否已经确认了问题“流出”的根本原因及“失效”的根本原 因？ 2.有否做到了现场，现时，现物 “三现” 3、检查问题是否涉及到设计、过程、材料、环境、产线及人员等 各方面因素 4、检查过去的原始相关数据/记录是否与投诉问题相关联； 5、检查是否不止一个根本原因； 6、检查相似产品/部件是否有同样问题； 7、用5W的方法找出根本原因； 8、尽量尝试让问题重现 9、当根本原因找到时，再重新确认D2看是否相符合。
Checklist
D1－组建团队 1.有否组建团队？ 2.团队是否具有合适的技能？ 3.团队成员需4-8人 4.有无指定团队负责人？
8D report: Checklist
D2－描述问题
1.4W( Who/what/where/when) 是否清晰?
2.2H(How much/How)是否清晰? -不良延伸的数量及严重程度 -如何发生的?什么样的操作模式下使这个问题发生?
D3－围堵措施 1.有否确定有效的围堵措施并有文件/相关信息予以证明？ 2.有否明确临时措施的时间？ 3.措施是否被核实？（需要提供改前和改后的数据对比作为证 4.是否已经选择了最好的临时围堵措施？成本最优化,风险最小 5.所涉及的产品是否已被排查?（供应商端,原材料、半成品、在 制品、在途品,仓库及客户处） 6、所有相关排查是否100%做到，避免遗漏。
D7－预防再发生 1.预防措施是否针对业务、制造、工程、质量、体系控制等环节 的基础流程？ 2.涉及方是否都同意此预防措施？是否有改进的承诺日期？ 3.预防措施是否被完全标准化？ 4.是否有计划实施预防措施？ 5、是否点检及评估了系统改进情况？
D8－结案并祝贺 1、有没有总结相关经验和教训？ 2、有没有选择一种适当的方式来认可团队取得的成果？ istYesNo

网站业务安全checklist编写指南在网络时代，随着互联网的发展，越来越多的业务都开始转移到网上进行，网站也成为了很多企业的重要组成部分。

然而，随之而来的安全威胁也开始不断涌现。

为了保护网站的业务安全，编写一个全面的checklist是十分必要的。

本指南将为您介绍如何编写一个有效的网站业务安全checklist。

一、安全策略1. 网站业务目标：明确网站的业务目标，并进行详细描述。

2. 安全政策制定：制定适合网站业务的安全政策，包括对用户信息的保护、系统访问的控制等。

3. 风险评估和管理：评估网站存在的潜在风险，并制定相应的风险管理措施。

4. 安全团队建设：组建专业的安全团队，负责网站业务的安全管理与监控。

二、身份验证和访问控制1. 用户注册和登录：确保用户注册和登录过程的安全性，包括密码复杂度要求、验证码验证等。

2. 权限管理：根据不同的用户角色，设置不同的权限，确保用户只能访问其可授权的信息和功能。

3. 强制访问控制：对敏感功能和关键数据进行强制访问控制，仅限制有权限的用户进行操作。

4. 反欺诈机制：设置反欺诈机制，识别并阻止恶意用户的访问。

三、数据保护1. 数据备份：定期备份网站数据，确保在数据丢失或受损时可以进行恢复。

2. 数据加密：对用户敏感信息进行加密存储，确保数据在传输和存储过程中的安全性。

3. 安全审计和监控：建立安全审计和监控机制，及时监测网站数据的异常行为和未授权访问。

4. 安全域隔离：根据业务需求，将不同的业务数据进行隔离，确保数据的安全性和完整性。

四、应用安全1. 安全编码实践：开发人员应采用安全编码规范，避免常见的安全漏洞，如跨站脚本攻击、SQL注入等。

2. 应用程序更新和维护：定期更新和维护应用程序，确保修复已知的安全漏洞和问题。

3. 安全漏洞扫描：定期进行安全漏洞扫描，及时发现和修复漏洞，避免被黑客利用。

4. 文件上传和下载：对上传和下载功能进行安全性验证，防止上传恶意文件和非法下载。

销售助理+销售
开发助理+销售 各站点销售 各站点销售 各站点销售 各站点销售
3.1 明确自身目标，紧盯1-3个竞争对手 3.2 共用review 3.3 获得节点排名
各站点销售 各站点销售
3.4 两周内出单量 至少达到30单，欧洲站点挤进 目标排名，美国站点获得new release
各站点销售
3.5 Giveaway设置的注意事项结合30% code Leader
3.6 三周内Listing有评论
各站点销售
3.7 $450一个产品，可竞争激烈的重点产品开始
3.8 一般情况30%-40%的折扣比例
3.9 listing 无垃圾Asin流量进来
各站点销售
3.10 一周内广告陆续出单
3.11 页面上有3个QA 3.12 至少回评1个
各站点销售+Leader辅助 各站点销售
4.上架2月： 稳定产品
第二个月：跟进第一 升转化率 个月的计划循环往 复，持续拉升销量
产品推广
4.上架2月： 稳定产品
第二个月：跟进第一 个月的计划循环往 复，持续拉升销量
4.4 站外facebook广告投放，老用户投放 4.4 Q&A维护：维持Q&A数量与Review比例1:3，增加复 4.5.站内秒杀：通过各种渠道申报站内LD及BD，有条
阶段名称
1.产品准备
目的与意义
具体计划
1.1产品利润核算
销售与开发 配合了 解产品，了解市场环
1.2
产品市场调研
境
1.3信息汇总
2 销售准备
2.1 信息录入——暂定开发和销售录入
2.1.1 SKU，UPC，产品尺寸
2.1.2 MSDS上传

checklist模板实用在我们日常生活和工作中，我们经常需要处理各种各样的事情，有时候可能会让一些事情滑漏。

为了提高工作效率和避免疏忽，使用checklist模板是一个非常实用的方法。

checklist模板可以帮助我们把任务细化、整理和安排，确保我们完成所有必要的步骤。

本文将介绍一些常见的checklist模板以及它们的实用性。

1. 旅行checklist模板无论是商务差旅还是度假旅行，我们都需要做很多准备工作。

旅行checklist模板可以帮助我们列出需要带上的物品，如护照、钱包、手机、行李等。

除了物品清单，还可以列出办理机票、酒店预订、签证办理等的步骤。

这样，我们就可以避免在旅行前或旅途中忘记某些重要的东西。

2. 会议checklist模板参加会议时，我们需要做很多准备工作以确保会议顺利进行。

会议checklist模板可以帮助我们准备演示文稿、会议议程、会议资料等，并列出参会人员名单以避免遗漏。

此外，还可以添加准备会议室、检查会议设备等任务，以确保一切就绪。

3. 项目管理checklist模板项目管理是一个复杂而繁忙的任务。

使用项目管理checklist模板可以帮助我们更好地组织和管理项目。

这种模板可以包括各个项目阶段的任务、里程碑、交付物以及相关的计划和时间表。

通过使用这个模板，我们可以清晰地了解项目的进展情况，并确保按时完成各个阶段的任务。

4. 日常任务checklist模板我们每天都会面对大量的日常任务，例如回复邮件、安排会议、处理文件等。

使用日常任务checklist模板可以帮助我们更好地组织并优化这些任务。

这种模板可以帮助我们列出每天需要完成的任务，并按优先级进行排序。

通过使用这个模板，我们可以明确自己每天需要完成的任务，并及时跟进。

5. 事件筹备checklist模板筹备一个活动或者庆典是一个复杂且需要全面考虑的过程。

事件筹备checklist模板可以帮助我们规划并管理各个方面的任务。

2011/11/14前
5.提供与门店设计相关的资料讯息交门市保管
2011/11/14前
Mark进行中
6.工程交接及验收，门市Key交接
2011/11/14前
待定中
1.提供一份List，确认该门市之物业所提供之清洁、送货、垃圾、维修等服务，及与物业有关之费
用与支付方式（水电费、电话费）
Mark
2.告知门市业绩预估及相关资料
9.开幕活动pop确认
1.确认完成最终工程验收的时间
2.与训练部门一起安排训练计划，执行训练计划并追踪训练结果。
10.建立门市人员通讯簿
市场部
一切与开幕活动有关的行销制作物确认。
11.确定开幕班表的排定
营运部
赵萍；门店完成门店所有人员的通讯录，建议每月更新一次。
12.进货前门市仓库及办公室清洁
2011/11/17前
研发部及营运部
暂定2011年11月7日完成
8.提供清洁剂使用说明
采购部门
外部厂商
与采购部门沟通清洁用品的明细
与外部厂商沟通使用的操作说明和提供门市的资源
9.提供物流相关信息；提供门市三名紧急联系人、送货区域说明
配送厂商
采购部
10.文具、店名章、医药箱、名片、电话、工具箱、验钞机、传真打印一体机、熨斗、烫板的准备（如经理室与吧台分离，请提供子母型电话机
22.确认开幕期行销活动相关制作物和当日的活动流程
23.确认已完成开幕当日的订货
2011/11/18前
14.门市细部清洁
2011/11/18前
15.布置仓库及办公室并建立相关文件
确认所有的进货品项，将物品按照定位图设计摆放。
16.所有设备调试
咨训部完成门市后台电脑的调试，营运部门完成后台的电子文档建立。

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经理、架 构师、运维

整机软件调试是否OK。待机电流，用户手 册，CQ中的A类BUG。
量产前的天线测试报告，是否为开模样品 。否则不予确认。只给针对样品的报告数 据
客户ID是否完成评审、备案。有否和其他 客户冲突接近
客户MD是否完成评审
是否告知客户我司的单机下载工具 是否告知客户我司的多串口下载工具 客户 相关 客户的供应商是否审核完整，包括屏，摄 像头，天线，电池厂家，FPC厂家。目前 要求这5类。大客户的话，喇叭也要求
分类分类项情况最后更新操作时间原因备注项目信息表是否及时更新原理图和摆件评审原理图评审时注意核对功能需求包括哪些资源是复用的而导致有些功能只能两选一等layout评审后续gerber文件的更新变更是否描述清楚是否写明了板子的内存种类拼板大小在文件名中bom归档后的差异料跟踪生产资料核对钢网的制作安排
客户第一次小批量装机的跟踪需要，和聂浅进行沟通。
若前期评审有错，以最后一次改进时间为准 。如果客户没有把改进的MD发来，此处留 空并且跟催。完成标志是必改项为0 保存校准参数的方法等。
需要签署封样的，例如中宝的，留有签署封 样的文件
生产资料核对，钢网的制作安排。有否因 为特殊机型需求，区别钢网，堵住某些开 孔等
过程 PR1试产前，软件的安排准备
PR1试产前，外围料安排准备，LCD，摄像 头，按键板等供调试用
样品要求器件上带有规格型号。
第一次发布正式版本前，对软件共性问题 的提前预防和监督。使得V001对测试部而 言有意义。
PCBA的调试结论是否给出，作为量产投板 依据
XY项目备忘
分类
分类项
情况
最后更新/操作时间
原因备注
项目信息表是否及时更新 原理图和摆件评审
原理图评审时注意核对功能需 求，包括哪些资源是复用的而导 致有些功能只能两选一等

CIT测试频段 作业指导书 工艺流程图 包装工艺要点 读写IMEI工具 IMEI号段提供 手机背贴格式及可打印性 彩盒标签格式及可打印性 外箱标签格式及可打印性 包装清单要求 出货栈板方式 打包袋方式 生产测试用 QC检测用 成品出货检验标准 来料是否通过IQC检验 物料检验承认书和样品 品质异常协议确认 出货检验方式 收料方式 帐务管理 物料盘点 出货方式
新产品导入技术状态跟踪表
NPI Checklist
客户 产品描述 序号 1 2 3 机型/项目 类别 项目团队 BOM 样机 跟踪项目 客户项目团队 易兴通团队 组装 包装 整机样机 软件下载 软件下载工具 测试设备和仪器 测试用数据下载线 测试用夹治具 作业指导书 工艺流程图 组装工艺要点 制程类别 组装夹治具 工程模式指令 单项测试指令 硬件平台: 投产时间: 技术状态 □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □有铅 □无铅 □ROHS □非ROHS □LCD焊接 □DOME粘贴 □LED灯折弯/焊接 出货时间: 技术说明
4
主板测试
5
组装
□Other_____
□易兴通自制
6
组装测试
MMI测试项目
□OK □NG □N/A □OK □NG □N/A 在线全测: □拍照 □触屏 □LCD背光 □振动 □MIC □受话器 □扬声器 □按键 □充电 □蓝牙 □闹钟 □传感器 □键盘灯 □T卡读取 □软件版本 □SIM卡切换 □FM收音机 □TV搜索 □LED手电筒 QC抽检: □MP3 □MP4 □摄像 □录音 □拨号 □通话音质 □蓝牙耳机 □短信 □铃声 □图片预览 两频:□GSM900/DCS1800 □GSM850/PCS1900 三频:□GSM900/DCS1800/PCS1900 □GSM850/DCS1800/PCS1900 □CDMA模块 □Other______ □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A 电池30pcs/产线、耳机6pcs/产线、充电器6pcs/产线、下载线4pcs/产线 电池4pcs、耳机2pcs、充电器2pcs □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A □OK □NG □N/A 单项不良低于: □3% □2% □1% □Other □易兴通QC检验 □客户QC在线抽检 □客户QC线外抽检 □易兴通领取套料 □供应商发货到易兴通 □客户提供套料 □易兴通整理电子表单 □导入客户系统软件终端管理 □入易兴通系统帐 □ Other □按订单批次盘点 □月盘点 □Other □易兴通送货 □客户自提 □客户委托物流公司提货

checklist流程Checklist流程引言作为一名资深的创作者，我们经常需要按照一定的流程来完成工作。

而使用checklist流程可以帮助我们更高效、更系统地完成任务，避免疏漏和错误。

本文将详细介绍如何使用checklist流程来提升工作效率。

1. 制定任务清单首先，制定一个任务清单，列出需要完成的所有任务。

可以使用Markdown格式来记录清单。

例如：•☐完成市场调研•☐撰写第一版初稿•☐进行内容校对•☐进行排版和设计•☐进行最终审阅•☐发布作品2. 分解任务将主要任务逐步分解为更具体的子任务。

这样可以更清晰地了解需要完成的工作内容，并可以更好地掌握进度。

例如：•☐完成市场调研–☐了解目标受众–☐研究竞争对手–☐收集相关数据3. 设定优先级根据任务的重要性和紧急性，为每个任务设置优先级。

这样可以更好地安排工作时间和资源。

例如：•☐完成市场调研（优先级：高）•☐撰写第一版初稿（优先级：中）•☐进行内容校对（优先级：中）•☐进行排版和设计（优先级：低）•☐进行最终审阅（优先级：低）•☐发布作品（优先级：低）4. 设置截止日期为每个任务设置截止日期，以确保任务能按时完成。

根据任务的复杂性和优先级，灵活地安排截止日期。

例如：•☐完成市场调研（截止日期：5月30日）•☐撰写第一版初稿（截止日期：6月5日）•☐进行内容校对（截止日期：6月10日）•☐进行排版和设计（截止日期：6月15日）•☐进行最终审阅（截止日期：6月20日）•☐发布作品（截止日期：6月25日）5. 监督和反馈在大项目或团队协作中，及时监督和反馈是必不可少的环节。

定期检查任务完成情况，并向团队成员提供反馈。

例如：•☐完成市场调研（状态：进行中，负责人：张三）•☐撰写第一版初稿（状态：未开始，负责人：李四）•☐进行内容校对（状态：未开始，负责人：王五）•☐进行排版和设计（状态：未开始，负责人：赵六）•☐进行最终审阅（状态：未开始，负责人：孙七）6. 完成任务按照任务清单、分解、优先级和截止日期的安排完成每个任务。

36
]
评分 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 36
得分
佐证记录及说明
题的发生？
0
4. DOA售后维修
评分说明：每] ] 总分 [
程序文件 是否有清楚的程序文件去定义DOA的作业流程？ 是否有清楚的程序文件去定义客户退机类别及处理流程，如DOA,RA,ECO etc. 是否有程序文件去定义RMA系统管理流程及相关数据的管理要求？ 是否有文件定义针对不同RMA机器的判断&验证流程？ 产品存储 是否有文件定义RMA机器分析及维修时间不得超过30天？ 是否有清楚的定义不同客户，不同产品的区域规划？以防止产品的混淆？ 是否有针对RMA区域进行单独空间规划，不得与正常生产车间相混淆？ 系统管理 是否可以确保RMA中心使用的SW image是经过客户确认并验证OK？ 是否可以确保RMA中心使用MES系统是与工厂数据库完全隔离的？ 是否有流程可以清楚的鉴别出二次退机，三次退机的产品？ 是否有明确的规定，不允许维修3次退机产品，给予直接报废处理？ 是否有系统可以查询并追溯所有的RMA机器报废记录及明细？ 是否有定期的整理RMA相关数据给到工厂，以便工厂提出改善对策预防同类问题的发生？ 是否有文件明确定义，快速的反馈DOA机器分析进度及结果给到客户？ 是否有完善的机制去确保RMA中心的所有备件都是充足的？ 是否有独立的RMA测试区域去满足产品的测试要求？ 是否有完善的MES系统去收集产品测试的相关信息，并做定期的改善分析？ 是否有完善的机制去确保RMA中心的ESD状况良好？（ESD测量；ESD audit）

、 工 程……等 6〃决定查检表的格式。（图形或表格） 7〃决定查检记录的方式。如：正、++++、 △、√、○
四、制作的方法
1.
点检用查检表 A〃详列点检项目 B〃顺序 C〃层别 D〃可先用，如不符合再改善
2〃纪录用查检表
A〃列出所需的项目及所需要收集的数据 B〃决定格式 C〃决定记录的方式。如：正、++++、△ 、√、○。 D〃决定收集数据的方法
查检表(Check list)
一、目的：
1〃确认作业过程中,防止作业疏忽或遗漏
2〃利于资料的记录
二、种类
1〃点检用查检表:在设计时既已定义使用
的，只做是非、仪器保养维护的实 施状况或为预防事故发生，以确保使用时 的安全。此类检查表主要是确认检核作业 过程中的状况，以防止作业疏忽或漏洞。
五、制作要点
1〃如可以可先行参考他人的实例 2〃愈简单愈好 3〃一目了然
4〃以TEAM
WORK 方式进行，集思广益
六、实例说明
2〃记录用点检表：此类查检表是用来搜集
计划资料，应用于不良原因和不良项目的 纪录，作法是将数据分类为数个项目别， 以符号、划记或数字纪录的表格或图形。 由于常用于作业缺失，品质良莠等纪录， 故也称为改善用查检表。
三、制作检查表应注意的事项
1〃明了制作检查的目的 2〃决定查检的项目 3〃决定查检的频率 4〃决定查检的人员及方法 5〃相关条件之记录方式,如作业场所、日期

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）的使⽤--测试检查表checklist很常见，各⾏各业都有，但是作为电信运营⽀撑系统这样⼤的软件系统的实施和开发，却。

检查项⽬并不是⼀成不变的，也不是随便想⼏个就可以的，否则会成为摆设。

⼀定得要有过程管理思想并深刻体会到其中的关键点进⾏监控。

每个团队、每个时期都是动态变化的，checklist是⼀种动态的⼯具。

除了过程，可以使⽤在其他⽅⾯，例如：各种评审。

checklist可以让⼯作标准化，但是快速发展的团队和⾼效⼯作似乎不需要标准化？错，这要看checklist的内容是什么。

总会有需要checklist的地⽅并且能起到真正的作⽤。

测试⽤例检查表是否每个⽤例测试⼀种单独的情况⽤例是否有测试数据⽤例是否有预期结果是否明确描述了测试数据的异常值、正常值、边界值预期结果是否可以再现测试⽤例是否分级展现是否有数据恢复脚本是否有优先级是否是可⽤状态（ready）每个⽤例是否覆盖了测试需求是否有设计时间(⽤例完成设计的时间)是否被评审过测试场景检查表场景是否由⽤例组成的场景是否有优先级是否每个场景中的⽤例已经run是否被评审过测试需求检查表涉及到数据库连接是否明确了连接个数和⽅式是否每个测试需求相对独⽴测试需求之间不应该存在因果关系测试需求中不应该存在模糊描述（⼤量、很多、长时间等等）测试需求的来源是否可靠（不会被随意改动）测试需求描述是否清晰⽆歧义是否被评审过是否设定了优先级测试需求是否包含了业务需求是否把复杂的业务需求分解了是否每个测试需求都有明确的输⼊输出，便于测试defect检查表是否描述清晰:出现问题的环境简要描述是否描述清晰:出现问题的操作过程描述是否描述清晰：问题现象描述清楚是否提出了⾃⼰的分析是否指定了解决⼈是否跟踪了每⼀个⾃⼰的bug是否有未关闭的bug是否提出bug之前检查了没有⼈已经提出来过（不重复）是否每个defect描述⼀个独⽴的问题是否及时修改了defect状态是否填写了应该填写的字段不能带有主观的对程序的评价bug描述中不能带有疑问句是否填写了优先级是否填写了严重程度测试计划检查表是否符合项⽬⾥程碑时间要求是否安排好了执⾏时间计划是否安排好了执⾏⼈计划计划安排是否粒度到天（周）是否有测试⼈员培训计划第⼀、描述了项⽬的⽬的第⼆、描述了项⽬的开发周期第四、描述了测试案例的设计周期第五、描述测试案例的执⾏周期第六、描述了测试过程中⽤到的⼯具或者技术第七、描述了测试过程中⽤到的资源情况每⼀部分测试计划时间安排是否有冲突是否有测试过程检查机制测试过程检查是否涉及到其他组是否取得了相关组的认可是否经过了有项⽬经理参加的评审是否有测试执⾏⽇报告机制是否有风险分析以及规避⽅法是否有测试环境描述是否有测试⼈员协作机制是否有测试⼈员考核点描述并且可⾏是否有其他组协作机制描述测试环境更新检查表是否是在确认了版本⽆误的情况下更新的是否有配置⽂件更新是否可执⾏程序权限正确是否记录了编译错误并报告更新后是否做了冒烟测试更新后是否记录了更新过程如果更新步骤或内容有变化是否同步更新了作业指导⽂档更新问题是否提交到CVS更新问题是否通知到相关⼈员是否记录了本次更新经验（版本更新⽇志）测试⽅案检查表是否描述了测试⽅法是否描述了测试参与⼈员是否描述了测试环境是否描述了⼈员协作办法是否相关⼈员已经通知到是否描述了测试内容测试内容时候细化到模块是否描述了测试时间安排是否描述了测试⼈员培训安排是否描写了测试说明章节是否进⾏了换位思考（别⼈能读得懂吗）是否有备份⽅案是否经过评审准备测试评审检查表是否提前给开发组和项⽬经理以及相关⼈员发送了评审材料是否预定了会议室和预约了合理的时间是否准备了与会材料和⼯具（投影机等）是否主讲者已经演练了⼀下是否最好了被推翻重来的准备是否做好了听取改进意见的准备是否做好了改变原有思路的准备是否做好了⼤家都没有意见的准备是否做好了需要⼆次评审的准备是否做好了由于各种原因评审会失败的准备是否检查过了被评审材料压⼒测试检查表是否已经清楚了实际业务的压⼒情况是否已经预估了业务发展趋势和量化了增长速度是否预估了产品的⽣命周期是否预估了产品⽣命周期内业务量可能的峰值是否统计了业务峰值时间段以及峰值业务量是否已经明确了⽣产系统的主机分布。

本文分析了做后台数据cheklist需要注意的十个方面：需要哪些数据（业务）、数据的来源（技术）、数据操作、数据批量上传、数据校验、数据展示方式和性能、数据实时性要求、数据计算规则（口径）、历史数据和版本处理记录、数据变更。

做后台，经常需要跟一些数据打交道，稍不注意，坑就在那里。

虚拟场景：当业务方跟小明说，我们要加一个很简单的数据。

小明分析了产品需求，觉得场景上来说是合理的真需求，业务确实需要，我们也有这个数据，见过别的地方用到了，那就这样提需求吧。

到了需求会上，小明说出了自己的来意。

研发说：数据从哪里来的？哪个数据表？需要校验码？加上这个数据要计算，展示性能我没办法保证啊，大概需要3秒才能展示出来，你能接受吗？实际上：我们可能不会像小明一样被问的这么惨，但是确实存在遗漏的情况。

那么我们究竟应该考虑哪些方面呢？我列举了十个方面：接下来详细介绍：第一步这个算是产品的本命了，老生常谈系列。

当业务方给你提一个数据的需求，你需要了解需求的场景，他们处于什么样的目的想要这个数据。

我们要做的就是分清真伪需求，找到他们的根本目的是什么？比如业务方说，给我展示一下每个课程里面的视频学生学习了多少秒？我看下学习情况。

你继续追问下去，才发现他们是因为需要计算运营的KPI，定了一个指标是学生的到课率，想看看每个班级到课率的情况。

那最后的产品方案也是不一样的。

得到业务真正需要的数据，是产品应该做到的。

数据从哪里来，数据要到哪里去？很多时候数据从哪里来（在哪个业务群的哪张数据表或者接口里可以用到）是研发需要考虑的问题或者是需要运营手动输入的。

但是因为数据的来源会带来一些产品需求上的变动，甚至需要一些流程上的变更进而影响了需求的时间点，所以产品经理最好也能考虑到。

比如数据源是其他业务群的数据，那么这个数据我们是从接口里获取吗？现在有这个接口吗？现在的接口支持批量获取吗？一旦没有或者不支持，我们就需要提前向别的业务群提需求，或者咨询开发还有没有其他的方式得到。