项目管理-精益六西格玛黄带工具方法

标签：六西格玛 CTQ 项目 黄带 VOC 项目管理 精益 阶段 WBS

基于模拟项目，对项目管理知识进行学习，通过理论和实践相结合，掌握项目管理常用工具的使用方法，提高项目管理能力。加入了作为软件开发者个人角度的一些思考。

1 项目管理的5个阶段

项目管理通常包括五个主要阶段，分别是启动阶段、规划阶段、执行阶段、监控阶段和收尾阶段。具体来说：

1. 启动阶段：这是项目的起始阶段，关键在于确定项目的价值及可行性。在这个阶段，需要提供商业案例证明项目的必要性，并进行可行性研究来概述项目的目标、资源需求、成本以及财务和商业意义。
2. 规划阶段：一旦项目获批，就进入规划阶段。这一阶段要制定全面的项目计划，包括任务分解、资源分配、时间安排等，确保项目能在规定的时间和有限的预算内达到预期目标。
3. 执行阶段：在执行阶段，项目团队开始实际的工作以实现项目目标。这包括完成项目管理计划中确定的各项任务和活动。
4. 监控阶段：监控阶段是跟踪、审查和调整项目进展与绩效的过程。它涉及到识别必要的计划变更，并启动相应的变更请求。这一阶段贯穿整个项目管理过程，以确保项目按计划进行。
5. 收尾阶段：最后一个阶段是收尾阶段，主要是为了正式结束项目或项目阶段。在这个阶段，需要完成所有剩余的工作，确认项目成果，并正式关闭项目。

综上所述，这些阶段共同构成了项目管理的生命周期，每个阶段都有其特定的任务和目标。学习项目管理需要对每个阶段都有清晰的理解，以便更好地处理每个阶段，并确保项目能够按时、按质、按预算完成。使用合适的工具和方法可以在项目的整个生命周期中有效地管理团队和工作流程。

下面以实例介绍一些精益六西格玛黄带涉及到的工具和方法。

2 PDCA循环

PDCA是英语单词Plan(计划)、Do(执行)、Check(检查)和Act(修正)的第一个字母，是美国质量管理专家沃特·阿曼德·休哈特（Walter A. Shewhart）首先提出的，由戴明采纳、宣传，获得普及，所以又称戴明环。

PDCA是一个持续改善的工具。

这一模型的核心在于通过四个阶段来改进和优化过程，具体包括：

1. 计划（Plan）：确定目标和过程，规划如何实现这些目标。在这个阶段，需要识别机会、问题以及潜在的解决方案，并制定相应的计划。
2. 执行（Do）：实施计划，执行标准化的过程，以实现预定的目标。
3. 检查（Check）：对已执行的过程和结果进行检查，比较实际成果与预期目标之间的差异，收集数据，以供分析和评估。
4. 行动（Act）：根据检查的结果采取行动。如果结果满意，那么将过程标准化；如果不满意，则识别问题的原因，并采取措施进行改进。

综上所述，PDCA循环的每个阶段都包含了一系列具体的步骤，这个循环可以不断重复，以持续改进和解决问题。

最初PDCA的提出用于质量管理方面，我理解它更多的是一种指导思想，一种持续改善的思想，一种精益的思想，通过反复的迭代，不断提高项目的质量，最终达到既定目标。

这种思想在敏捷开发中亦有体现，敏捷开发将传统的瀑布模型转变成为一个个小的迭代，并在每个迭代中实现阶段目标，并不断优化，提高交付产品的质量。

所以，其实在我看来，无论是具体到PDCA、敏捷开发模型，还是抽象出来做管理。想要提高项目质量，最重要的是提高思想层面上的认知，在个人层面就要有精益、持续改善的思想。

我想造一个轮子，那就先产生一个圆形胶圈，它能跑了，但它能交付么？

当然不能，在雪地上它就要打滑。那我就在上面刻上花纹增加摩擦力。它现在能交付了么？

还不能，用久了它就变形了，那我就在上面......

一定要把这种持续改善的思想带入日常的开发、管理中。

针对软件开发者，一定要经常的问自己，这个功能目前的状态你认可么？你能接受么？如果不能，请自己先进入下一个PDCA循环，不要把问题留给测试与客户。

3 SIPOC(高阶流程图)

  3.1 SIPOC的组成

