如何说服管理层质量保证是重要的？

Question

我为少于10名程序员的小型软件公司工作。我们的软件安装在世界各地的数十个地方。我们的代码库非常庞大，主要原因是设计不佳和大量代码重复（IMO）。我们有大约30个不同的项目，每个项目总共约600个KLOC，其中约200个KLOC是我们自己开发的代码。当我在2006年到达那里时，这段代码甚至没有受到版本控制。我已经设法说服权力它的重要性，我们现在使用代码控制系统（cs-rcs，不是我的选择，但它比nothin更好），以及一个bug跟踪系统。巨大的缺失是整个过程中完全缺乏质量保证。我们的发布过程在纸上是不存在的，在实践中它包括“命中ctrl-F9，将二进制文件复制到客户端，声明问题已修复。”

有人能指出一些官方文件或PHB语言文件或文章，可以解释这个过程中的公然疯狂吗？我相信老板可以聘请一些顾问告诉他这个，然后他可能会相信。但我只是一名软件工程学士学位的维护人员。我的种族对我也没有帮助。在这种情况下使用的最佳弹药是什么？

Answer 1

在这种情况下，你最好的弹药是等待不可避免的灾难。一旦发生这种情况，让你的所有鸭子连续计划，这将导致这场灾难再也不会发生，强调实施的成本远远低于灾难本身的成本。

如果PHB首先不想要“它”，那么任何谈话都不会使PHB“得到它”。只有那个严厉的大师 - 现实 - 面对一大笔才能最终说服他们。

哦，当你在这里时，更新你的简历并开始寻找。倾向于说服人们需要质量保证的灾难与杀害公司的灾难非常相似。

Answer 2

金钱是你最好的选择 - 在支付方面它会受到最大的伤害 我认为以下图片说明了一切：
（图片来自www.developertesting.com）

Answer 3

在同义上，说服他们的唯一方法就是将他们放在一些令人信服的事物面前。那个东西可以从以下列表中得出：

• 预示着采用先前提出的解决方案的昂贵的灾难
• 的 一场不为人知的灾难 现成的永不再来的解决方案
• 甲 出色的说服力预示 灾难
• 一个出色的 有说服力的贪婪诉求（拯救 预告的机会成本 灾难）

或者别的什么。在所有这些情况下，某人将不得不在某种程度上为您提出的质量保证解决方案做出判断，而且从某种角度来看，某人必须是您。所以我开始学习说服力。

How to Win Friends and Influence People最多只需花费几美元。 Getting To Yes也很便宜。

您是如何获得源代码控制协议的？你可以继续小费，一次改进一个小的增量吗？

尝试谷歌搜索“change your organization”，看起来有一些很有希望的链接。

最后，请记住（如同一位智者曾经说过的话），如果你无法改变你的组织，那么你应该改变你的组织。确实总有另一种选择。

Answer 4

除了两件事之外，管理层不会理解任何事情：（1）成本效益＆amp; （2）客户满意度。第二个很难量化，但第一个很容易。你可以花费4万到6万美元购买一个体面的QA工程师，他可以进入并开始理解这个混乱并开始围绕它制定计划。成本效益来自于确保高技能工程师不必花费2个月来追踪隐藏在100k行代码中的错误。

还有另一种方法可以解决这个问题......你可以在我工作的地方做我们正在做的事情。开始在开始时编写代码测试，然后在完成代码的时候开始编写代码，如果测试通过，那么你就是金色的。测试通过后，您将进行测试，以确保您是否能够立即打破您将了解的代码。如果你让其他程序员参与其中，那么至少所有新代码都将在测试框架下开发。 Test driven development不仅使流程变得更快（您在开始编码之前已经知道了想要的结果），而且还有助于快速完善您的需求。最重要的是，通过一点社交工程（与同行合作），您可以一点一点地改变开发文化，直到流程完成。

Answer 5

我可以推荐丰田之路。短版本通常可以从丰田网站免费订购。管理层应该已经阅读过，但显然他们没有。阅读，消化它，让管理层阅读它。为了获得灵感，我可以真正推荐阅读Lessons from Toyota's Long Drive（获得PDF文件非常值得花钱）。

Answer 6

也许如果你让一些程序员同事支持你，管理层会更愿意倾听。你不需要天才就能意识到一个巨大的，笨拙的代码库表明还有很大的改进空间。

Answer 7

参考Joel的book

Answer 8

如果你的管理层不认为质量保证很重要，有一些非常明显和“常识”到任何外行人会同意的地步，那么我认为不会提出一堆学术论文或其他任何内容。问题，对他们来说会有所不同。

你唯一的希望可能是试图整理一份能显示成本节省的文件，但我怀疑在这种情况下会有所帮助。

Answer 9

我在一个部门工作，在这个部门中，公共池在开发任务和测试之间轮换。这完成了两件事：

• 技术娴熟，高效的测试人员，他们最不知道代码尝试做什么，以及如何
• 知道轮到他们的开发人员正在进行测试，或刚刚从测试中返回的开发人员。因此，测试错误代码的痛苦是众所周知的，测试好代码的乐趣也是如此。

整个小组中最受尊敬的人是一个无情的测试人员，在开发时，会产生零缺陷软件。