经典项目管理表格系列之7、Check list及分工
供货商检查表Check List(QPA)
无 系 统
需 改 善
满 意
优 秀
得 分
0 0.5 1 1.5
核准：
品保主办：
工程主办：
采购主办：
项目
调查内容
无 系 统
需 改 善
满 意
优 秀
得 分
0 0.5 1 1.5
3.公司被测试之使用的文件是否有适当的被管制？
4.客户是否可荻得产品适当的可靠度测试数据？
5.可靠性测试作业是否有适当的书面化之程序文件？
无 系 统
需 改 善
满 意
优 秀
得 分
0 0.5 1 1.5
核准：
品保主办：
工程主办：
采购主办：
项目
调查内容
10.所有物料都有相应标识显示其状态(良品、不良品、原材料、半成品、成品等)？ 11.有无物料先进先出之管制?执行成效如何？
六.培训
1.公司人力资源政策是否有明确的书面规定：禁止招募、使用童工(16岁以下)，规定有无切实执行？ 2.有无文件化的培训程序？培训记录是否完整并保存？ 3.有无确定与质量有关所有人员培训需求之系统？有无按培训需求制定培训计划并依计划实施培训？ 4.所有与质量有关人员特别是检验人员及重要制程作业人员是否必须接受过相应培训且合格后方能上岗？ 5.有无规定接受培训人员之考核方法(理论考试或实践考试)？考核结果是否作为相应人员合格上岗之依据？ 七.文件管制 12..公有司无有文否件通化过的相文关件管管理制体程系序之明认确证定（义如管I制SO文90件01范等围）(？质量手册、程序文件、设计文件及技术图面、作业说明书、稽 核文件等)并保证管制文件确实受控？ 3.能否保证所有与质量有关人员易于得到恰当且现行有效管制文件？过时或作废文件是否及时从所有使用场所撤走？ 4.有无规定控制文件之审核权限？控制文件在发布前是否经受权人员审核通过？ 5.有无客户产品标准及工程变更转化系统以保证客户标准或工程变更能够及时被使用场所(检验、生产)得到并执行？ 6.质量记录有无保存时限规定？质量记录是否能充分证明质量系统运行之有效性并作改善之依据？ 八.可靠性测试 1.适当的最终测试与产品可接受度是否有纳入检验规范？ 2.首件产品是否有执行相关的测试？
项目管理部门职责表
3、完善和健全安全管理各种台帐，强化安全管理工作，负责各种安全记录资料的填制，收集和立卷工作。
4、负责完善本项目各类安全生产制度，消防保卫工作制度，ቤተ መጻሕፍቲ ባይዱ有针对性地制定安全生产细则。
5、监督分包商认真执行安全、保卫、消防、环保法规、条例、标准和规定的实施。
2、对工程的技术质量负总责；制定严格的管理制度和措施，按照国家规范和业主方的要求严格控制现场的施工质量。
3、对工程的施工质量负有技术责任、检查监督责任，进行工程质量的最终控制。
4、定期组织召开技术、质量例会，组织召开专题质量分析会。
5、参加招标人组织的设计交底和图纸会审会议。
技术部
1、负责日常的工程技术管理，参与工程的检查和验收工作。
7、负责技术资料的收集整理和归档工作。
质量部
1、负责本工程质量计划的编制工作，组织制定各分部分项工程的质量验收标准；按质量文件与合同要求，实施过程质量控制的检查、监督工作；组织工程验收。
2、负责对验收批、分部、分项工程及最终产品的检验，参与最终产品的质量评定工作，独立行使施工过程中的质量监督权力。
3、对施工全过程进行质量控制，对不合格产品坚决不予放行，待其进行整改后再行检查验收。严格控制无质保文件和不符合技术规范要求的材料设备进入现场。
4、协调各专业承包人和专业作业队伍之间的进度矛盾及现场作业面冲突，使各分包商之间的现场施工有序合理地进行。
5、具体抓项目的进度管理，从进度计划、实际进度和进度调整等多方面进行控制，确保项目如期施工。
6、进行施工质量的过程管理和控制，对工程的施工质量负责。
7、进行施工现场的标准化管理。
项目管理职能分工表
项目管理职能分工表一、项目管理职能概述项目管理是指对项目整个周期中的规划、执行、监测和控制的过程进行管理。
在一个项目中，各个职能部门需要紧密配合，共同完成项目的目标，保证项目成功交付。
因此，项目管理职能的分工非常重要，不同职能部门需要各司其职，确保项目的顺利实施。
二、项目管理职能分工表1. 项目规划项目规划是项目管理中的重要部分，其主要职能是制定项目计划并确保实施顺利，同时评估潜在风险和机会，确保项目的成功交付。
(1) 项目经理项目经理是项目规划的主要负责人，其职责包括：制定项目计划，协调项目相关的职能部门，确保项目实施的顺利进行，监测项目进展情况，及时调整项目计划。
(2) 项目团队项目团队是项目规划的主要成员，其职责包括：对项目进行深入分析，制定项目目标和计划，评估风险和机会，制定相关策略，确保项目计划的成功实施。
(3) 项目管理办公室项目管理办公室是负责项目管理的中心部门，其职责包括：监控并审查项目目标和计划的实现情况，评估项目的潜在风险和机会，协助项目经理修订项目计划，确保项目成功交付。
2. 项目组织与交付项目组织与交付是项目管理中最重要的职能之一，其主要职责是确保项目目标的成功实现，协调各个部门的合作，保证项目交付质量。
(1) 项目经理项目经理是项目组织和交付的主要负责人，其职责包括：监控项目进度，确保项目质量符合要求，协调各个部门的工作，及时解决问题并纠正偏差，保证项目成功交付。
(2) 项目团队项目团队是项目组织和交付的主要成员，其职责包括：协调各个部门的工作，共同完成项目目标，检查产品质量，及时解决问题并纠正偏差，确保项目成功交付。
(3) 质量保证部门质量保证部门是负责保证项目交付质量的重要部门，其职责包括：分析和审核项目交付产品的质量，确保其符合相关标准和规范，评估产品的可靠性和安全性，并及时提出改进意见。
3. 项目监控项目监控是贯穿整个项目生命周期的过程，其主要职责是监督项目进展情况，及时识别和纠正偏差，确保项目按照计划进行。
项目管理方法-检查清单模板
检查清单在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由项目管理室那样的支持项目管理的组织在项目审查和监督的成功案例和失败案例的基础上作成。
检查清单或者模板是组织的最佳实践，通过这些经验的积累可以提高项目管理的效率，有助于防止失败。
检查清单用于确认作业或工程是否存在遗漏。
模板作为产出物的雏形式样，具有WBS、网络图、需求变更书、进展报告书、合同标准文件等形式。
通过雏形的灵活运用，经验较浅的项目管理者可以明白必须做些什么，并能在其他项目中重复利用。
软件开发项目管理检查清单：天气晴雨表检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。
下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加详细。
通过这个清单，可以发现项目管理存在的问题，并采取措施加以改善。
需求式样晴雨表? 是否存在稳定的、完整的、书面的需求式样？? 是否已经就需求事项煞费苦心地与顾客进行了沟通和确认？? 是否存在需求式样尚未确定就以“暂定式样”开始作业而事后返工的情况？? 是否为了确认顾客的需求而对“需求式样书”进行了审查？? 是否根据顾客提供的产品式样书而直接进入了设计作业？? 是否在作业途中不断变更或追加需求式样？? 是否按照项目编号规则对每项需求赋予了惟一的编号？? 是否已经明确顾客方的项目推进体制以及最终决策者？? 是否摄于顾客的特权优位性而不经讨论地接受顾客的需求变更？? 是否在远远超越自身能力而根本无法完成的情况下不能清楚地说“不”？? 是否在作业已经进入测试阶段后还发现需求式样理解有误？? 是否以单一窗口接收顾客的需求，确保一窗口输入？? 项目组成员的作业是否基于最新需求信息，而不是已经失效的历史信息？项目计划晴雨表? 是否将估算视为一种特殊的技能，并将估算当作一个小项目？? 是否定期对项目计划实施重新估算并根据实际情况加以调整？? 是否对作业文档等成果物的“量”进行了估计？? 是否以适当的单位进行了作业量的估计？? 项目作业是否具有详细的日程表？? 日程表确定之后，如果和实际情况出入较大，是否进行了调整？? 是否接受了不切实际的开发日程，而其结果是，日程表仅仅成为一种形式？? “工作量”和“难易度”是否会因为担当者的不同而出现巨大变动？? 是否因为实际进展超前于计划而没有思考项目计划本身存在的精度问题？团队管理晴雨表? 是否存在明确的软件开发行动单位：团队？? 是否虽然叫作团队，但是并没有认识到协作而是专注于工作任务的分担？? 管理者是否仍然承担以前作为技术者所承担的具体开发作业任务？? 项目管理者是否仅仅根据自己的经验而将需求式样直接分派给“个人”？? 项目管理者是否总是认为项目没有什么值得注意的问题？? 团队成员是否知道项目作业内容的相互关系及其优先级？? 是否在项目启动之后仍然还有项目组成员感到无所事事？? 是否经常有特定的项目组成员总是加班到深夜？? 团队成员是否知道并遵守统一的作业规范？? 是否从作业流程上、从团队协作上追究过程序缺陷的真正原因？? 团队成员是否在相互察看成果物后产生提高自己的作业水平的意识？? 当问题难点解决之后，是否向项目组成员介绍解决该问题的思维和方法？? 项目组成员的出勤时间是否经常相差很大而不寻找原因？? 项目组成员在遇到技术难题时是否与项目组其他成员沟通并寻求支援？? 项目组成员在讨论问题时是否出现无条理的、非建设性的讨论？作业流程晴雨表? 是否存在专注于组织整体的开发作业和项目流程的人或者小组？? 是否存在项目开发作业的标准作业流程？? 是否存在记述顾客需求式样的文档标准？? 是否存在设计书的文档标准？? 是否不经过设计阶段而直接进入编码阶段？? 设计阶段是否实施了以设计为对象的审查？? 编码阶段是否实施了以代码为对象的审查？? 中途式样变更后，是否未经其影响范围的分析就直接分配给担当者？? 是否未经单体测试就直接开始综合测试？? 是否时至最后才发现此前隐藏的诸多问题？? 是否无视已经发现的问题而继续推进作业？? 是否多次重复出现以前相同的错误而没有吸取教训？? 是否没有专门的测试人员而在交付之前还是由开发者自己实施测试？? 对式样需求是否确立了适当的测试项目？? 测试是否几乎没有自动化手段？? 过程改善方面是否存在可以商量和咨询的人员？? 是否鼓励各开发小组写作事后分析报告，至少能就项目进程开会讨论？? 是否组织正式的活动，就软件开发与质量控制流程的相关问题相互切磋？项目配置晴雨表? 是否在发现潜在的缺陷时难以确定其对现有模型的影响范围？? 是否只有担当者知道而没有向所有成员公布缺陷的修正范围和修正方法？? 是否因为修改一个程序缺陷而引发多个新的缺陷？? 担当者是否能在任何时间对源程序做自由的变更？? 开发期间是否定期对制作过程中的文件和程序进行备份？? 是否确立了资源备份在非常时期的因应方式？? 需求式样书和设计书等正式文件是否存在“确认”手续？? 项目文档是否一直保持最初的状态，即使在式样变更后仍然没有变化？? 是否在项目后期难以想起中途式样变更的“理由”？? 对于程序缺陷和式样变更，是否能追踪其修改点？? 对于开发环境目录中的旧代码是否难以判断其能否删除？? 开发文档是否会出现链接到旧版本的情况？教育培训晴雨表? 是否描绘出现在的开发组织多年后的“风姿”？? 在组织上，是否对现在的人员实施技术性教育和培训？? 是否确立了员工教育培训的计划和目标？? 是否将技术学习视为个人任务而没有组织上的“方向”？? 项目开发人员所持有的软件开发文献的平均数量是否在1册以下？? 项目作业休息时间是否毫不涉及崭新技术方面的话题？? 项目组成员是否不知道软件工程的意思？? 是否不了解“凝聚度”、“结合度”等词汇的意思？? 是否难以说出5个以上的软件质量特性及其副特性？项目审查晴雨表? 参与者是否了解审查的整体流程？? 是否带着目的而非盲目地实施审查作业？? 是否仅仅局限于代码审查而不顾及其他？? 审查者是否只关注形式而非实质？? 是否明确审查对象物，针对“物”而非“人”？? 是否记录审查结果并追踪缺陷修正结果？? 是否将审查的反馈结果导入下一项目中？? 审查会议是否演化成为问题解决会议？其他? 是否采取了数据备份以及病毒防范等措施？? 对电子邮件的应对是否总是滞后？? 是否感到电子邮件的应对很繁琐？。
项目文档Check List
29
QA试产检查
30
QA外观、功能检查
31
QA结构评价
32
AM评价
33 34
项 目 检
ID评价 HW测试
35 36
测 与
PRT MFG试生产报告
37 评 QA汇总
38 价 PL评价
39
环境物质调查
完成后由QA汇总到《项目评价报告》中， 并按附件形式归CQS，
ISSUE由PM汇总到《ISSUE LIST》中
40
客户特殊要求评价
41
验证性评价
42
试用报告
43 部品 部品评价
44 附件 附件评价
45 评价 Spec认定
阶段
1）按《阶段目标评价》check list进行；2）每次试生产结束后
46 目标 阶段评价
的第2-3周内进行；3）完成后归CQS，4）ISSUE归《ISSUE
评价
LIST》
及时生成：1）PR1（EP1）试生产结束的第3天生成，2）每次
总结会：15个工作日内
DCC归档发布前确认是否评审（评审表有否），是否归CQS
细化的文件LIST
项目：
Owner:PM
标准要求
DP DR EP SP PP MP 备注
◎○●
◎●
◎●
◎●
◎●
●○○○
◎● ◎●
●○○ ● ● ● ◎● ◎● ◎◎●
◎● T1 T2
◎● T◎1 T●2 P1 P2 ◎● P1 P2 ◎◎◎●
试生产的2周内附件形式提交QMS-CQS，3）PR3（无PR3时
47
ISSUE LIST
PR2）（SP）开始每周更新，发布给项目组成员和各部门主管
QC7大手法第三章检查表
六、检查表制作要点
查验表的制作，可任意配合需求目的而作更改 ，故没有特定之形式，但仍有几项重点是制作 时间特别留意的：
1 、并非一开始，即要求完美，可先行参考 他人的例，模仿出新的，使用时如有不 理想，再行改善。
2 、愈简单俞好，容易记录、看图，以最短 的时间将现场的数据记录下来。
3 、一目了然，查验的事项应清楚陈述，使 记录者在记录问题的同时，即能明了所 登记的内容。
2
三、检查表制作应注意的事项
1 明了制作查检表的目的。 2 决定查验的项目。 3 决定查验的频率。 4 决定查验的人员及方法。 5 相关条件之记录方式，如作业场所 、
日期、工程…等。 6 决定查检表格式。（图形或表格） 7 决定查检记录的方式。如：正、
+++、△、√、○。
3
四、检查表的制作方法 1 点检用查检表之制作方法： 列出每一需要点检的项目。
2、资料是否集中在某些项目，而各项目间之差异为何? 3、某些事项是否因时间的经过而有所变化? 4、如有异常，应马上追究原因，并采取必要的措施。 5、查验的项目应随着作业的改善而改变。 6、事实现物的观察要细心、客观。 7、由使用的记录即能迅速判断，采取行动。 8、查检责任者，明确指定谁来做，并使其了解收集目的及
第三章 检查表（Check sheet; Check list) 一、定义
检查表是使用简单易于了解的标准化图形 ，人员只需填入规定之检查记号，再加以统计 汇整其资料，即可提供量化分析或比对检查用 者谓之，亦称为点检表或查核表。
1
二、检查表的分类 一般而言检查表可依其工作的目的或种
类分为下述两种。 1 点检用查检表：在设计时即已定义使
比较其差异性。 15 、查检表完成后可利用柏拉图加以整理，以便掌握问题
LPA检查表(生产管理人员及质量工程师适用)
11
IQC检验时是按照规定的抽样标准在抽取样 本吗?
进料检验不良时,不合格品的处理是否按规 12 定及时间处理?有无超过规定期限未处理情
况?
13
对生产中发现的来料不良,IQC是否及时进行 处理?
M03-01-W01-07
平和精工（太仓）
1/3
内容版本：01
Action Owner 负责人
Remark 备注
15
制程PPM达到目标了吗?如果没有,相关的行 动由谁在主持展开?Q图每日都有更新吗?
16
来料有合格标识并作追塑性记录吗?对来料 不良有标示隔离吗?
17
有作业前的点检表格并记录按要求实施了吗 (手拿已填好的记录来一项一项检查)?
防错样件确认其保存完好(清洁,在有效期
18
内),并在防错点检中被使用.(随机抽查一 个,能证明被有效检测)？同时验证产线所有
Check Record / 检查记录
Y/N? 判定
Dept. 部门
3
待验区物料摆放是否整齐，物料的批次号是 否有按先入先出要求整理？
4
IQC检验出的不良品是否及时与良品作出区 隔?标示是否明确？
5 发料是否实行先入先出?
良品退库是否保留了原有标签或复制原来标 6 签(需有零件号、数量、LOTNO等信息）？
Check Record / 检查记录
Y/N? 判定
Dept. 部门
23
预防性维护记录按计划实施了吗?抽查至少 一周的记录
24
所有的工装,治具,测量仪器等工具有完好无 损的编号吗?有指定有效期的有效吗?
25 现场产品追溯记录是否完整?
26 信息看板保持最新状态吗?
27
对该项目过去发生的客户投诉,相关员工清 楚吗?有反映到现有制程控制的措施吗?
check list的几大要素
Checklist的几大要素
Checklist的几个重要要素是：项目/任务、步骤、条件和标记（或勾选）方式。
1. 项目/任务：Checklist的首要要素是明确列出需要完成的项目或任务。
这些项目可以是工作任务、检查清单的事项、待办事项或需要遵循的步骤。
2. 步骤：每个项目或任务通常包含一系列需要执行的步骤。
步骤是指完成项目所需的行动或操作。
逐步明确列出这些步骤，可以确保在执行任务时不会遗漏关键细节。
3. 条件：Checklist的有效性还需考虑任务执行的条件。
条件是指完成项目或任务所需满足的先决条件、环境要求或其他相关情况。
在Checklist中包含适当的条件，有助于确保在适当的环境下执行任务。
4. 标记/勾选方式：Checklist的目的是跟踪任务完成情况。
为了实现这一目标，需要一种标记方式来记录已完成的步骤或任务。
常见的标记方式包括打勾、打对号、使用符号或颜色等方法。
这些要素的组合构成了一个完整的Checklist。
通过明确描述项目、步骤和条件，并使用适当的标记方式，Checklist 可以提供一个简单而有效的工具，帮助人们管理任务、确保重要步骤不被忽略，并提供一种可视化的方式来追踪任务的
进展。