不要将糟糕的软件归咎于开发人员——归咎于他们的经理

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸:仿小红书(微服务架构)》 正在持续爆肝中,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...点击查看项目介绍 ;
  • 《从零手撸:前后端分离博客项目(全栈开发)》 2 期已完结,演示链接: http://116.62.199.48/ ;

截止目前, 星球 内专栏累计输出 63w+ 字,讲解图 2808+ 张,还在持续爆肝中.. 后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,权限管理,Spring Cloud Alibaba 微服务等等,已有 2200+ 小伙伴加入学习 ,欢迎点击围观

那里有很多糟糕的软件。不可靠、不安全、不安全和不可用。情况变得如此糟糕,以至于一些人要求对软件开发和 授权软件开发人员 作为“软件工程师”进行监管,以便他们可以遵守 专业标准 ,并可能 因疏忽或玩忽职守而被起诉

许可将确保开发软件的每个人都至少具有基本的知识水平和 可接受的能力水平 。但是许可开发商并不能确保提供好的软件。即使是训练有素、经验丰富且忠诚的开发人员也不能总是构建出好的软件。因为大多数驱动软件质量的决策不是由开发人员做出的——它们是由组织中的其他人做出的。

产品经理和产品负责人。项目经理和项目经理。执行赞助商。 CIO、CTO 和工程副总裁。决定什么对组织很重要、什么可以完成、什么不能完成以及由谁来决定的人——最优秀的人在解决什么问题,什么工作被转移到海外或外包以节省成本。负责招聘和解雇的人,决定在培训和工具上花费多少钱的人。决定人们如何组织以及他们遵循什么流程的人。以及他们有多少时间来完成他们的工作。

经理——而不是开发人员——决定质量对组织意味着什么。什么是好的,什么是“足够好”。

管理失误

作为一名经理,我在我的职业生涯中犯过很多错误和错误的决定。降低质量以降低成本。在无法满足的最后期限前签约团队。让营销人员控制日程安排和优先级,尝试加入更多功能以使客户或营销主管满意。压倒那些告诉我软件还没有准备好,他们没有足够的时间来正确地做事的开发人员和测试人员。让技术债务加起来。坚持我们必须现在交付或永远不会交付,并且我们会以某种方式在以后解决问题。

我从这些错误中吸取了教训。我想我现在知道构建好的软件需要什么了。我试着坚持下去。但我一直看到其他经理犯同样的错误。即使是在世界上最大、最成功的科技公司,如 Microsoft 和 Apple 等组织中。

这些是控制自己命运的组织。他们可以决定要构建什么以及何时需要交付它。他们拥有世界上最优秀的工程人才。他们拥有金钱可以买到的所有好工具——如果他们需要更好的工具,他们会自己编写。他们已经存在了足够长的时间,知道如何正确地做事,而且他们有足够的资金和规模来完成它。

他们应该编写漂亮的软件。使用起来很愉快的软件,我们其他人可以效仿。但他们甚至没有接近。这不是工程师的错。

微软质量

Microsoft 的软件质量问题由来已久,以至于“ Microsoft 质量 ”已成为一个公认的术语,指的是勉强“足够好”而勉强被接受的软件——有时甚至没有那么好。

即使在 Microsoft 成为占主导地位的全球企业供应商之后,质量仍然是一个问题。 2014 年计算机世界的一篇文章“ 在微软,质量似乎不是工作 ”抱怨早期版本的 Windows 10 存在严重的质量和可靠性问题。但 Windows 10 应该代表微软在新 CEO 领导下的翻天覆地的变化,一个机会弥补过去的错误,把事情做好。那么出了什么问题呢?

足够好 ”软件的文化和传统已经存在了很长时间,以至于微软似乎被困住了,即使他们已经认识到“足够好”已经不够好,也无法改进。这是一个根深蒂固的组织和文化问题。一个管理问题。不是工程问题。

苹果的软件质量问题

Apple 将自己与 Microsoft 和其他技术领域区分开来,并根据其在设计和工程卓越方面的声誉收取溢价。但在软件方面,苹果并不比任何人好。

