ben*_*nno 9 process-management kpi
这个问题最初是在询问"你在软件开发组织中使用什么KPI".不幸的是,似乎KPI是一个四个字母的单词,并且直接的假设是KPI总是被误用(也许它们是？).
所以,我希望能够改进这个问题,以实现我最初认为KPI有用的基本目标.假设您有一些流程来说明您(或您的组织)如何开发软件.其次假设您(或您的团队)希望在开发和交付软件方面做得更好.最后,假设改进的方法之一是改进您的过程.
鉴于这一切,您如何知道您的流程改进是否产生了积极影响？如果这些是KPI或[SMART目标](http://en.wikipedia.org/wiki/SMART_ ( project_management),请提供您认为有效的KPI/SMART目标的个人或团体.如果是其他一些机制请解释它是什么.最后,我想,如果你不认为改进过程是有用的,我想你也可以解释一下.
我认为有用的改进领域是:质量,发布的及时性,生产力,灵活性.如果个人或开发团队的其他方面,那么知道这将是有趣的.
澄清笔记:
问题不在于如何最好地适应或改变一个过程,或者一个好的过程改进过程(无论是Kaizen,回顾等).它也不是关于根本原因分析或用于确定应该改进过程的哪些具体方面的其他方法.
使用措施来确定是否已实现过程改进,不应与正在进行的过程改进相混淆.(这是一件好事,但这不是问题所在!)
这个过程可能是任何事情; scrum,敏捷,极端,瀑布,ad-hoc.这个问题不是关于哪种过程最适合某些类型的软件开发,而是关于如何随着时间推移改进该过程.
显然,具体指标将取决于所涉及的过程以及试图改进的感知问题.这个问题的目的只是为了获得所用指标的例子,这显然会跨越许多不同的流程和改进领域.
度量不需要的东西,用所有的时间,例如,可以只使用它,而如果测试过程改变的作品.(例如,在任何时候进行测量和跟踪都可能过于昂贵 - 时间或金钱明智 - 因此您只需跟踪它就会调整过程).
如果实施不当,使用度量可能会对开发人员游戏系统或其他方面产生不利影响.假设实施流程变更的人员已意识到此问题并已采取有效措施来缓解此问题.
所有软件组织都不同,它们如何适应公司,因此公司内部会有不同的特定事物,但我认为产品质量,生产力,灵活性和发布的及时性适用于大多数(如果不是所有)组织.(根据具体的组织,明显不同的重点.)
这个问题与源代码行无关!特别是,我对测量程序员的工作效率不感兴趣,特别是在SLOC或固定的错误数量或任何其他天真的测量方面.我对团队或个人衡量他们改进的更高层次方式感兴趣.我对使用单个KPI来衡量任何人的表现并不感兴趣.我有兴趣使用一系列KPI来衡量和改进我的团队的软件开发过程.
我知道关于KPI被滥用和无效的恐怖故事(你不需要非常努力地找到它们),但我无法相信没有人试图不断改进他们的流程,所以必须有一些关键绩效指标的好例子.
我知道应用于各个软件程序员的简单度量的缺点.我真的希望得到人们认为有用的KPI或替代策略的例子,而不是我不应该使用KPI的所有原因.
我最感兴趣的是与大型公司内的开发组织相关的流程和性能,而不是整个软件开发公司.例如,软件公司应该确保产品具有适合市场的功能,但通常是产品管理的角色,而不是工程.是的,关于工程师应该参与产品管理的原因和程度,还有一个完整的其他讨论,但这是一个单独的讨论.
当我听到关键绩效指标时,我会有点担心,因为通常接下来要做的就是将绩效与奖励挂钩,然后你就可以很快地解决问题.我总是想起软件公司决定围绕bug修复的奖励系统 - 测试人员会因发现bug而获得奖励,而开发人员因修复bug而获得奖励.由于在插入,检测和纠正错误周围形成了即时黑市,因此开发停滞不前.
您的组织KPI应该以客户为中心.根据您所使用的软件产品类型,您可以通过以下方式进行测量:
是的,这些指标似乎与基本级软件指标无关,如发现的错误和生成的代码行.但是,发现错误的问题是你必须对错误的严重程度进行评级,重构通常会减少你的代码行.只有满足客户对及时交货的期望,及时性才有意义.
专注于业务目标.如果您有客户购买您的软件,他们不需要很多支持来使用它,他们很高兴,那么您的软件组织就会成功.如果您没有这三件事,那么无法检测出错误,计划单或任何其他内容.
如果您的软件项目与大多数软件项目一样,那么它将会延迟,超出预算,运行的功能少于预期,并且存在漏洞.不要在这些事情上打败自己,处理它们并继续前进.是的,您需要错误数据库,源代码控制,测试和测量项目速度的方法,但最终如果您不能满足业务成果,那么无论您的代码是多么精致和闪亮以及如何成功,您都无法成功它有一些错误.
更新以尝试解决修订后的问题
当您提供通常也是移动目标的无形产品时,您希望使用它们的关键绩效指标很难实现.今年在实施文件管理系统时,您今年在会计系统上使用的KPI是否具有相同的含义？
让我们以一个广泛使用KPI的专业为例 - 律师.衡量律师使用KPI,例如:每天平均工作时数; 每个小时收费; 债务人分类账的年龄; 未开单工作的平均年龄; 注销费用的百分比; 等等.您应该注意到这里的趋势 - 所有这些KPI都与客户愿意(或不愿意)支付所提供的服务有关.这是成功的最终仲裁者,这就是为什么我建议(上文)某些方法可以将此类测量用作软件业务的KPI.
当您尝试使用与您的客户愿意支付的价值无关的KPI时,我们会发现我们正在测量的内容,您如何衡量它以及它们之间存在哪些差异的问题测量或今年的测量与去年相比.
"客户支付的美元"每年都有固定价值 - 任意指标,如"软件中的错误","发布的及时性"和"灵活性"没有固定的价值,而且KPI的增加可能没有直接的与KPI要衡量的基础价值的关系,例如"更多的错误意味着更低的质量".
例如,在哥伦比亚大灾难之后,我记得调查小组提出了数百项建议和要调查的项目.这些新发现的"虫子"是否意味着航天飞机的质量突然降低了很多？实际上,经过调查,航天飞机的质量更高.因此,通过广泛的QA会话可以轻松扭曲有关错误的KPI,并且报告的更多错误实际上可能意味着您的软件具有更高的质量.
发布的及时性方面的生产力很容易被商业因素扭曲,例如客户向您投入资金为他们做一些定制开发.您的发布时间表将会下滑,但您的业务将会改善.
至于灵活性,我甚至无法猜测你将如何测量如此无形的东西.
关于我能想到的唯一一个衡量客户钱包这方面价值的衡量标准是项目速度 - 我们估计我们会做多少次上次迭代/周期/发布以及我们实际完成了多少工作？然后将此图插入下一次迭代/周期/发布的可用时间,以估计这次可能完成的工作量.您可以在迭代期间显示刻录图表中的剩余时间或类似时间.
其余的归结为我不认为你可以确定KPI的流程.你所能做的就是确保你的开发人员知道每个人都在做什么(每日开发人员会议),你的扩展团队得到输入(每周或两周一次的团队会议),你了解上次工作的内容和没有的内容(回顾)以及最重要的你有透明有效的沟通.
不幸的是,我认为没有像你这样的神奇KPI(但不要忽视从客户那里获取资金作为KPI的相关性).
到目前为止,最好的单一指标是"测试功能已交付和接受".在敏捷世界中,我们通常根据"用户故事"来衡量"功能",但它可以采用任何方便的形式,只要它能够测量交付和测试的实际功能,客户可以接受.
由于查理的第一管理法,通常的其他措施,如SLOC,SLOC /员工小时等,都失败了,这是:
人们将提供他们获得奖励的任何东西.
将您的度量设置为SLOC,您将获得大量SLOC.使用SLOC/hr,你会得到很多SLOC/ht.给他们加班的奖金,你会得到很多加班费.
哦,还要记住相关内容:
人们提供的是他们认为交付的回报.
如果你没有得到你想要的东西,那么问问为什么做完这些事情是有益的.
| 归档时间： |
|
| 查看次数： |
5235 次 |
| 最近记录： |