Project management 我们可以从工程和建筑行业学到哪些项目管理经验和最佳实践？

众所周知，It项目的失败率令人震惊（一些调查表明失败率超过60%）。通常，项目经理试图从这些失败中“恢复”，或者通过压缩他们的资源来加班，或者通过降低可交付成果的质量（减少测试工作量、缩小范围等）。不幸的是，软件质量并没有被企业领导者视为非常重要

我想知道其他职业是否也是这样？例如，在失败成本非常高、单一错误可能造成灾难性后果的建筑行业，如何管理项目？像欧洲隧道和马石油塔这样的大型工程项目需要数千人和数十亿美元的建设，但这些项目中的大多数都在时间内或有时甚至提前成功完成

---

在其他行业如何规划和管理项目，我们可以从中吸取一些教训吗？

软件开发和工程或建筑行业之间存在差异——规范总是可以更改的

水上行走与发展 规范中的软件很简单 如果两者都冻结了

--爱德华五世贝拉德（）

---

在“书”的开头，你可以更详细地解释项目管理方法的不同之处。我认为最大的区别是他们永远不会考虑用我们所给出的同样的劣质要求开始一个项目。也许我们也应该停止这样做，迫使人们在开始编写代码之前真正定义他们想要的东西

---

我想补充一点，作为一个行业，当需求（比如需求）发生变化时，我们需要一个新的时间表和预算，这是一项糟糕的工作。我们开始在这里做更多的推回，告诉客户所请求的更改需要多少小时（和更多的钱），在现有的截止日期前再加上两天，让他们正式提出更改请求。一旦我们坚持要为变更支付费用，请求对初始需求进行变更的数量急剧下降。这一变化也将我们从公司的成本中心转移到了利润中心，因为我们做了很多额外的工作，但向客户收取的费用不超过最初的估算。

让我们以一座桥梁为例，将其与软件进行比较

桥梁的外部规格将更少。它将有一些非常严格的规格，但其中许多将是内部的（如材料强度）

它将由知道桥梁设计不会过于匆忙的人设计。一般来说，土木工程师比软件开发人员更能得到管理层的尊重。此外，土木工程师还将在一个更受约束的问题空间中工作。制造桥梁的方法远不如库存系统多

设计完成后，一名或多名持有执照的专业工程师将在设计上签字。这是接受真正的责任。（或者，没有一个PE会把他或她的许可证押在它的可靠性上，设计也不会去任何地方。）这不会发生在软件中，部分原因是问题空间是如此的不受约束

最后，大桥将建成，这将需要几个月的时间和大量的重型设备。软件最初将使用编译器构建，然后使用廉价工具无限期地复制。这里有一个很大的心理意义：人们倾向于认为项目具有重要的设计和重要的制造阶段，如果制造过于琐碎，则倾向于认为设计的一部分是制造

如果软件更像土木工程，我们将需要标准的做法，充分和可靠的，为大多数事情。我们需要工程师研究这些实践，并愿意证明软件设计是否正确，事实上，我们需要根据这些实践完成的项目几乎完全可靠。我们需要更正式地承担责任。我们需要更多的外部尊重，因为不敢插手一个1000万美元的建设项目的管理者通常会毫不犹豫地把一个2000万美元的软件项目搞砸

---

简而言之，软件作为一门学科太不成熟，无法像土木工程那样工作。

从工程中可以学到的一个教训：尊重非功能性需求

功能需求已经够难了，因为他们希望用户、开发人员、分析师和其他相关人员能够定义业务所需的内容

非功能性需求是工程师和技术人员提出的，功能性人员可能对此视而不见的东西。很容易忽视或轻视非功能性。我在过去工作过的一些项目经理不想听到关于非职能人员的消息，因为他们不能直接与业务需求联系在一起，并且引入的任务会威胁到“按时按预算”的指标

示例

功能要求：豪华船必须能够承载X个数量的乘客

非功能性要求：船大到足以承载X数量的乘客，需要有船体Y单元厚，以保持完整性，即使与冰山碰撞

计算成本

为什么软件PM不尊重非功能性需求？因为这种不尊重的代价对于工程和软件开发来说是不同的

在我的船上，忽视非功能性要求的成本示例：生命损失

忽视软件中的非功能性的代价：一些被称为技术债务（technicaldebt）的软弱无力的东西，稍后将由人们支付