转载

别怪程序员——都是项目经理的错

现在有很多糟糕的软件。不可靠，不稳定，不安全，不可用。这些软件是如此糟糕，以致于有些人要求监管软件开发和限制专业软件开发人员为“软件工程师”，以便于软件工程师能够保持专业水准，避免因为疏忽或玩忽职守而被指责。

认可方式可以确保每个开发软件的人具备一定的知识和能力。但是，专业开发人员也不能保证良好的软件。即使是训练有素、经验丰富并全力以赴的开发人员，他们创建的软件，也不能保证都是良好的软件。这是因为大多数影响软件质量的决定，不是由开发人员下的——而是由企业中的其他人决定的。（比如这篇文章《软件开发项目失败的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

正文到此结束