• 供应商：为流程提供输入的组织或个人
• 输入：流程需要的资源
• 流程：将输入转换成输出的一系列活动
• 输出：交付的产品或服务或产生的结果
• 客户：向核心流程提供关键信息、材料，或其他资源的组织，一般为流程的接收者或受益人

  3.2 VOC：客户声音

VOC 是“客户之声”的缩写，它指的是客户对产品、服务或流程的期望、需求和偏好。VOC 是一个重要的概念，因为它可以帮助组织了解客户的需求并提供满足这些需求的产品和服务。

收集 VOC 的方法：

• 客户调查
• 焦点小组
• 访谈
• 社交媒体监测
• 客户反馈分析

有两种主要的 VOC 类型：

• 明确的 VOC：客户明确表达的需求和期望。
• 隐含的 VOC：客户未明确表达但可以通过观察或研究推断出来的需求和期望。

  3.3 CTQ：关键质量特性

CTQ，即关键质量特性（Critical To Quality），是六西格玛管理中的一个重要概念。

CTQ代表了客户最在意的产品或者服务特性。在六西格玛管理中，通常用Y来表示CTQ。它将客户需求（VOC）转化为具体可衡量的要求，可以帮助提高项目或产品的质量和客户满意度。

CTQ需要具备的特征：SMART原则：

• S = Specific          具体的
  目标需要明确具体，而不是含糊不清。它应该回答需要达成什么，以及希望实现的具体结果是什么。例如，不是说“我要提高销售额”，而应该说“我要在接下来的季度内将销售额提高20%”。
• M = Measurable   可测量的、能够量化的
  目标应该有明确的衡量标准，以便可以跟踪进度和最终是否实现了目标。继续上面的例子，“将销售额提高20%”可以通过销售数据来衡量。
• A = Achievable     可达到的
  目标应该是实际可以达成的。这意味着在设定目标时需要考虑资源、时间和个人能力等因素。目标应该是挑战性的，但同时也要确保是可以实现的。
• R = Relevant        相关性
  目标需要与个人或组织的更广泛目标和愿景相符合。这样可以确保目标对于整体成功是有贡献的。
• T = Time-bound    具有明确时间节点的
  目标应该有明确的时间框架，说明何时开始以及何时完成。这有助于创建紧迫感，并防止目标被无限期地推迟。

  3.4 实例

在了解了上述概念之后，来看下SIPOC如何绘制。其中上面提到的VOC针对C（Customer）。CTQ是由VOC分析得来的，最终体现在O（Output）中。

假设我们要开发一个监控系统的软件部分。功能：远程音、视频监控，并且可以控制摄像头旋转角度。

注意这里针对软件开发，所以硬件的工作就作为了我们的供应商（S）。但对于整体项目而言，硬件工作将作为输入（Input）。

CTQ的定义：

1. CTQ测量：音视频无法播放/播放频繁卡顿、掉帧；无法通过app控制设备，视为异常。
2. 日常测量频率：开发过程中的每个新功能加入后
3. 项目的评价频率是多久一次：每周
4. 数据来源：测试人员实际使用情况

4 WBS分解

工作分解结构 (WBS) 是将项目或工作范围分解成更小、更易于管理的部分的过程。它是一种分层结构，其中项目或工作范围的最高级别位于顶部，而较低级别的部分位于其下方。

 WBS分解目的：

• 识别和定义项目或工作范围的组成部分。
• 组织和结构化项目或工作范围，以便于管理和控制。
• 确定项目或工作范围的范围和边界。
• 为项目或工作范围的规划、执行和控制提供框架。

WBS分解步骤：

1. 定义项目或工作范围：明确项目或工作范围的总体目标和成果。
2. 识别主要可交付成果：确定项目或工作范围的主要成果，这些成果对于实现总体目标至关重要。
3. 分解可交付成果：将主要可交付成果分解成较小的、更易于管理的部分。
4. 创建 WBS 层次结构：将分解的可交付成果组织成一个分层结构，其中最高级别是项目或工作范围，较低级别是可交付成果和任务。
5. 分配责任：为 WBS 中的每个部分分配责任，以确保所有工作都有明确的所有者。
6. 审查和完善：定期审查和完善 WBS，以确保其准确反映项目或工作范围，并根据需要进行调整。

  4.1 实例-树分解框架

将上例项目使用WBS分解如下：

  4.2 WBS分解-目录式WBS

目录式WBS更具体，每条任务都应该包含：编号、任务名称、周期、开始和结束时间、责任人。

