您使用哪些测量方法来改进您的流程？ [关闭]

Question

这个问题最初是问“您在软件开发组织中使用什么 KPI”。不幸的是，KPI 似乎是一个四个字母的词，直接的假设是 KPI 总是被误用（也许是？）。

因此，我希望改进这个问题，以达到我最初认为 KPI 有用的基本目标。假设您有一些关于您（或您的组织）如何开发软件的流程。其次，假设您（或您的团队）希望在开发和交付软件方面做得更好。最后，假设改进的方法之一是改进您的流程。

鉴于所有这些，您如何知道您的流程改进是否产生了积极影响？如果这些是KPI，或 [SMART 目标](http://en.wikipedia.org/wiki/SMART_(project_management) 请提供您认为有效的个人或团体 KPI/SMART 目标。如果是其他机制，请说明什么是的。最后，我想，如果你认为改进流程不是一件有用的事情，我想你也可以解释一下。

我认为有用的改进领域是：质量、发布的及时性、生产力、灵活性。如果个人或开发人员团队还有其他方面的信息，那将会很有趣。

澄清说明：

问题不在于如何最好地适应或改变流程，或者什么是好的流程改进流程（无论是改善、回顾等）。也不是关于根本原因分析或用于确定流程的哪些特定方面应该改进的其他方法。

使用措施来确定是否已实现流程改进，不应与正在进行的流程改进相混淆。 （这是一件好事，但这不是问题所在！）

进程可以是任何东西； scrum，敏捷，极端，瀑布，临时。这个问题不在于哪种流程最适合某些类型的软件开发，而是如何随着时间的推移改进该流程。

显然，具体的指标将取决于所涉及的过程，以及试图改进的感知问题。这个问题只是为了获取所用指标的示例，这些指标显然会跨越许多不同的流程和改进领域。

指标不必是一直使用的东西，例如，它可以只在测试流程更改是否有效时使用。 （例如，在时间或金钱方面，始终测量和跟踪可能太昂贵了，因此您只需跟踪它就会调整流程）。

如果实施不当，指标的使用可能会在开发人员游戏系统或其他方面产生不利影响，这是理所当然的。假设实施流程变更的人意识到了这个问题并采取了有效的措施来缓解它。

所有软件组织都不同，它们与公司的适应方式不同，因此公司内部对他们的具体期望也不同，但我认为产品质量、生产力、灵活性和发布及时性适用于大多数人，如果不是的话所有组织。 （根据具体组织的不同，重点明显不同。）

这个问题与源代码行无关！特别是，我对衡量程序员的生产力不感兴趣，尤其是在 SLOC 或修复的错误数量方面，或任何其他幼稚的衡量标准方面。我对团队或个人衡量他们改进的更高层次的方式感兴趣。我对使用单个 KPI 来衡量任何人的绩效不感兴趣。我我有兴趣使用一系列 KPI 来衡量和改进我团队的软件开发流程。

我知道关于 KPI 被滥用和无效的恐怖故事（您无需费力搜索即可找到它们），但我无法相信没有人试图不断改进他们的流程，所以肯定有一些 KPI 的好例子。

我完全了解适用于单个软件程序员的简单指标的缺点。我真的希望获得人们认为有用的 KPI 或替代策略的示例，而不是我不应该使用 KPI 的所有原因。

我最感兴趣的是与大型公司内的开发组织相关的流程和绩效，而不是整个软件开发公司。例如，软件公司应该确保产品具有适合市场的功能，但通常这是产品管理的角色，而不是工程。是的，关于工程师应该参与产品管理的原因和程度，还有一个完整的其他讨论，但这是一个单独的讨论。

Answer 1

当我听到关键绩效指标时，我有点担心，因为通常接下来要做的就是将绩效与奖励联系起来，然后你很快就会摆脱困境。我总是想起那个决定围绕错误修复制定奖励系统的软件公司——测试人员会因发现错误而获得奖励，而开发人员会因修复错误而获得奖励。随着围绕错误插入、检测和纠正的即时黑市形成，开发陷入停顿。

您的组织 KPI 应该以客户为中心。根据您制作的软件产品的类型，您可以通过以下方式对其进行衡量：

• 销售 - 您的产品是否满足客户要求？您可以根据软件演示与销售或访问您网站的购买页面与实际购买的比率来衡量这一点
• 质量 - 您的软件是否易于理解且可靠？您每天会接到每位客户多少次支持电话？是关于如何做某事的问题还是错误？
• 客户满意度 - 您的客户对您的产品的满意度如何？调查您的客户并找出您可以做些什么来提高他们的满意度，然后稍后再次调查他们以了解您是否有所改进。 （不要因为问太多问题或太频繁地问问题而惹恼您的客户）

是的，这些指标似乎与发现的错误和生成的代码行等基本软件指标无关。但是，发现错误的问题是您必须对错误的严重程度进行分级，而重构通常会减少您的代码行数。仅当您满足客户对及时交付的期望时，及时性才重要。

专注于业务目标。如果您有客户购买您的软件，他们不需要很多支持来使用它并且他们很高兴，那么您的软件组织就是成功的。如果您没有这三件事，那么检测到的错误、进度表或其他任何事情都不会重要。

如果您的软件项目与大多数软件项目一样，那么它会迟到、超出预算、交付的功能少于预期并且存在错误。不要因为这些事情而自责，处理它们并继续前进。是的，您需要错误数据库、源代码控制、测试和衡量项目速度的方法，但最终，如果您不满足业务成果，那么您就无法成功，无论您的代码多么优美和闪亮，以及如何它有一些错误。

更新以尝试解决修改后的问题

在交付通常也是移动目标的无形产品时，很难使用您希望使用的 KPI。当您实施文档管理系统时，您今年在会计系统上使用的 KPI 是否具有相同的含义？

让我们以广泛使用 KPI 的职业为例 - 律师。衡量律师使用关键绩效指标，例如： 平均每天工作小时数；每月计费的小时数；债务人分类账的年龄；无账单工作的平均年龄；已注销的账单费用百分比；等等。您应该注意到这里的一个趋势——所有这些 KPI 都与客户是否愿意（或不愿意）为所提供的服务付费。这是成功的最终仲裁者，这就是为什么我建议（上面）一些方法，你可以使用这种类型的测量作为你的软件业务的 KPI。

当您尝试着手制定与客户为您提供的价值付费的意愿无关的 KPI 时，我们就会着手解决我们所衡量的内容、衡量方式以及差异的问题与去年相比，今年有测量或正在测量的内容。

“客户支付的美元”每年都有一个固定值 - “软件中的错误”、“发布的及时性”和“灵活性”等任意指标没有固定值，KPI 的增加可能不会与要由 KPI 衡量的基础值有直接关系，例如“更多错误意味着更低质量”。

例如，在Columbia disaster之后，我记得调查组提出了数百个建议和要调查的项目。这些新发现的“漏洞”是否意味着航天飞机的质量突然下降了很多？实际上，经过调查，航天飞机的质量更高。因此，围绕错误的 KPI 很容易被广泛的 QA 会议扭曲，报告的错误越多实际上可能意味着您的软件质量更高。

在发布及时性方面的生产力很容易受到商业因素的影响，例如客户向您投钱为他们进行一些定制开发。您的发布计划会推迟，但您的业务会有所改善。

至于灵活性，我什至无法猜测您将如何衡量如此无形的事物。

关于我能想到的对客户钱包这一方有价值的唯一衡量标准是project velocity - 我们估计上一次迭代/周期/发布会做多少，我们实际完成了多少？然后将此数字插入下一次迭代/周期/发布的可用时间，以估计这次您可能能够完成多少工作。您可以在迭代期间以burn down chart 或类似名称显示剩余时间。

其余的归结为流程，我认为您无法将其归结为 KPI。您所能做的就是确保您的开发人员知道每个人都在做什么（每日开发人员会议），您的扩展团队获得意见（每周或每两周一次的团队会议），您了解上次哪些工作有效，哪些没有（回顾），最重要的是你有透明有效的沟通。

不幸的是，我不认为有任何像您所追求的神奇 KPI（但不要忽视从客户那里获得资金作为 KPI 的相关性）。

Answer 2

到目前为止，最好的单一指标是“交付和接受的测试功能”。在敏捷世界中，我们通常根据“用户故事”来衡量“功能”，但它可以采用任何方便的形式，只要它衡量的是交付和测试的、客户可接受的实际功能。

由于查理的第一管理定律，通常的其他度量，如 SLOC、SLOC/员工小时等，都失败了，即：

人们会提供他们所提供的任何东西 交付奖励。

将度量设置为 SLOC，您将获得大量 SLOC。使用 SLOC/hr，你会得到很多 SLOC/ht。给他们加班奖金，你会得到很多加班费。

哦，还要记住相关性：

人们交付的是什么 他们认为这将是有益的 交付。

如果你没有得到你想要的，问问为什么做已经完成的事情会有回报。

Answer 3

Benno，我正在回复你的评论，但那里没有足够的字符来回答。

这取决于您要解决的问题。例如，假设问题是从开发人员签入代码到实际投入生产的时间似乎太长了。然后你会得到一个基线测量它需要多长时间。然后你会投入你的改变，然后测量一段时间，看看现在是否需要更少的时间。您还可以检查解决方案被确定为不起作用并在前后送回返工的次数，以确保解决方案不是更快，而是质量更低。

现在，IT 中使用这些测量的问题是，可能需要相当长的时间来积累足够的数据，因为有些问题不会经常再次发生。在这种情况下，您可能必须从依赖主观数据开始，直到您可以积累足够的数据来了解更改是否良好。但是在用户习惯之前不要问是否有改进。新流程的头一两周，你会遇到改变的阻力，如果你问得太早，就会得到不好的主观结果。

另一件需要注意的事情是，如果人们知道你在衡量某件事，他们会害怕他们的个人表现被衡量，因此会与系统博弈以获得良好的结果。如果您可以基于一些已经存在的系统进行测量，通常是最好的（我们有一个管理软件更改请求的系统，我们可以查询数据库以了解历史上有多少请求错过了截止日期，有多少我们在被重新打开后重新打开关闭或与过去的请求等有关，开发人员完成和将代码移至生产等之间的时间差是多少）。您可能还必须考虑消除严重的异常值，尤其是当时间跨越旧系统和新系统的时间段时。例如，我们有一个请求已经在 QA 中超过 100 天，不是因为它很糟糕，而是因为 QA 存在可用性问题，而这个请求是最低优先级的，所以它不断受到更高优先级的工作的影响。这个时间对于衡量时间的改进没有价值，因为使时间如此长的因素不是您要修复的过程。如果您将数据绘制成图表，您将很容易看到可能需要排除的异常值。

Answer 4

基于成本、质量和进度的 KPI 将是一个良好的开端。考虑一下您要衡量的每个人的属性是什么。

能够将这些指标中的每一个分开来显示错误的成本会很有用 - 项目后期的大量错误修复工作意味着成本/进度井喷。能够分析代码库的哪些部分存在错误有助于定位额外的测试和可能的代码重写——通常 80% 的错误将来自 20% 的代码。知道它在哪里可以让您的团队更好地集中注意力。

编辑：查看质量成本 (CoQ) 和劣质成本 (CoPQ) 等指标。

生产力之类的衡量标准总是难以量化 - 例如，使用 LOC/day 会引发关于代码行到底是什么的争论？如果开发人员不理解为什么要跟踪这些东西或将它们视为个人度量，它还可能导致愚蠢的代码格式化以“提高”生产力。即使 LOC/day 不是在开发人员级别衡量的，您仍然可以让团队竞争导致相同的结果。

编辑：Steve McConnell 的Construx 网站上有一些很好的讨论。 [是的，这就是 Code Complete 的 Steve McConnell 成名]

Answer 5

除了让每个人真正团结起来并弄清楚什么是有效的，什么是无效的之外，没有任何流程可以帮助您改进您的工作。对于我目前领导的团队，我们通过一系列回顾来做到这一点（我强烈推荐this book）。团队通常知道他们想要改进哪些部分 - 诀窍是赋予他们实际衡量和改进这些内容的权力。

是的，您当然仍然需要有人关注宏观层面。如果你看看像丰田这样的组织，他们有一位横跨业务和生产之间的总工程师（关于一个很好的解释，请参阅 Scott Bellware 的blog post）。在我们的组织中，我们也有类似的人——我的老板是近 20 年前我们产品的最初开发者之一，并且在技术方面保持高度活跃，但在客户方面也进行了大量投资。我的工作也是从整体上审视团队以提出改进建议。

为了衡量，我们首先确保我们努力实现的任何改进都是我们的团队可以实际改变的，然后使用类似于 SMART goals 的东西，以便任何改进都是可衡量的。我们有一个Big, Visible Wall，我们会在上面发布回顾展的笔记。这恰好也是我们举行日常站立会议的地方，因此我们可以专注于正在发生的事情。

为了将统计数据汇总到我们的行政会议，我们专注于代码交付，而不是交付的代码行。我故意让团队在nebulous units 中进行测量，这意味着我们不会报告我们工作了 x 小时数、天数或其他什么。他们所看到的是一张趋势图，显示了我们提供功能的情况以及我们如何改进。当团队认为他们想要分享时，我们还会包含有趣的花絮。

关于这一切的最好的部分是我们可以尝试一个月，然后在 4 周后重新评估它。这为尝试新事物创造了更低的进入门槛，因为团队知道如果它对他们产生影响，我们要么立即取消它，要么我们将在下一次回顾会议上重新评估并找到更好的方法。

不好的部分是它不是你要找的。我们没有持续遵循一个或一组指标。我们随时观察趋势，并衡量我们认为有趣的趋势——但只是一小部分，而且只有当团队开始着手实现特定目标时。但总的来说，我对它的工作方式非常满意，并且我看到团队参与改进流程的情况有了显着改善。我们不完全是Kaizen，但我们每天都在变得更好。

Answer 6

我从事专业的流程改进工作 14 年。这是我的建议，停止尝试量化并开始与人交谈。测量适用于特定问题（一旦您知道问题，您就会更好地了解要测量的内容）以及制造等可重复过程。您的员工确切地知道问题区域在哪里，您的客户和用户也是如此（从非常不同的角度来看）。流程图（使用工业工程符号而不是计算机编程符号）列出存在问题的区域的实际过程（不是我们假装的过程，您需要观察并提出问题）。一旦你看到流程的整个流程，寻找延迟、工作重复的区域、有不必要流程的区域（通常是由于在流程中添加了更多步骤来解决人为错误，从而为人类创造了更多潜在区域错误）。质疑每一步的必要性以及是否有更好的方法来完成每一步。测试潜在的变化，看看它们是否真的是一种改进（太多次它们使情况变得更糟而不是更好）。在任何情况下都不要只在感觉到问题或绘制流程图时才与经理交谈。你不会得到真实的图片，因此会解决错误的问题。

Answer 7

了解浪费和价值流图将向您展示需要改进的地方，并且根据这些知识，您将了解需要衡量的内容。精益和看板的原则在这里适用。了解浪费及其对生产软件的影响将使您走上特定的改进之路，而这对于您的组织来说是不可避免的。你不能采取千篇一律的方法。阅读（或收听）“目标”和“精益思考”，了解更多关于问题所在以及如何解决问题的令人惊叹且令人大开眼界的观点。

Answer 8

关键绩效指标的最佳用途是驾驶（或转向，如果您愿意）。 实时课程修正。

（请参阅Dashboards are for Driving 了解有关此子主题的更多废话。警告：我是废话文章的作者。）

所以，回到您的问题是：您是否尝试评估性能事后，什么时候为时已晚，或者您是试图找到可以帮助您坚持到底的 KPI？

如果是前者，您的组织关心的任何指标（错误计数、发货日期延迟、带有 cmets 的代码行、客户退货百分比等）都可以。在运送产品和升级之间进行测量，祝你好运;-)

