现在有很多糟糕的软件。不可靠，不稳定，不安全，不可用。这些软件是如此糟糕，以致于有些人要求监管软件开发和限制专业软件开发人员为“软件工程师”，以便于软件工程师能够保持专业水准，避免因为疏忽或玩忽职守而被指责。
认可方式可以确保每个开发软件的人具备一定的知识和能力。但是，专业开发人员也不能保证良好的软件。即使是训练有素、经验丰富并全力以赴的开发人 员，他们创建的软件，也不能保证都是良好的软件。这是因为大多数影响软件质量的决定，不是由开发人员下的——而是由企业中的其他人决定的。（比如这篇文章 《软件开发项目失败的3个原因》提到的几个原因）
产品经理和产品负责人，项目经理和程序经理，执行发起人， CIO和CTO以及工程副总裁。这些人决定了什么是重要的事情，要做什么，不应该做什么，以及谁来做——哪些问题需要***秀的人去解决，哪些工作可以外包 以便于节约成本。决定雇佣和解雇的人，才是决定要花多少钱在培训和工具上面的人。
管理者——不是开发人员——决定了企业对质量的选择——哪里必须***，哪里“差不多”就行。
管理误区
作为一个管理者，我在我的职业生涯中作过很多错误和糟糕的决策。不要求长期质量以降低成本。替团队签约却无法在***期限前完成合同。让市场来掌控计 划安排和优先事项，挤出更多的功能使客户和营销经理满意。不顾开发人员和测试人员告诉我的软件还没有准备好，以及没有足够的时间让他们做好事情。不管技术 负债的增加。坚持现在或永远不交付，但是后来莫名其妙地就搞定了。
我从这些错误中吸取了经验教训。我觉得现在我知道构建良好的软件需要什么了。我会坚持这些理念。但是，我时常看到其他管理人员犯着与我相同的错误。即使是世界上***和最成功的科技公司——微软和苹果也不例外。
这些巨鳄能够掌控潮流的走向。他们能够决定他们要创建什么，以及什么时候发布。他们有世界上最棒的工程天才。他们拥有所有钱可以买得到的好工具——并且如果他们需要更好的工具，他们可以为自己写出来。他们知道如何正确地做事情，他们有资金有规模，足以完成一个个挑战。
他们应该写出漂亮的软件。使用他们的软件时候应该是让人愉快的。但现实中却并非如此。而这不是工程师的错。
微软质量
微软的软件质量问题由于存在的时间长，以致于“微软质量”已成为一个公认的术语，意味着“差强人意”的软件，可以勉强被接受——虽然有时软件并不那么好。
即使在微软成为占全球主导地位的供应商后，质量仍然是一个问题。《Computer World》于2014年发表了一篇名为《At Microsoft, quality seems to be job none》的文章，抱怨Windows 10的早期版本有严重的质量和可靠性问题。Windows 10原本被认为代表了微软在其新的CEO的执掌下发生的一个翻天覆地的变化，是一个弥补过去错误，把事情做好的机会。那么为什么还是会出现问题呢？
由于一直以来推崇的“差不多”的软件文化和传统，微软似乎被困住了，无法改善这种情况，即使他们已经认识到，“差不多”的理念已经不适合这个时代了。这是一个深层次的企业和文化问题。是管理的问题。而不是工程师的问题。
苹果的软件质量问题
苹果和微软专注的技术领域不同，主要依赖设计和工程的卓越性赚钱。但是，如果说到软件，苹果也不比微软好。
从苹果地图，到iTunes和App Store不断涌现的问题，更新iOS安装失败的问题，iCloud数据丢失，严重的安全漏洞，没有任何意义的错误消息，莫名其妙限制使用的问题，苹果软件在很多基础的地方以一种尴尬的方式令人失望。
和微软相同，苹果的管理层似乎也陷入迷途中：
我担心苹果的领导层并没有认识到软件缺陷使得声誉受损的严重性，因为如果他们意识到的话，他们必然会做出重大改变以避免这种情况的发生。然而现在并没有，相反的，多个产品线的更新步伐似乎是正在扩大和加速。
我怀疑苹果软件的快速下滑，是一个表明现在的苹果将市场的优先地位摆得过高的信号：每年都发布一个重要的新版本，显然对于工程团队来说既要跟上速度，同时 又保持品质是不可能的。也许你认为这是工程问题，但我怀疑不是——我怀疑没有任何一个工程团队能够在保证时间的同时，维持一个明显又更高的质量。
Marco Arment，《Apple has lost the functional high ground》，2015年1月4日
在今年的WWDC上，***的公告显示，苹果正在提供更多的时间，以确保他们的软件质量。我们期待这或许是一个迹象，一个表明管理层已经开始理解质量和可靠性是多么重要的迹象。
管理人员：请不要重蹈覆辙
如果像微软和苹果这样的超级公司，有着这么多的人才和资金，依然不能创建出高质量的软件，那么我们这些小虾米又怎么能办到呢？很简单。不要再犯同样的错误：
-
将产品推向市场的速度和成本摆在其他任何事情的首位。督促团队像敢死队一样在期限前完成任务。喊着冲刺的口号：要求速度，不给团队正确做事的时 间，也不给他们停下来反思和改善的机会。我们虽然得在期限和预算内开展工作，但在大多数情况下，企业还是有余地的。敏捷方法和增量交付提供了一条当你很难 谈判***期限或成本时的出路。如果你不能说不，那么你可以说“还不行”。铁面无私地安排优先工作，确保你尽可能快地发布重要的事情。并且由于这些事情的重 要性，所以一定要确保做得正确。
-
从头到尾拒绝测试。这意味着结束之后，依然会残留没有修复的bug。也意味着交付延迟，因为bug太多。训练有素的敏捷实践依赖于测试——和修复 ——在你的编码过程中。 TDD甚至会强迫你在写代码之前测试。持续集成可以确保每次检查的时候代码都能工作。也就是说不让bug有任何可趁之机。
-
不与客户交流，也不早点测试点子。不去了解为什么他们需要软件，他们如何使用软件，他们喜欢软件哪里，哪里又是他们所讨厌的地方。递增式地发布，并获取反馈。按照反馈行事，并改进软件。循环往复。
-
忽略基本又良好的工程实践。装得好像你的团队不需要做这些事情，或没有能力和时间来做这些事一样，即使我们很早以前就知道正确地做事有助于更快地 发布更好的软件。作为项目经理或产品所有者或企业老板，虽然你不需要成为软件工程方面的专家，但是如果你不能深入了解软件是如何构建的以及软件应该如何被 构建这些基本原理，那么就作不出明智的权衡决策。关于如何才能做好软件开发的资讯很多，你没有理由不好好学习。
-
忽略警告标记。倾听开发人员的建议，当他们告诉你什么不能做，什么不应该做，或必须做什么事情的时候。开发人员一般都不太愿意和人扯淡。所以，当他们告诉你，他们不会做某件事，或者不应该做某件事的时候，一定要注意。
当你犯错误的时候——别否认，你一定会犯错误，要从中吸取经验教训，不要浪费这个学习的机会。当出错的时候，让团队来审查以搞清楚出了什么问题，为什么，以及如何可以做得更好。从纠错审查和测试中学习。认真对待客户的负面反馈。这是很重要的信息。所以要重视。
作为一个管理者，你能做的最重要的事情是不要带领你的团队走向失败。这要求并不过分，并且也不需要你做太多。
译文链接：http://www.codeceo.com/article/donot-blame-programmer.html
英文原文：Don’t Blame Bad Software on Developers – Blame it on their Managers
