I think the biggest difference is that they would never consider starting a project with the same kind of shoddy requirements we are given. Maybe we should stop doing so as well and force people to actually define what they want before we start trying to code it.
I wanted to add that we as an industry to a lousy job of pushing back with a new timeline and budget when the requirements (such as they are) change. We started to do much more of this pushback here, telling the customer how many more hours (and more money) the requested change would take, adding the two extra days to do the the exisitng deadline and making them formally put in a request for change. The number of requested changes to intial requirments dropped drastically once we insisted there would be a cost for the change. This change also moved us from a cost center to a profit center in the company as we were doing a lot of extra work but not charging the customer more than the intial estimate.
Let's take a bridge as an example, and compare it with software.
The bridge will have fewer external specifications. It will have some pretty exacting specifications, but a lot of those will be internal (such as material strengths).
It will be designed by people who know that bridge design is not to be excessively rushed. In general, civil engineers will get more respect from their management than software developers. The civil engineers will in addition be working in a much more constrained problem space. There aren't nearly as many ways to make a bridge as an inventory system.
When the design is done, one or more licensed professional engineers will sign off on it. This is accepting real responsibility. (Alternately, no PE will bet his or her license on its soundness, and the design won't go anywhere.) This doesn't happen in software, partly because the problem space is so unconstrained.
Finally, the bridge will be built, and this will take months and a lot of heavy equipment. Software will be built initially with a compiler and reproduced indefinitely with cheap tools. There is a great psychological significance here: people tend to think of projects as having significant design and significant manufacturing stages, and if manufacturing is too trivial tend to think of part of the design as manufacturing.
If software were to be more like civil engineering, we'd need standard practices, adequate and reliable, for most things. We'd need engineers to study those practices, and be willing to certify that software either was or was not designed properly, and in fact we'd need projects done according to those practices to be almost completely reliable. We'd need more formal assumption of responsibility there. We'd need more external respect, because managers that will not dare throw away a $10 million construction project by meddling will often have no qualms about messing up a $20 million software project.
In short, software is too immature a discipline to work like civil engineering.
A lesson that can be learned from engineering: respect the non-functional requirements.
Functional requirements are hard enough, as they expect the users, developers, analysts and anyone else involved to be able to define what is needed to do business.
Non-functional requirements are the things engineers and technical people come up with that functional people may be blind to. It's very easy to overlook or downplay the non-functionals. Some PMs I've worked with in the past did not want to hear about non-functionals because they couldn't directly be tied to business needs and introduced tasks that would threaten the metrics of "on time and on budget".
Example
Functional requirement: Luxury ship must be able to carry X amount of passengers
Non-functional requirement: Ship big enough to carry X amount of passengers needs to have hull Y units thick to sustain integrity even upon impact with icebergs
Counting the Cost
Why don't software PMs respect non-functional requirements? Because the cost for such disrespect is different for engineering than it is for software development.
Cost of disregard for non-functional requirements in my ship example: loss of life.
Cost of disregard for non-functionals in software: some wimpy thing called technical debt, which will later be paid for by people long removed from the project team and the project team's completion bonuses.
Granted my examples are simplistic. Not all engineering foibles lead to death while some faulty software certainly can (avionics, medical, or traffic control systems being a few examples). But I think you get the idea.
发布评论
评论（4）
我认为最大的区别是他们永远不会考虑以与我们相同的劣质要求开始一个项目。也许我们也应该停止这样做，并迫使人们在我们开始尝试编码之前真正定义他们想要的东西。
我想补充一点，我们作为一个行业，在需求（例如需求）发生变化时推迟新的时间表和预算是一项糟糕的工作。我们开始在这里做更多的反击，告诉客户所请求的更改还需要多少小时（和更多的钱），增加额外的两天来完成现有的截止日期，并让他们正式提出更改请求。一旦我们坚持认为更改会产生成本，对初始需求的请求更改数量就会急剧下降。这一变化也使我们从公司的成本中心转变为利润中心，因为我们做了很多额外的工作，但向客户收取的费用却没有超过最初的估计。
I think the biggest difference is that they would never consider starting a project with the same kind of shoddy requirements we are given. Maybe we should stop doing so as well and force people to actually define what they want before we start trying to code it.
I wanted to add that we as an industry to a lousy job of pushing back with a new timeline and budget when the requirements (such as they are) change. We started to do much more of this pushback here, telling the customer how many more hours (and more money) the requested change would take, adding the two extra days to do the the exisitng deadline and making them formally put in a request for change. The number of requested changes to intial requirments dropped drastically once we insisted there would be a cost for the change. This change also moved us from a cost center to a profit center in the company as we were doing a lot of extra work but not charging the customer more than the intial estimate.
我们以桥为例，将其与软件进行比较。
该桥的外部规格将减少。它将有一些非常严格的规格，但其中很多都是内部规格（例如材料强度）。
它将由那些知道桥梁设计不应过于仓促的人来设计。一般来说，土木工程师比软件开发人员会得到管理层更多的尊重。此外，土木工程师将在更加受限的问题空间中工作。建造桥梁的方法没有库存系统那么多。
设计完成后，将由一名或多名持有执照的专业工程师签字。这就是接受真正的责任。 （或者，没有一个 PE 会把他或她的许可押在其健全性上，并且设计不会有任何进展。）这种情况在软件中不会发生，部分原因是问题空间如此不受约束。
最后，这座桥将建成，这将需要数月时间和大量重型设备。软件最初将使用编译器构建，并使用廉价工具无限期地复制。这里有一个很大的心理意义：人们倾向于认为项目具有重要的设计和重要的制造阶段，如果制造太琐碎，则倾向于将设计的一部分视为制造。
如果软件更像土木工程，那么我们就需要针对大多数事情的充分且可靠的标准实践。我们需要工程师研究这些实践，并愿意证明软件设计是否正确，事实上，我们需要根据这些实践完成的项目几乎完全可靠。我们需要在那里更正式地承担责任。我们需要更多的外部尊重，因为那些不敢通过干预而放弃 1000 万美元建设项目的管理者往往会毫不犹豫地搞砸一个 2000 万美元的软件项目。
简而言之，软件作为一门学科还太不成熟，无法像土木工程那样发挥作用。
Let's take a bridge as an example, and compare it with software.
The bridge will have fewer external specifications. It will have some pretty exacting specifications, but a lot of those will be internal (such as material strengths).
It will be designed by people who know that bridge design is not to be excessively rushed. In general, civil engineers will get more respect from their management than software developers. The civil engineers will in addition be working in a much more constrained problem space. There aren't nearly as many ways to make a bridge as an inventory system.
When the design is done, one or more licensed professional engineers will sign off on it. This is accepting real responsibility. (Alternately, no PE will bet his or her license on its soundness, and the design won't go anywhere.) This doesn't happen in software, partly because the problem space is so unconstrained.
Finally, the bridge will be built, and this will take months and a lot of heavy equipment. Software will be built initially with a compiler and reproduced indefinitely with cheap tools. There is a great psychological significance here: people tend to think of projects as having significant design and significant manufacturing stages, and if manufacturing is too trivial tend to think of part of the design as manufacturing.
If software were to be more like civil engineering, we'd need standard practices, adequate and reliable, for most things. We'd need engineers to study those practices, and be willing to certify that software either was or was not designed properly, and in fact we'd need projects done according to those practices to be almost completely reliable. We'd need more formal assumption of responsibility there. We'd need more external respect, because managers that will not dare throw away a $10 million construction project by meddling will often have no qualms about messing up a $20 million software project.
In short, software is too immature a discipline to work like civil engineering.
可以从工程中学到的一个教训：尊重非功能性需求。
功能需求已经足够困难了，因为他们期望用户、开发人员、分析师和其他相关人员能够定义开展业务所需的内容。
非功能性需求是工程师和技术人员提出的东西，而功能性人员可能会忽视。人们很容易忽视或淡化非功能性。我过去共事过的一些项目经理不想听到非职能性的内容，因为它们无法直接与业务需求联系在一起，并且引入的任务会威胁到“按时按预算”的指标。
示例
功能要求：豪华船舶必须能够承载 X 数量的乘客
非功能要求：船舶足够大，可以承载 X 数量的乘客需要使船体 Y 单元变厚，以便即使在与冰山撞击时也能保持完整性
计算成本
为什么软件 PM 不尊重非功能性需求？因为这种不尊重的成本对于工程和软件开发来说是不同的。
在我的船舶示例中忽视非功能性需求的成本：人员伤亡。
忽视软件中非功能性的成本：一些被称为技术债务的软弱事物，稍后将由长期从项目团队中移除的人员和项目团队的完成奖金来支付。
当然我的例子很简单。并非所有的工程缺陷都会导致死亡，而一些有缺陷的软件肯定会导致死亡（例如航空电子设备、医疗或交通控制系统）。但我想你明白了。
A lesson that can be learned from engineering: respect the non-functional requirements.
Functional requirements are hard enough, as they expect the users, developers, analysts and anyone else involved to be able to define what is needed to do business.
Non-functional requirements are the things engineers and technical people come up with that functional people may be blind to. It's very easy to overlook or downplay the non-functionals. Some PMs I've worked with in the past did not want to hear about non-functionals because they couldn't directly be tied to business needs and introduced tasks that would threaten the metrics of "on time and on budget".
Example
Functional requirement: Luxury ship must be able to carry X amount of passengers
Non-functional requirement: Ship big enough to carry X amount of passengers needs to have hull Y units thick to sustain integrity even upon impact with icebergs
Counting the Cost
Why don't software PMs respect non-functional requirements? Because the cost for such disrespect is different for engineering than it is for software development.
Cost of disregard for non-functional requirements in my ship example: loss of life.
Cost of disregard for non-functionals in software: some wimpy thing called technical debt, which will later be paid for by people long removed from the project team and the project team's completion bonuses.
Granted my examples are simplistic. Not all engineering foibles lead to death while some faulty software certainly can (avionics, medical, or traffic control systems being a few examples). But I think you get the idea.
软件开发与工程或建筑行业之间存在差异 - 规范总是可以更改。
-- Edward V Berard（从此处）
您可以找到有关差异的更详细说明《极限编程应用》一书开头的项目管理方法。
There is a difference between software development and engineering or contruction industry - a specification always can be changed.
-- Edward V Berard (from here)
You can find more detailed explanation of differences in approach to project management at the beginning of the "Extreme Programming Applied" book.