所有的软件项目都始于梦想和宏伟的愿景。在平行宇宙的某个地方，有一个能够实现所有梦想项目，但是在我们的宇宙中，软件项目往往踉踉跄跄地走到终点线，有时甚至会跨过它。
分析师也许喜欢随机推算出一些评估软件项目失败的百分比，但这些数字必然是十分不准确的，因为失败并不是非此即彼的事物。你最终可能会得到运行顺利但无人使用的代码。或者你甚至会得到不能编译的代码。有时你可以从熊熊燃烧的残骸中找到有用的东西，有时最好在爆炸发生前逃跑。
当余火燃尽的现场冷却时，尸体解剖随之开始，人们开始寻找事发原因。以下列出了软件项目失败的最常见原因。
团队成员太少
用很少的程序员做很多的事情，这种效应不难理解。一年只有52周，人们在累垮之前能捣鼓出来的代码就只有那么一点。我曾经在一个团队中工作过，该团队中的管理者认为从敏捷团队中挤出更多成果的正确方法是安排好每一场“冲刺”，以便在前一个冲刺之后立即接力。不留喘息的余地。也无从弄清楚什么在起作用，什么失败了。Sprint 42周三下午1点59分结束，Sprint 43周三下午2点结束。他们甚至计划在下一次冲刺开始后进行回顾性分析会议。有些聪明人建议将其改名为“马拉松”，并很快跳槽了。
当然，到底需要多少程序员，这很难估算。有时计划完成了，估算也是准确的。有时候障碍和问题会挡道。工作量翻倍可不一定是管理者的错，但是如果你人手不足，你的项目很可能会失败。
团队成员太多
如果程序员太少是一件坏事，那么程序员太多情况则更糟糕。同一个使一些社交媒体平台显得不可或缺的网络效应也可能导致软件项目失败。人越多，协调工作就越复杂，开会也更频繁，写代码的时间也遭到了剥夺。你可以试着取消会议，让程序员有更多的创建时间，但是如果你没有开足够的会议，你很快就会发现甲队的API无法对接乙队的微服务。
如果程序员过多，他们可能会相互消耗精力，使项目掉进五指山。如果我们破财消灾，在项目上搞人海战术，这也不错，但是你不能这么做。
基本功能变更
理论上，开发人员往往自命敏捷。这就是他们接受这个词的原因。但有时敏捷会让所有人乱了方寸。这一切都取决于这种转变是否需要对基础框架进行根本的变更。在移动按钮或更改颜色时很容易做到敏捷。但是涉及到重新构建数据库模式或者使用切片和复制时，想优雅地转变，谈何容易。
选错了技术
即使你认真规划并为项目拟定了正确的功能列表，如果你在构建功能集时用错了技术，这也可能会导致失败。例如，数据库的目的就是尽可能通用和灵活，但是它们受限于架构。如果你试图促使它们实施超出设计范围的事情，那么当它们扩展时，你可能会眼睁睁地看着它们慢得几乎停下来。或者你可以从NoSQL数据库开始，因为它们听起来很酷，可是后来却发现你确实需要ACID级别的事务(transaction)来保持事物的一致性，而数据库不提供这样的事务。天哪!
没设置好优先级
优秀的规划人员会绘制一个功能列表并分清轻重缓急。但有时候，现实并不符合实施这些优先事项的条件。在最坏的情况下，最重要的功能也是最难创建的。
你的开发人员要做什么呢?如果他们专注于最重要的功能，他们将无法取得进展，最终可能什么功能都实现不了。但是，如果他们解决了简单的功能，那么他们最终可能只实现了毫无价值的功能。
良好的规划需要的不仅仅是清单。架构层面的愿景必须考虑到交付这些架构的需求和成本。
市场窗口关闭
有时候这不是程序员的错。我其中一个项目是将最畅销的参考书做成应用。该书在互联网出现之前就已经很畅销。这个计划就是要挖掘这一需求并制作一个交互式版本，使人们可以对数据进行分类和搜索。编程团队交付了包含书中所有内容的软件，但它比纸质版更快，更漂亮且更轻。但没有人想要它。我们几乎送都送不出去。但这不是开发商的错。市场恰恰不再需要这些数据。资料来源越来越丰富，没有人需要一个与新闻网站做同样事情的多余的应用。
软件项目无法补救编程团队或管理团队的错误。有时候，一个想法看似不错，但市场是不会刻舟求剑的。
糟糕的架构决策
在一个项目中，我授命在数据库中更改一个数字。在用户完成注册时，我要将用户的ID号添加到最新的订单中。这看起来很简单，对吧?但是这个系统是建立在一个微服务架构上的，光写一行命令数据库更新该列的代码是不能解决这个问题的。想都别想。架构规划是为现有栈添加一个新的微服务调用命令，就这也已经很难了，因为我的第一个微服务调用命令需要触发另一个微服务调用命令，以此类推。
最后，创建这个微服务网络的架构专家告诉我，这一切都非常简单，然后他通过微服务架构的五个不同层次概述了一条蛇形路径。所以我的工作是向五个不同的微服务应用程序添加五个新的API调用命令。这些命令都是完全独立的，这意味着每一层都要添加五组自动化测试。各个微服务API历来都由不同的团队开发，这些微服务要求我理解和模拟五种不同风格的编码。一切只为更改一个数字。
诸如此类的简单要求使团队不断变慢。在我离开时，五个新的API调用命令已经写好了，它们正好一致通过测试。但我从未看到它们得到部署。
架构决策可以持续整个生命周期——如果你全身心投入，而你无法改变他们，情况尤其如此。在主要的架构计划不起作用时，项目管理者必须时刻留意到，以便做出重大决策。当规划出了乱子而管理层又没有注意到，工作在一线的编码人员要不断努力，在不良架构模型造成的不良后果中迎难而上。
勾心斗角
将技术上的失败归咎于权术之争，这看似一种逃避，而不是坦然地承认这是自己的错误，但这种现象越来越现实。随着项目日渐变大，跨越多个组织和层级，派系出现，小组争夺控制权、资源和权力，这应该不会让人感到意外。
派系和真正的技术差异是两码事。人们往往有技术标准或代码库，它们以不同的方式完成同样的事情。以XML和JSON为例。既然我已经输入了这样的内容，我可以感觉到粉丝们急于解释为什么它们不一样，他们喜欢哪个，哪个就是正确的选择。他们也许是对的，但是当一个团队中的一部分人选择了技术而另外一部分人却十分看重敌对派系，那么冲突就会使他们分裂。
当架构师将应用程序分成多个更小的服务和API时，这种情况变得更加普遍。不同小组会得到对它们的控制权，但他们并不总能和睦相处。如果甲组喜欢用JSON，乙组坚持用XML，那么你的团队要么两者都实现，要么对其中一个进行变更。对于所有必须与甲组和乙组一起工作的团队而言，这三种情况(两种技术加派系之争)都是令人烦恼的。
押宝尚未准备好投入生产的技术
程序员都喜欢用最新的工具和框架。他们宁愿相信，新方法将扫除所有停滞于上一代的残余物。他们确信，新的抽象和例程将统一，扩展和简化代码应该做的所有事情。
但下一代工具和框架往往还没有准备好用于生产。新功能也许闪闪发亮，看似完美，但是差距往往很难在顷刻间体会到。有时代码仅支持少数几种文件类型，或者仅能与少数几个数据库进行交互。他们向你保证，其它的代码即将推出，但你的项目需要在本月交付，“即将”可能意味着要六个月或更长时间才能完成你需要的功能。
诸如此类的问题可能注定会使软件项目失败。团队押宝一项新技术是因为它似乎解决了许多重大问题，而且确实经常能解决问题。但是在某个阶段，通常在冲刺阶段，程序员发现新技术缺失了某些部分。而这些缺失有时甚至没有记录。该代码的开发人员却要着手处理，结果可想而知。
押宝即将过时的技术
人们会忍不住像金凤花姑娘(Goldilocks)一样思考，对太旧的技术的指责丝毫不亚于对太新的技术的指责。根据我的经验，旧的东西往往更可靠，更经得住考验，这比完整的功能集更有价值。但这并不意味着旧技术是完美的。一旦软件上线，对你的软件项目来说很重要的功能可能会缺失。但更糟糕的是，押宝旧技术可能会使你错失先机，因为它们会根据线路的变化而发生变化。新的想法、协议和文件格式会诞生，而它们也许未能得到实施。如果竞争团队的人一定要你支持某种新协议，那么旧技术将会受损。
不切实际的期限
专家说，找出需要多长时间然后加倍。就好像已然成为笑柄的专家能在有生之年中真正完成一个项目似的。他们总提意见却不写代码。
截止日期是个很棘手的问题。很多项目要在特定季节或活动中推向市场。然而，最初写下截止日期时，开发人员还没有发现过程中可能出现的障碍。然后，如果项目延期并且活动在没有启动软件的情况下遭到了忽略，那么即使代码能流畅运行，整个项目也无异于失败。截止日期可以帮助所有人集中注意力，使他们齐心协力，但他们也会产生不切实际的期望。
不可预见的竞争
优秀的产品经理在参与竞争前会对其进行调查，但没有人能预测什么样的竞争会突然出现。如果新的竞争对手引入了你必须复制的新功能，那么请参阅上述关于功能变更和优先级不匹配的部分。
急于求成
很多软件项目都是以想要解决问题的人或团队的愿景开始的。他们想出了“乙的色布拉”或“乙的优步”这样的短语，然后期望产品团队能够像色布拉(Snapchat)或优步(Uber)一样迅速响应。问题是，确定项目范围，勾画数据流和设想用户界面(UI)的工作量往往是写代码的十倍之多。但是构想者却想立即将想法变成代码。(为什么呢?你可能要责怪那些演示新框架，数据库或无服务器等玩意儿，同时承诺你用几行代码就能写成应用程序的开发人员。)
线框、数据库模式和用户故事可不是虚张声势的东西，而是工作的重要组成部分。但大多数人想当然地认为，软件项目只是编写代码来实施一个想法。
误信软件的力量
有时候，梦想家对软件改变世界的力量有着不切实际的信念。很多人认为社交媒体会把我们所有人联合起来，但这总是莫名其妙地暴露出明显的断裂带。很多软件项目都是一系列以蓝天白云为背景的幻灯片开始的，这些幻灯片有望破坏某些东西并革新世界的某个角落。当在数据库中插入一些位并不能拯救或改变任何人时，那么，有人会生气，无聊，困惑或者变得更糟。然后他们会说软件坏了，并接着做别的事情。至于数据库是否运行顺畅，应用程序是否将这些位存储在正确的位置，这些都不重要了。这样的软件无法实现人人都期望的魔法般的转变。
很多软件项目都可以编译，通过质量保证，出货甚至获得好评，但最终却无法实现蓝天白云般的幻灯片中所承诺的一切，因为这些改变世界的承诺是不可能兑现的。
京公网安备 11010502049343号