5 识别关键X

识别关键 X 是确定影响关键质量特征 (CTQ) 的关键输入变量的过程。

关键 X 是影响 CTQ 的少数关键因素。

有几种方法可以识别关键 X，包括：

• 鱼骨图
• 流程图
• 5Why
• 回归分析
• 实验设计
• ......

识别关键 X 对于组织至关重要，原因如下：

• 帮助组织专注于影响 CTQ 的最重要因素
• 提高产品和服务质量
• 减少缺陷和返工
• 提高客户满意度和忠诚度
• 推动创新和增长

通过识别关键X，针对关键X进行改善，可以提高项目质量。

  5.1 实例-改善前流程图

改善前可以识别到如下一些可能影响交付质量的风险点：

  5.2 实例-流程图 挖掘关键X

针对问题1：需求理解偏差，分析如下：

这里可以看到有多种原因，能选取作为关键X的，一定是可控的X，并且对输出有改善的X。

比如上面提到的表达水平（对方）其实就是一种不可控的X。而在多个X中，我们要选出相比之下对改善更有利的X，例子中选择沟通频次作为关键X。

改善方案：

问题	解决方案	预期目标/效果	时间/投入/收益	对其他业务环节影响	评审意见
X1沟通频次	1.每周期开展项目例会，与客户确认目前研发进展及软件状态，交付阶段成果 2.提高会议以外的沟通效率，如邮件、微信等信息及时回复，问题及时提出	消除需求理解偏差引起的无效开发。及时纠错，回归正轨。	研发每周期投入10min-30min开展研讨会确认项目进度及方向。	无	通过

可以看到这里已经有一些敏捷开发的影子。如果这个开发由你一人完成，那么你自己就是一个敏捷团队。

  5.3 实例-鱼骨图 挖掘关键X

针对问题2：实现存在技术难点，分析如下：

在挖掘关键X的过程中一定要避免陷入到逃避的思想中。

比如说这里提出的技术能力不足。就大多数人日常开发的工作而言，根本不存在技术能力不足的情况。各种开源平台，技术网站资料，再加上AI的崛起，遇到棘手的问题基本都可以解决。

如果真的出现编码进行不下去了，那么首先要回过头考虑，是不是设计上就存在问题，而不是认为问题无法解决。如这里的X2、X3。

6 改善

对例子中识别出的关键X逐一分析修改，可以得到改善后的流程图：

可以看到里面还应用了敏捷开发的思想，例子中是针对整体产品，但作为个体程序员，每个开发的功能都能作为这一套项目管理的输入，自己走到这一套开发流程之中。这也就是前文提到的，开发者个人要具有敏捷的思想，在日常开发中，自己就进入到PDCA持续改善、敏捷开发精益的过程中，那么项目的质量自然而然就会提高。

7 收尾工作

  7.1 改善措施标准化

在项目实施结束后，要对好的部分进行标准化，形成文档，为后续项目的开展提供帮助。

NO	过程	问题点	措施	实施人	实施日期	标准化文件	负责人	更新日期
1	需求确认	沟通不及时	增加每周期验收 成果验证	xxx	xxxx	/	xxx	/
2	代码编写	技术难点	模块解耦 结构优化	xxx	xxxx	/	xxx	/
3	功能展示	软件实现最终才能看 到成品	缩短迭代周期，见到 最小可演示品	xxx	xxxx	/	xxx	/
4	测试验证	提交资料的周期过长	每功能实现后针对性 测试	xxx	xxxx	/	xxx	/

  7.2 KISS模型

KISS模型用于经验总结，指的是Keep，Improve、Start、Stop，保持好的，改进差的，开始正确的行动，取消错误的行动。例：

Keep	Improve
将整个项目按周期拆分，每个周期的功能模块在流程上都相当于之前的一个项目，这样每个功能更健壮，同时能看到阶段性成果，并且能及时响应客户需求。	代码逻辑优化。
Start	Stop
进一步对冗余代码删除，提高程序运行效率； 新版子功能验证。	没有在初期留出对接接口，增加了后续增添的成本。

以上就是项目管理的一些知识，想要提高我们的项目管理能力，一定要在日常开发中就带着持续改善的思想去开发每个功能，精益求精。

标签：六西格玛,CTQ,项目,黄带,VOC,项目管理,精益,阶段,WBS
From： https://blog.csdn.net/hkj887tg/article/details/137264598