下载文档原格式
项目管理职能分工表一、项目管理职能概述项目管理是指对项目整个周期中的规划、执行、监测和控制的过程进行管理。
在一个项目中，各个职能部门需要紧密配合，共同完成项目的目标，保证项目成功交付。
因此，项目管理职能的分工非常重要，不同职能部门需要各司其职，确保项目的顺利实施。
二、项目管理职能分工表1. 项目规划项目规划是项目管理中的重要部分，其主要职能是制定项目计划并确保实施顺利，同时评估潜在风险和机会，确保项目的成功交付。
(1) 项目经理项目经理是项目规划的主要负责人，其职责包括：制定项目计划，协调项目相关的职能部门，确保项目实施的顺利进行，监测项目进展情况，及时调整项目计划。
(2) 项目团队项目团队是项目规划的主要成员，其职责包括：对项目进行深入分析，制定项目目标和计划，评估风险和机会，制定相关策略，确保项目计划的成功实施。
(3) 项目管理办公室项目管理办公室是负责项目管理的中心部门，其职责包括：监控并审查项目目标和计划的实现情况，评估项目的潜在风险和机会，协助项目经理修订项目计划，确保项目成功交付。
2. 项目组织与交付项目组织与交付是项目管理中最重要的职能之一，其主要职责是确保项目目标的成功实现，协调各个部门的合作，保证项目交付质量。
(1) 项目经理项目经理是项目组织和交付的主要负责人，其职责包括：监控项目进度，确保项目质量符合要求，协调各个部门的工作，及时解决问题并纠正偏差，保证项目成功交付。
(2) 项目团队项目团队是项目组织和交付的主要成员，其职责包括：协调各个部门的工作，共同完成项目目标，检查产品质量，及时解决问题并纠正偏差，确保项目成功交付。
(3) 质量保证部门质量保证部门是负责保证项目交付质量的重要部门，其职责包括：分析和审核项目交付产品的质量，确保其符合相关标准和规范，评估产品的可靠性和安全性，并及时提出改进意见。
3. 项目监控项目监控是贯穿整个项目生命周期的过程，其主要职责是监督项目进展情况，及时识别和纠正偏差，确保项目按照计划进行。
检查清单在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由项目管理室那样的支持项目管理的组织在项目审查和监督的成功案例和失败案例的基础上作成。
检查清单或者模板是组织的最佳实践，通过这些经验的积累可以提高项目管理的效率，有助于防止失败。
检查清单用于确认作业或工程是否存在遗漏。
模板作为产出物的雏形式样，具有WBS、网络图、需求变更书、进展报告书、合同标准文件等形式。
通过雏形的灵活运用，经验较浅的项目管理者可以明白必须做些什么，并能在其他项目中重复利用。
软件开发项目管理检查清单：天气晴雨表检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。
下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加详细。
通过这个清单，可以发现项目管理存在的问题，并采取措施加以改善。
需求式样晴雨表? 是否存在稳定的、完整的、书面的需求式样？? 是否已经就需求事项煞费苦心地与顾客进行了沟通和确认？? 是否存在需求式样尚未确定就以“暂定式样”开始作业而事后返工的情况？? 是否为了确认顾客的需求而对“需求式样书”进行了审查？? 是否根据顾客提供的产品式样书而直接进入了设计作业？? 是否在作业途中不断变更或追加需求式样？? 是否按照项目编号规则对每项需求赋予了惟一的编号？? 是否已经明确顾客方的项目推进体制以及最终决策者？? 是否摄于顾客的特权优位性而不经讨论地接受顾客的需求变更？? 是否在远远超越自身能力而根本无法完成的情况下不能清楚地说“不”？? 是否在作业已经进入测试阶段后还发现需求式样理解有误？? 是否以单一窗口接收顾客的需求，确保一窗口输入？? 项目组成员的作业是否基于最新需求信息，而不是已经失效的历史信息？项目计划晴雨表? 是否将估算视为一种特殊的技能，并将估算当作一个小项目？? 是否定期对项目计划实施重新估算并根据实际情况加以调整？? 是否对作业文档等成果物的“量”进行了估计？? 是否以适当的单位进行了作业量的估计？? 项目作业是否具有详细的日程表？? 日程表确定之后，如果和实际情况出入较大，是否进行了调整？? 是否接受了不切实际的开发日程，而其结果是，日程表仅仅成为一种形式？? “工作量”和“难易度”是否会因为担当者的不同而出现巨大变动？? 是否因为实际进展超前于计划而没有思考项目计划本身存在的精度问题？团队管理晴雨表? 是否存在明确的软件开发行动单位：团队？? 是否虽然叫作团队，但是并没有认识到协作而是专注于工作任务的分担？? 管理者是否仍然承担以前作为技术者所承担的具体开发作业任务？? 项目管理者是否仅仅根据自己的经验而将需求式样直接分派给“个人”？? 项目管理者是否总是认为项目没有什么值得注意的问题？? 团队成员是否知道项目作业内容的相互关系及其优先级？? 是否在项目启动之后仍然还有项目组成员感到无所事事？? 是否经常有特定的项目组成员总是加班到深夜？? 团队成员是否知道并遵守统一的作业规范？? 是否从作业流程上、从团队协作上追究过程序缺陷的真正原因？? 团队成员是否在相互察看成果物后产生提高自己的作业水平的意识？? 当问题难点解决之后，是否向项目组成员介绍解决该问题的思维和方法？? 项目组成员的出勤时间是否经常相差很大而不寻找原因？? 项目组成员在遇到技术难题时是否与项目组其他成员沟通并寻求支援？? 项目组成员在讨论问题时是否出现无条理的、非建设性的讨论？作业流程晴雨表? 是否存在专注于组织整体的开发作业和项目流程的人或者小组？? 是否存在项目开发作业的标准作业流程？? 是否存在记述顾客需求式样的文档标准？? 是否存在设计书的文档标准？? 是否不经过设计阶段而直接进入编码阶段？? 设计阶段是否实施了以设计为对象的审查？? 编码阶段是否实施了以代码为对象的审查？? 中途式样变更后，是否未经其影响范围的分析就直接分配给担当者？? 是否未经单体测试就直接开始综合测试？? 是否时至最后才发现此前隐藏的诸多问题？? 是否无视已经发现的问题而继续推进作业？? 是否多次重复出现以前相同的错误而没有吸取教训？? 是否没有专门的测试人员而在交付之前还是由开发者自己实施测试？? 对式样需求是否确立了适当的测试项目？? 测试是否几乎没有自动化手段？? 过程改善方面是否存在可以商量和咨询的人员？? 是否鼓励各开发小组写作事后分析报告，至少能就项目进程开会讨论？? 是否组织正式的活动，就软件开发与质量控制流程的相关问题相互切磋？项目配置晴雨表? 是否在发现潜在的缺陷时难以确定其对现有模型的影响范围？? 是否只有担当者知道而没有向所有成员公布缺陷的修正范围和修正方法？? 是否因为修改一个程序缺陷而引发多个新的缺陷？? 担当者是否能在任何时间对源程序做自由的变更？? 开发期间是否定期对制作过程中的文件和程序进行备份？? 是否确立了资源备份在非常时期的因应方式？? 需求式样书和设计书等正式文件是否存在“确认”手续？? 项目文档是否一直保持最初的状态，即使在式样变更后仍然没有变化？? 是否在项目后期难以想起中途式样变更的“理由”？? 对于程序缺陷和式样变更，是否能追踪其修改点？? 对于开发环境目录中的旧代码是否难以判断其能否删除？? 开发文档是否会出现链接到旧版本的情况？教育培训晴雨表? 是否描绘出现在的开发组织多年后的“风姿”？? 在组织上，是否对现在的人员实施技术性教育和培训？? 是否确立了员工教育培训的计划和目标？? 是否将技术学习视为个人任务而没有组织上的“方向”？? 项目开发人员所持有的软件开发文献的平均数量是否在1册以下？? 项目作业休息时间是否毫不涉及崭新技术方面的话题？? 项目组成员是否不知道软件工程的意思？? 是否不了解“凝聚度”、“结合度”等词汇的意思？? 是否难以说出5个以上的软件质量特性及其副特性？项目审查晴雨表? 参与者是否了解审查的整体流程？? 是否带着目的而非盲目地实施审查作业？? 是否仅仅局限于代码审查而不顾及其他？? 审查者是否只关注形式而非实质？? 是否明确审查对象物，针对“物”而非“人”？? 是否记录审查结果并追踪缺陷修正结果？? 是否将审查的反馈结果导入下一项目中？? 审查会议是否演化成为问题解决会议？其他? 是否采取了数据备份以及病毒防范等措施？? 对电子邮件的应对是否总是滞后？? 是否感到电子邮件的应对很繁琐？。
Checklist的几大要素
Checklist的几个重要要素是：项目/任务、步骤、条件和标记（或勾选）方式。
1. 项目/任务：Checklist的首要要素是明确列出需要完成的项目或任务。
这些项目可以是工作任务、检查清单的事项、待办事项或需要遵循的步骤。
2. 步骤：每个项目或任务通常包含一系列需要执行的步骤。
步骤是指完成项目所需的行动或操作。
逐步明确列出这些步骤，可以确保在执行任务时不会遗漏关键细节。
3. 条件：Checklist的有效性还需考虑任务执行的条件。
条件是指完成项目或任务所需满足的先决条件、环境要求或其他相关情况。
在Checklist中包含适当的条件，有助于确保在适当的环境下执行任务。
4. 标记/勾选方式：Checklist的目的是跟踪任务完成情况。
为了实现这一目标，需要一种标记方式来记录已完成的步骤或任务。
常见的标记方式包括打勾、打对号、使用符号或颜色等方法。
这些要素的组合构成了一个完整的Checklist。
通过明确描述项目、步骤和条件，并使用适当的标记方式，Checklist 可以提供一个简单而有效的工具，帮助人们管理任务、确保重要步骤不被忽略，并提供一种可视化的方式来追踪任务的
进展。
QC七大手法检查表(Data collection form)分层法(Stratification)散布图(Scatter)排列图(Pareto)直方图(Histogram)因果图(Cause-Effect diagram)控制图(Control Chart)1. 查检表（Check List）以简单的数据或容易了解的方式，作成图形或表格，只要记上检查记号，并加以统计整理，作为进一步分析或核对检查用，其目的在於『现状调查』。
2. 柏拉图（Pareto Diagram）根据所搜集之数据，以不良原因、不良状况、不良发生或客户抱怨的种类、安全事故等，项目别加以分类，找出比率最大的项目或原因并按照大小顺序排列，再加上累积值的图形。
用以判断问题症结之所。
3. 特性要因图（Characteristic Diagram）一个问题的特性（结果）受一些要因（原因）的影响时，将这些要因加以整理，而成为有相互关系而且有条且有系统的图形。
其主要目的在阐明因果关系，亦称『因果图』，因其形状与鱼骨图相似故又常被称作『鱼骨图』。
4. 散布图（Scatter Diagram）把互相有关连的对应数据，在方格上以纵轴表示结果，以横轴表示原因，然后用点表示分布形态，根据分析的形态未研判对应数据之间的相互关系。
5. 管制图（Control Chart）一种用於调查制造程序是否在稳定状态下，或者维持制造程序在稳定状态下所用的图。
管制纵轴表产品品质特性，以制程变化数据为分度；横轴代表产品的群体号码、制造曰期，依照时间顺序将点画在图上，再与管制界限比较，以判别产品品质是否安定的一种图形。
6. 直方图（Histogram）将搜集的数据特性值或结果值，在一定的范围横轴上加以区分成几个相等区间，将各区间内的测定值所出现的次数累积起来的面积用柱形画出的图形。
因此也叫柱形图。
7. 层别法（Stractification）针对部门别、人别、工作方法别、设备、地点等所搜集的数据，按照它们共同特徵加以分类、统计的一种分析方法.二： 8D 8D 的原名叫做 8 Disciplines，意思是8 个人人皆知解决问题的固定步骤。
