Rah*_*hul 8 project-management
众所周知,IT项目以惊人的速度失败(一些调查显示失败率超过60%).通常情况下,项目经理试图通过挤压他们的资源来延长工作时间或者通过降低可交付成果的质量(减少测试工作量,缩小范围等)来从这些故障中"恢复".不幸的是,商业领袖并不认为软件质量非常重要.
我想知道其他职业是否也是如此？如何管理项目,例如,在建筑行业中,故障成本非常高,而且单个错误可能是灾难性的？像Eurotunnel和Petronas塔这样的大型工程项目需要数千人和数十亿美元来建造,但大多数这些项目都是在有时甚至在时间之前成功完成的.
我们是否可以从中学到如何在其他行业中规划和管理项目？
我认为最大的区别在于他们永远不会考虑以我们给出的相同的劣质要求开始一个项目.也许我们也应该停止这样做,并强迫人们在开始尝试编码之前实际定义他们想要的东西.
我想补充一点,我们作为一个行业,在需求(例如它们)发生变化时,推迟了新的时间表和预算.我们开始在这里做更多的回击,告诉客户要求的更改需要多少小时(和更多钱),再增加两天来完成现有的截止日期并使他们正式提出变更请求.一旦我们坚持要求改变成本,请求的初始要求变更数量急剧下降.这一变化也使我们从公司的成本中心转移到了利润中心,因为我们正在做大量的额外工作,但不会向客户收取超过初始估算的费用.
我们以桥梁为例,并将其与软件进行比较.
该桥将具有更少的外部规格.它将有一些非常严格的规范,但其中很多将是内部的(例如材料优势).
它将由那些知道桥梁设计不会过于仓促的人设计.一般而言,土木工程师将比软件开发人员更受管理者的尊重.此外,土木工程师将在一个更加受限制的问题空间中工作.将桥梁作为库存系统的方法并不多.
设计完成后,一位或多位有执照的专业工程师将签字.这是接受真正的责任.(换句话说,任何PE都不会打赌他或她的许可证在其稳健性上,并且设计不会去任何地方.)这不会发生在软件中,部分原因是问题空间是如此不受约束.
最后,桥梁将建成,这将需要数月和大量的重型设备.软件最初将使用编译器构建,并使用廉价工具无限期地复制.这里有一个很大的心理学意义:人们倾向于认为项目具有重要的设计和重要的制造阶段,如果制造过于琐碎,往往会将设计的一部分视为制造.
如果软件更像土木工程,我们需要标准的做法,足够和可靠,对大多数事情.我们需要工程师来研究这些实践,并愿意证明软件设计得当或设计得不合适,事实上我们需要根据这些实践完成的项目几乎完全可靠.我们需要更正式的责任承担.我们需要更多的外部尊重,因为那些不敢通过干预抛弃1000万美元建筑项目的管理人员通常不会有任何关于弄乱2000万美元软件项目的疑虑.
简而言之,软件就像土木工程一样不成熟.