如果是后者，请选择velocity。当然，假设您使用的是测试驱动开发 (TDD)。

编辑：所以是前者。好吧，这就是你可能不走运的原因：

假设您决定通过衡量客户报告的错误数量作为您的后处理 KPI 来最好地量化“质量”。假设您正在使用 TDD，并假设您的团队在 6 个月内交付了产品 #1，并且在该领域工作了 6 个月后，您发现您有 10 个客户报告的错误。那么现在，您究竟要做什么来改进您的流程？测试更多？专门测试更多的东西，比如报告的错误的原因？在我看来，您已经在进行测试，并且当发现错误时（无论是否由客户），您都会为特定错误添加回归测试和额外的单元测试，以确保没有更多类似的错误。换句话说，您的流程后改进响应与您的流程中改进响应没有什么不同，因此此 KPI 对改进您的流程确实没有显着帮助。关键是，无论是在发布后 6 个月还是在编码后两天发现错误，您改进流程的方式都保持不变。因此，尽管这可能是挂在经理墙上或部门通讯上的闪亮 KPI，但它确实不会改变您的流程改进机制。 （请注意不要在此 KPI 中放太多库存，因为它可能会受到您无法控制的因素的极大影响！）。简而言之，知道错误的数量并不能帮助您改进。

（这里还有一个危险，不仅在商业中，而且在军队中也很常见，那就是认为事后分析揭示了有价值的信息的错觉，因此事后的经验教训被大力应用于下一个项目，这可能和上一个项目不一样。这被称为“打最后一战”。）

