软件项目为何失败？

互联网行业一夜之间变富翁的事件不足为奇，但是失败的案例也比比皆是。 因此，如何管理好软件项目俨然成为人们口中经常提及的话题。作者 Harri Paavola发表了《 软件项目为何失败？》这篇博文，笔者从中摘译了一些。我们一起来看下：所谓“失败”也就意味着与他们的预期不一致。”失败可以分为三种：管理问题、工程问题、文化问题，以上三个问题，很难说其中一个问题凌驾于另外两个问题之上或者说某个问题更为常见。 

缺乏远见和权力

几年前，芬兰最高的一座公寓楼就建在了我家附近（与其他城市最高的建筑物相比，这并不算高）。左边呈现的这幅图是当时参与竞赛的设计图，而右边的则是实际呈现出的效果。

建筑行业VS.软件行：举个例子，目前房地产很火，造什么样的房子，只要资金到位，都能保质保量的造好。造10层楼，1层用多少人，每天做什么，很容易计划，分配任务，人力资源，而且需求是不会变的。没见过造房子，盖了3层之后改主意了，拆了重新盖。而软件就大大不同了，需求的变化是不可避免的，而且凡是做过项目的人都知道，需求的变化实际上还挺频繁。这样一来，很容易造成计划赶不上变化。

当工程项目拖延了工期，可以多加人手，把工期赶回来。而软件就不这么简单了，新来的人要熟悉项目的内容就要花时间，工期很难完全赶上。很多IT的老总们体会不到这个问题，总以为多加人手，加班就能搞定。真正的有效的项目管理是要靠一个有效的管理体系来支撑的。

糟糕的开始

许多产品还未完成就被叫停了，这跟产品负责人也有关系。那么，在什么情况下会挑选下一任产品经理来负责该项目呢？——原先的产品负责人不喜欢该产品，对该产品毫不在乎。

当产品负责人对产品没有强烈的欲望时，那么他对产品的质量也不会有太大的要求。如果长期目标威胁到短期目标（奖励机制），他会以快速且不负责的心态完成，如此一来，产品功能也跟着下降，最后呈现出的结果差强人意。比如Nokia推出的手机以及Windows Vista系统，事实表明，很少有人愿意为此而买单。

管理人的软弱

软件开发，尤其是在管理层上，包含大量的政治色彩。有时，高层管理不会让产品负责人追逐他们的梦想。这现象很普遍——不让新的产品蚕食老产品。高层管理人无法接受这样的市场蚕食。长此以往，我们所拥有的都是些残缺的产品。不仅如此，有时其他产品负责人当看到新产品会吃掉现有产品的销售份额时，他们也会发动反击。当然这种行为建立在奖励机制上，销售下降，奖金也会跟着下降。

产品负责人的无能=产品的失败

如果产品负责人对产品没有强烈的责任心，那么该产品必定是失败的；如果产品负责人没有为公司制定梦想，那么产品失败；如果产品负责人敌不过其他产品负责人，那么该产品也是失败的。

发布坏的、不完整、不合适的代码

苹果公司发布的" goto fail"就出现了Bug，这个bug会引起中间人攻击，bug的描述中说，这个问题是因为丢掉了对连接认证的合法性检查的步骤。就这因为这个Bug，所有 iOS设备与SSL有关的都出现了漏洞。Goto Fail成为一个经典事件。

开发商的莫不关心

很多开发者不使用任何静态分析工具以及不执行任何代码审查过程，俨然已经成为一种普遍现象。从代码技术层面来说无需进行高质量的代码审查就意味着该团队中的每一个成员都能编写出高质量的代码。很明显这种假设是错的。

实践证明，大多数团队中至少有一名开发者无法真正做到高效编程。因为每个人都会有心情不好的时候，当某个人意志薄弱时难免会出错。

每个人都想成为老好人

即便在代码审查过程中发现了错误的代码，很多人还是选择随它去了。这是因为每个人都想充当老好人。而通常这类错误的决定以及误解都是由同一类人造成的。

当审查者查找出错误，哪怕是有一丁点错误也不放过，长此以往这就使得审查者与开发者之间不再和谐，开发者认为审查者是在故意找茬，两者的矛盾慢慢就会产生，审查者自身也认为这样显得太过苛刻，于是他们给自己放松了标准。

开放但不等于成功，满足用户所需才是最重要

尽管微软在Windows 8上注入了大量心血，但其市场份额并不理想，业界对此也褒贬不一，很多用户认为Metro界面和老的桌面体系并存，但融合的却不那么平滑，有种非此即彼的分裂感觉。

这里还有两个原因，笔者一句话带过，即不听——大多数不去轻易的尝试产品，不愿倾听别人的反馈；不问——大多数人不会主动去问别人意见。

写在最后：产品失败存在很多因素，只有做到尽可能面面俱到，方可在软件开发领域分得一杯羹。

——摘自CSDN