Apple Maps 史诗般的公众形象工厂,到 iTunes App Store 中不断出现的问题,iOs 更新安装失败的问题, iCloud 中某处丢失的 数据,严重的 安全漏洞 ,毫无意义的错误消息,以及 令人困惑的不一致 和对可用性的限制,Apple 的 软件经常以基本和令人尴尬的方式令人失望

和微软一样,苹果管理层似乎迷失了方向:

我担心 Apple 的领导层并没有完全意识到他们的软件缺陷对他们的声誉造成了多么严重和严重的损害,因为如果他们意识到这一点,他们就会做出看似没有发生的重大改变。相反,似乎正在发生相反的情况:多个产品线的快速更新步伐似乎正在扩大和加快。

我怀疑 Apple 软件的迅速衰落表明,如今 Apple 将营销放在首位:工程团队显然不可能在保持质量的同时每年都发布重要的新版本。也许这是一个工程问题,但我怀疑不是——我怀疑任何有凝聚力的工程团队都能跟上这些需求并保持更高的质量。

Marco Arment, Apple 失去了功能制高点 ,2015-01-04

最近在今年的 WWDC 上发布的公告表明,Apple 正在花一些额外的时间来确保他们的软件能够正常工作。 更多的光洁度,更少的闪光 。我们将不得不拭目以待,看看这是暂时的停顿,还是管理层开始理解(或记住)质量和可靠性的实际重要性的迹象。

管理者:停止犯同样的错误

如果像 Microsoft 和 Apple 这样的公司,凭借他们所有的人才和资金,都不能构建高质量的软件,那么我们其他人应该如何去做呢?简单的。通过不犯同样的错误:

  1. 将上市速度和成本放在首位。迫使人们太过努力以致于无法达到“放弃死期”。从字面上理解“冲刺”:尽可能快,不给团队时间做正确的事情,也不给团队停下来反思和改进的机会。
    我们都必须在截止日期和预算内工作,但在大多数业务情况下,都有做出明智决策的空间。当您无法协商截止日期或成本,并且不了解或无法控制范围时,敏捷方法和增量交付提供了一条出路。如果你不能说不,你可以说“还没有”。无情地确定工作的优先级,并确保尽早交付重要的事情。因为这些事情很重要,所以要确保你做对了。
  2. 把测试留到最后。这意味着将错误修复留到结束之后。这意味着交付延迟且错误太多。
    有纪律的敏捷实践都依赖于在编写代码时进行测试和修复。 TDD 甚至会强制您在编写代码之前编写测试。持续集成确保代码在每次有人签入时都能正常工作。这意味着没有理由让错误累积。
  3. 不与客户交谈,不及早测试想法。不了解他们为什么真正需要该软件,他们实际如何使用它,他们喜欢它的什么地方,他们讨厌它的什么地方。
    逐步交付并获得反馈。根据此反馈采取行动,并改进软件。冲洗并重复。
  4. 忽略基本的良好工程实践。假装您的团队不需要做这些事情,或者负担不起或没有时间做这些事情,即使我们多年来一直知道 正确地做事有助于更快地交付更好的软件 .
    作为项目经理、产品负责人或业务负责人,您无需成为软件工程方面的专家。但是,如果不了解软件构建方式以及应该如何构建软件的基本原理,就无法做出明智的权衡决策。那里有很多关于如何正确进行软件开发的有用信息。没有理由不学习它。
  5. 忽略警告标志。
    当开发人员告诉您某些事情不能做、不应该做或必须做时,请听取他们的意见。开发人员通常太愿意签约太多,无法达到太远。因此,当他们告诉您他们不能做某事或不应该做某事时,请注意。

当你犯错时——你会犯错,从中吸取教训,不要浪费它们。当出现问题时,让团队在回顾中对其进行审查,或者进行 无可指责的事后分析 ,以弄清楚发生了什么、为什么,以及如何才能变得更好。从审计和渗透测试中学习。认真对待客户的负面反馈。这是重要的、有价值的信息。相应地对待它。

作为一名经理,你能做的最重要的事情就是不要让你的团队失败。这并不过分。

相关文章