假设客户退货/退款的数量是您选择的“质量”KPI - 如果这个数字是 5，这说明了什么？客户要求退款的具体原因可能是一些质量问题的迹象（“太慢”、“无法与 XYZ 系统接口”等），但仅此类事件的数量就说明了你什么都没有。与预期回报百分比的差异可能会告诉您质量是否有所提高，但再次该数字并不能帮助您提高。您需要的信息比电话号码所能提供的更多。

那么对于“发布的及时性”，什么衡量标准是合适的？发货日期延误的天数？基于原始估计的超支百分比？ 没关系，因为再次这些数字并不能帮助你提高。

如果您可以在产品完成后测量“生产力”，那么您可能可以在产品开发过程中进行测量（例如速度），不同之处在于开发过程中低于预期的生产力可以立即提高，而整体开发完成后测量的生产力数字太粗略，太平均，没有任何用处。只能猜测为什么 6 个月后它低于预期......

我不知道如何衡量“灵活性”，这听起来像是营销术语 ;-)

我希望我没有把这颗钉子敲得太重或太远，但我不认为有任何有用可以在你无法衡量的事实后衡量 em>进行中。并且有很多事后的测量，在不知道原因的情况下是无用的。

Answer 9

您可以在http://www.dashboardzone.com 获得很多关于 KPI 和 Dashboards 示例的想法

按行业和功能领域划分的关键绩效指标。