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

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

认可方式可以确保每个开发软件的人具备一定的知识和能力。但是,专业开发人员也不能保证良好的软件。即使是训练有素、经验丰富并全力以赴的开发人 员,他们创建的软件,也不能保证都是良好的软件。这是因为大多数影响软件质量的决定,不是由开发人员下的——而是由企业中的其他人决定的。(比如这篇文章 《 软件开发项目失败的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上,最新的公告显示,苹果正在提供更多的时间,以确保他们的软件质量。我们期待这或许是一个迹象,一个表明管理层已经开始理解质量和可靠性是多么重要的迹象。

管理人员:请不要重蹈覆辙

如果像微软和苹果这样的超级公司,有着这么多的人才和资金,依然不能创建出高质量的软件,那么我们这些小虾米又怎么能办到呢?很简单。不要再犯同样的错误:

  1. 将产品推向市场的速度和成本摆在其他任何事情的首位。督促团队像敢死队一样在期限前 完成任务。喊着冲刺的口号:要求速度,不给团队正确做事的时 间,也不给他们停下来反思和改善的机会。我们虽然得在期限和预算内开展工作,但在大多数情况下,企业还是有余地的。敏捷方法和增量交付提供了一条当你很难 谈判最后期限或成本时的出路。如果你不能说不,那么你可以说“还不行”。铁面无私地安排优先工作,确保你尽可能快地发布重要的事情。并且由于这些事情的重 要性,所以一定要确保做得正确。

  2. 从头到尾拒绝测试。这意味着结束之后,依然会残留没有修复的bug。也意味着交付延 迟,因为bug太多。训练有素的敏捷实践依赖于测试——和修复 ——在你的编码过程中。 TDD甚至会强迫你在写代码之前测试。持续集成可以确保每次检查的时候代码都能工作。也就是说不让bug有任何可趁之机。

  3. 不与客户交流,也不早点测试点子。不去了解为什么他们需要软件,他们如何使用软件,他们喜欢软件哪里,哪里又是他们所讨厌的地方。递增式地发布,并获取反馈。按照反馈行事,并改进软件。循环往复。

  4. 忽略基本又良好的工程实践。装得好像你的团队不需要做这些事情,或没有能力和时间来 做这些事一样,即使我们很早以前就知道正确地做事有助于更快地 发布更好的软件。作为项目经理或产品所有者或企业老板,虽然你不需要成为软件工程方面的专家,但是如果你不能深入了解软件是如何构建的以及软件应该如何被 构建这些基本原理,那么就作不出明智的权衡决策。关于如何才能做好软件开发的资讯很多,你没有理由不好好学习。

  5. 忽略警告标记。倾听开发人员的建议,当他们告诉你什么不能做,什么不应该做,或必须做什么事情的时候。开发人员一般都不太愿意和人扯淡。所以,当他们告诉你,他们不会做某件事,或者不应该做某件事的时候,一定要注意。

当你犯错误的时候——别否认,你一定会犯错误,要从中吸取经验教训,不要浪费这个学习的机会。当出错的时候,让团队来审查以搞清楚出了什么问题,为什么,以及如何可以做得更好。从纠错审查和测试中学习。认真对待客户的负面反馈。这是很重要的信息。所以要重视。

作为一个管理者,你能做的最重要的事情是不要带领你的团队走向失败。这要求并不过分,并且也不需要你做太多。