做电子商务系统网站,河南艾特软件 网站建设,如何推销企业建设网站,医疗网站建设意见欢迎来到通向卓越之路#xff01;我们或许都陷入了这样的困境#xff0c;我们努力成为卓越的企业#xff0c;我们进行绩效考量#xff0c;并在此过程中找到正确的OKR、KPI或ABC。但这可能是一件很困难的事情#xff0c;特别是当我们所在的组织非常复杂并从技术幽灵#x… 欢迎来到通向卓越之路我们或许都陷入了这样的困境我们努力成为卓越的企业我们进行绩效考量并在此过程中找到正确的OKR、KPI或ABC。但这可能是一件很困难的事情特别是当我们所在的组织非常复杂并从技术幽灵Ghosts of Technology Past和管理幽灵Ghosts of Management Past中继承了它们的衡量指标。虽然不存在一个万能的衡量指标但仍然有一些可遵循的指南以及一些可以避免的常见错误。我们在与Jez Humble和Gene Kim共同撰写的新书“Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”中概述了什么才是好的衡量指标。这两个规则非常简单可以帮助我们理解我们在进行绩效考量时所犯下的惊人错误。两个简单的衡量指南使用专注于结果而不是输出的衡量指标。使用针对全局或整个团队成果而不是局部或个人成果而进行优化的衡量指标。仅此而已。软件开发绩效考量中的很多问题通常是因为采用了不遵循上述两个准则的衡量指标。衡量指标形成了我们的激励机制继而影响我们的行所以我们需要使用正确的衡量指标。常见的不良衡量指标大多数软件绩效考量都把注意力放在了生产力上他们通常忽略上述的两个指导原则。或许我有一点幸灾乐祸的意思不过先让我们从“不应该做什么”开始讲代码行数。一直以来我们试图使用代码行数来衡量生产力。有些公司甚至要求开发人员记录每周承诺的代码行数Apple Lisa团队的管理层发现将代码行数作为衡量生产力的指标是毫无意义的这里是他们的故事。如果1000行代和10行代码都能解决同一个问题我当然喜欢后者。奖励开发人员编写额外的代码只会让软件变得更加臃肿这会带来更高的维护成本和变更成本。那么另一个极端呢最小化代码行数也不行。虽然有时候可以用一行代码来完成一个任务但这样的代码别人不好理解所以很难维护。理想情况下我们应该奖励开发人员用最少的代码来解决业务问题——如果我们可以在不编写代码或删除代码的情况下解决问题或许是通过修改业务流程那就更好了。将代码行数作为生产力衡量指标违反了我们的指导原则因为这样关注的是产出而非成果。它只衡量了人们做了什么代码行数——通常是因为这样做更容易——但通常忽略了真正的目标因为目标难以表达和衡量。但目标不是我们应该真正关心的吗速度。将速度作为衡量指标是源自敏捷运动——问题被分解为故事story点数然后开发人员为故事点数分配相应的工作量。在截止工作时完成的故事点数就是团队的速度。但是这只是团队的容量规划工具。使用速度作为生产力衡量指标有几个不足。首先速度是一种依赖于团队的度量具有相对性。团队通常具有不同的背景所以在团队间进行速度比较并不合适。其次当速度被用作生产力衡量标准时团队很可能会做出一些与事实不符的事情他们会夸大他们的估算并想尽可能多地完成故事点数疏于与其他团队合作这可能会降低他们自己的速度并加快其他团队的速度反而会让他们看起来很糟糕。这不仅会破坏速度原本的意义还会抑制团队之间的协作。将速度作为生产力衡量指标也违反了我们的指导原则因为它更关注局部指标而非全局指标。为了优化自己的速度团队通常不会与其他团队合作。这通常会导致组织采用次优的解决方案因为他们没有关注全局指标。利用率。很多组织将利用率作为生产力的衡量指标。不幸的是数学在这里不起作用。疲于处理待办事项列表的人都应该能够理解我将要描述的内容一旦利用率超过一定水平就没有多余的容量用于容纳计划外的工作、计划的变更或改进工作。这导致完成工作的时间变长。数学中的队列理论告诉我们当利用率接近100时交付周期就接近于无穷大——换句话说一旦达到非常高的利用水平团队就需要指数级的时间来完成任务。由于交付周期——衡量完成工作的速度——不会与其他指标一样存在某些弊端因此我们可以通过管理利用率以一种相对经济的方式做出平衡。将利用率作为生产力衡量指标违反了我们的指导原则因为它侧重于产出而非结果。它还侧重于个人而非局。这让我们看起好像在压榨员工实际上我们正把自己推向无法完成任何工作的境地。技术考量的正面例子事情还是有它好的一面。我们确实有一些很好的例子可以用来说明如何衡量技术的生产力我将在这里概述其中的一些。软件。”Accelerate“一书把我们在软件开发和交付方面使用的度量叫作软件交付绩效。它可以分为两个类别每个类别包含两项指标节奏:交付周期从提交代码到代码在生产环境中成功运行所需的时间。部署频率团队部署代码的频率。稳定性恢复服务的时间当服务发生服务事故例如计划外中断、服务损害时恢复服务通常需要多长时间。变更失败率他们对主要应用程序或服务做出的变更有多少百分比会导致服务降级或随后需要进行修复例如导致服务受损或中断需要修补程序、回滚或补丁。这些衡量指标遵循我们的指导原则因为它们既是面向结果的指标又是全局的指标——也就是说它们专注于让软件对组织和客户产生价值而不是把注意力放在无法给整体目标带来帮助的局部问题上。我们发现节奏和稳定性可以放在一起实现高绩效企业在两个方面都表现良好。我们的研究发现通过关注这些指标可以提升组织绩效高绩效企业可成倍实现盈利能力、生产力和市场份额以及效率和客户满意度。数据库。另一个很好的例子是数据库性能的考量。做到这一点其实不容易因为我们经常会陷入细节之中数据输入、数据输出、数据安全、我们的遥测是什么样的、我们选择什么样的聚合等等。所有这些都要求我们对数据和数据库有充分的了解。但是如果我们想要考量数据库性能我们应该退后一步看看全局的衡量标准和结果。这就是为什么我会喜欢Laine Campbell和Charity Majors在”Database Reliability Engineering“一书中提出的的指导原则。他们在关于操作可视性的章节中指出了两个关键问题你的服务是否在运行消费者是否感到痛苦他们非常巧妙地解释说“端到端检查是你工具库中最强大的工具因为它们最能反映你的客户体验”。我喜欢他们给出的明确的指导原则并专注于这些指标因为在这种情况下你可以通过将数据库和开发团队聚集在一起来产生价值并确保交付高质量的软件应用程序和数据库代码。顺便说一下专注于这些指标也有助于将数据库纳入到你的技术和产品的价值对话中。如果你的客户感到痛苦因为你的跨职能开发团队在开发应用程序时忽略了你的数据库团队他们只能手动部署数据库变更以便跟上应用程序的更新速度那么这就到了一起坐下来解决问题的时候了。质量。关注质量对于所有的组织来说都很重要但这也是最难的指标之一。为什么这是因为用软件质量专家Jerry Weinberg的话说“质量对某些人来说就是价值”【1】。众所周知不同的组织有不同的环境提供不同的职能和服务不同的人。但是“质量”——无论在什么样的背景下——通常都是一种良好的生产力衡量标准因为它侧重于全局指标和结果。我们通常会考虑我们的最终用户或客户或者我们产品的最终状态。在我们的研究中我们发现了一个质量指标也就是是返工或计划外工作所花时间的百分比包括中断或修复工作、紧急软件部署和补丁、响应紧急审计文档请求等等。我们发现在新工作、计划外工作或返工以及其他工作上花费的时间在高绩效者和低绩效者之间存在显著差异。换句话说高绩效者要提升质量因此必须花更少的时间来修复错误。看看下图。通过专注于这两件事——全局指标和结果——你就可以很好地设计出可以帮助你取得成功的重要指标。当你专注于全局成果如质量时生产力就会随之而来。其他一些人也发现了这一点。John Seddon说得很好“矛盾的是当管理者关注生产力时很少能实现长期改善。而当他们关注质量时生产力反而会不断提升。“关于作者Nicole Forsgren 是一位IT影响力专家指导领导者和技术专家如何释放技术变革的潜力。她是DevOps、IT采用和影响力以及知识管理方面的顾问、专家和研究员。她是DevOps Research and AssessmentDORA与Gene Kim和Jez Humble合的联合创始人、首席执行官兼首席科学家。她是ACM Queue编辑委员会成员也是克莱姆森大学和佛罗里达国际大学的学术合作伙伴。Nicole拥有管理信息系统博士学位和会计硕士学位已发表多篇期刊论文并获得公共和私人研究资助资助者包括NASA和NSF。参考【1】WeinbergGerald M质量软件管理第1卷系统思考。纽约多塞特郡出版社1992年。原文地址http://www.infoq.com/cn/articles/measuring-tech-performance-wrong.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
