决策者根据什么曲线做出决策
在关于产品质量的对话中,产品负责人说:“如果测试人员更快地发现问题,我们的工作就会更快。”
测试人员说:“如果开发人员没有提出太多问题,那么我们现在就可以完成。”
开发人员说:“如果您不给我太大压力,我本可以做得更好。”
![](https://i-blog.csdnimg.cn/blog_migrate/f57bf04cefacf812cb9d883652252594.png)
他们没事。
那是因为产品开发是一个工作系统。 如果您给系统的一个部分施加压力,而又没有在其他地方承受这种压力,那么您就会制造出不良的产品。
让我们从测试人员的工作开始。
测试员做什么?
多年前,我写了《有影响力的测试经理》 。 我在那篇文章中说过,测试经理(和测试团队)的任务是:
随时评估开发中产品的状态并报告该状态。
那不是“保证”。 这也不是质量工程。 测试人员无法保证产品质量-他们可以报告产品状态。 测试人员也无法设计产品质量。
只有开发人员才能将质量控制到产品中。 而且,如果他们感到压力,他们会停止的第一件事是什么? 任何技术上的卓越 ,这就是您如何将质量设计到产品中。
开发人员的工程和测试人员的评估都需要时间。
这就是为什么停止测试并不能阻止问题的发生。 停止测试隐藏了问题。 问题仍然存在。 我们不知道他们。
当管理人员决定简化测试时间和测试资源(例如计算机或实验室设备)时,管理人员将决定产品质量。 他们拿起金字塔并将其倾斜。
当经理关注日期和功能时,他们会忽略对缺陷的影响以及实际的发布成本。 (发布的初始成本可能很低。持续的成本非常高。嗯,我可能需要写一篇关于所谓的敏捷团队及其修复缺陷的成本的文章。)
管理决策会影响我们如何谈论问题以及人们在哪里度过的时间。 让我们从我们使用的词开始。
关于单词的管理决策
我讨厌适用于软件的错误一词。 有关软件错误的起源,请参见Wikipedia文章。 请注意,起源是bugaboo或bugbear,指的是怪物。
虫子从外面飞进来。
大多数怪物都是奇幻生物。
这些都不能准确描述软件问题。
我花了很多时间来解决代码,测试,编写等方面的问题。 并且,这些问题中的每一个都具有以下特征:
- 我的队友还是我造成了这个问题。
- 在尝试或发布产品之前,我们没有检查或测试代码或没有进行足够的测试(现在是在撰写本文时)。
我们创建了缺陷,问题,错误,故障。 我们没有创建错误。 而且,我们没有事先检查我们的工作是否具有卓越的技术。
我敦促您重新考虑如何谈论问题。 当我使用诸如缺陷,问题,故障或问题之类的词语时,我们经常更改关于为工作分配时间的讨论。
管理有关时间的决定
我在这篇文章的顶部包括了项目金字塔 。 (该链接指向项目边界系列文章。)
并非每个项目都需要针对低缺陷进行优化。 有时,我们需要为客户提供足够好的产品以进行优化,以便我们学习。
而且,如果您向开发人员施加压力,那么您可能无法获得足够好的产品。 如果您使用压力测试仪,则可能不了解该产品。
压力并不能使人们更快地工作。
这就是为什么我说经理负责质量。 开发人员和测试人员会在系统内部尽最大努力。 而且,如果管理者做出不明智的决定,产品质量将会受到损害。
有助于产品质量的出色管理决策
那么,什么样的管理决策将有助于产品质量?
- 确定您想要看到的结果类型。 当经理选择该项目作为项目组合时,这是战略工作的一部分。 您可能需要特定的产品成果或学习经验。 并且,确定驱动程序,约束和浮动对象的边界 。
- 与其向团队施加压力,不如问他们:“您还需要什么以最快的速度完成最佳工作?”
- 如果您较晚开始项目,请缩小范围并更频繁地释放较小的价值增量。 不要试图将所有内容都塞进一个大版本中。 (从每周到每个月到每个季度到每年对这个想法使用递归。)
管理者创建并完善人们工作的系统。 如果您鼓励技术卓越,那么无论是在开发还是在测试中,您都将获得它。 您也可能会更早获得该产品。 并且,管理资产(产品)的持续成本将更低。
该职位开始时的团队面临压力。 我从未见过外部压力会努力创造更好的产品。 创建一个使人们为工作感到自豪的系统。 他们将尽力而为。 都是因为经理们做出了质量决定。
翻译自: https://www.javacodegeeks.com/2020/06/managers-make-the-real-product-quality-decisions.html
决策者根据什么曲线做出决策