每个软件项目都是在号角和乐观中开始的。即使是在深夜中拼凑起来的最微不足道的小项目，也都是源于一个星光璀璨的梦想。团队相信，只要几行代码和一些开源库，我们就可以完成任务，并可以为我们优雅、完美的工作而接受奖励。
但是在几周或几个月后，我们就会从梦中醒来，并发现git存储库中充满了各种决策、修订和恢复。它足够好了吗?满足标准了吗?会有人真正使用它吗?很多时候，软件团队深入到一个项目中，却发现这些问题的答案中至少有部分是否定的。有没有办法预见到它的到来呢?
的确，有时候，即使是最好的编程计划在没有任何警告的情况下也会误入歧途，但大多数情况下，一个注定要失败的结局对于任何一个一路上密切关注它的人来说都是显而易见的。
下面是软件工程师列出的十几个软件项目可能失败的早期警告信号。
在管理层支持下的转变
这个项目的业务冠军是在某天早上试图把他或她的孩子送进南加州大学或耶鲁大学后被捕的吗?CIO是否取消了最近的三次进度评审会议?算一下，你是否已经大概有一年没见到CIO了?财务总监问过你的员工预算吗?合并能扫除一半的组织结构图么?
许多软件项目失败的原因可能与编写代码的人没有任何关系。如果管理层中有人喜欢您的软件项目，就会通过审批流程以支持它，如果这个人消失了，支持也就会消失。你的愿景其实是无关紧要的。如果另一个团队对公司的发展方向有不同的看法，并且这个派别控制了公司，你的项目就可能会消失。所以，尽管你可能不想这么做，但还是要关注政治。
市场的变化
重要的不仅仅是内部支持。消费者和他们所驱动的市场也能改变他们的欲望。软件项目需要几个月的时间才能完成，而市场却可能在几周、几天甚至几分钟内就消失了。
如果你的项目针对的是一个快速发展的市场，那么当你完成代码时，市场变得完全不同的可能性就会更高。即使你的项目是在一个更稳定的领域，新的竞争也几乎可以在一夜之间出现。如果你的团队没有一个计划来适应不断变化的趋势，就很有可能会被淘汰。
程序员的跳槽
人们总是在换工作，优秀的程序员需求量总是很大，但是如果团队不断地流失人员，那么就会出现问题。如果工资已经足够高，工作条件已经足够好，那么项目本身就可能是罪魁祸首。也许编码人员被需求弄糊涂了，他们跳起来是为了避免心理压力。也许整个架构都是错的，他们已经无法让它正常工作。也许团队中有一些害群之马正在赶走所有人。团队外流是一个预兆，表明有些事情是错误的，可能会破坏项目成功的机会。
在简单的事情上花了太多时间
团队对简单的变更响应速度有多快?他们能改变背景颜色吗?将复选框移动几个像素?如果微小的更改需求没有得到快速处理，那么大的更改将会需要更长时间。
有时候糟糕的架构决策会让一些简单的事情变得几乎不可能。我的一个工作项目要求我在数据库中填写一个额外的列，这需要更改五个不同的微服务。这意味着要检查五个不同的项目，通过五个不同的代码审查，并编写五组不同的单元测试。它们都只是为了更新一行中的一个数字。
开发人员有一种过度复杂化简单任务的习惯，有时最聪明的开发人员反而是最糟糕的。有些更改将是困难的，但是如果团队在处理大多数小更改时也遇到困难，那么这就表明基础过于复杂了。
没有成本模型
估计每个用户的成本比以往任何时候都要容易。云计算按小时计算，无服务器系统按事务定价。如果用户每个月使用M字节的数据访问服务器N次，你知道对这些数据进行所有计算需要多少成本吗?
一些项目团队对成本一无所知，然后他们可能会发现，一笔花费X便士的交易只能带来Y便士的收入，遗憾的是，X > Y。该软件可以编译和运行，也没有太多bug，但是项目失败了，因为它是一台赔钱的机器。跟踪成本和确定一个明确的目标是至关重要的，否则开发人员可能最终构建出一个非常酷的东西，但需要周围有6台最复杂的云机器。
开发人员一味地遵从一个天才
有聪明人在你的项目上工作是件好事。但是当一个人的思想占据主导地位时，危险就来了。除了一些奇怪的情况外，如果每个人都说“我们去问X吧”，而X总是同一个名字，这通常就是一个不好的信号。如果X死了或者跑到山里去寻找启示，这个项目就会失去方向。
但是，如果X不离开，情况可能会更糟，因为每个人都希望由X来执行决策，而出现的瓶颈会阻止所有人继续前进。X可能享受权力，X也可能是一个合格的天才，但强迫所有的工作都得到X的批准将是缓慢的。
代码标准主导着讨论
美学很重要，但一些开发人员过分关注代码中的空白空间，并将这一点发挥到了极致。所谓的代码标准只是妨碍团队成员行使权力的一种方式。在代码评审期间，当他们发现一个放错位置的空格或制表符时，他们就不祥地宣布“没有达到标准”。
功能最终决定着一个项目的成败，如果团队不停止争论外部人员永远不会看到的内部代码的美学，那么团队可能永远也无法达到目标。
指标看起来太过完美
通过指标来衡量团队进度是一个必要的要求，但是对它们过于信任也是很危险的，因为开发人员会玩弄您所能想象的任何度量。一位朋友解释说，他的老板有一个指标，可以衡量有注释的功能的比例，所以他使用了著名的AI聊天机器人Eliza，以确保他的所有功能都有注释，无论是多么愚蠢的注释。他甚至编写了一些快速代码来搜索变量名称，并将它们包括在毫无意义的注释当中。他的统计数据非常棒。要求所有功能都有注释的老板从来没有读过这些注释，所以老板也一直不知道内情。他刚刚在仪表板上看到了100%的注释代码，然后就去了高尔夫球场。
目光朝着闪亮的新事物移去
新的语言、库和体系结构都很棒，但它们也有自己的定位，而且通常不在关键任务的堆栈中。它们适用于示范和探索性的次要项目。对于项目外围的非必要微服务来说，它们是可以的。如果团队有一个舒适的时间表，并且也没有其他选择，那么这些选择可能是可以接受的。
然而，隐藏在对某些新软件解决方案的渴望中的真正含义是，开发人员可能正在与当前的项目或体系结构作斗争。当前的计划可能已经产生了太多的小故障、错误和令人头疼的事。他们可能正试图迫使一些方形图库与圆形API进行通信。胶水代码可能比实际代码还要来的多。对当前方法的不满可能导致开发人员在不断地徘徊。
业务规范的不明确
这个过程的前景是否模糊得令人难以置信?它是否充斥着像“disrupt”或“meta”这样的流行词，而不是像“HTTP”或“AJAX”这样的技术术语?是否存在大量关于“改变世界”的讨论，却很少讨论数据库的选择或架构策略?
创建软件需要具体的技术决策，而有时候那些项目的幻想家并没有花足够的时间来考虑如何实现这个目标。有时候，他们很幸运，因为有一些聪明的人能够构建它，但是通常情况下，不清晰的业务规范通常会导致项目的失败。也许它需要太多的带宽。也许延迟会让用户界面变得迟钝。也许所有这些云计算的成本还不足以被广告和订阅费所覆盖。我们不知道会发生什么，因为规划文件里没有涉及到那个细节。
不受控制的复杂性
管理软件项目的主要任务是找到一种方法来让用户满意，同时将任务的复杂性降低到可管理的程度。每个人都希望代码能够轻松地阅读他们的想法并提供答案，但是这些东西只有在用户都想要相同的东西时才有可能。
当多个派系开始要求不同的东西时，项目就开始出错了。如果他们对项目拥有太多的权力，而项目经理不能找到一种方法来协调他们的兴趣并让每个人都满意时，那么项目将变得非常复杂，完成它所需的代码量将会大幅增加。如果项目团队不能有效地说“不”，那么工作的复杂性将比程序员编写代码的速度增长得快得多。
糟糕的测试计划
有些程序员喜欢大量编写新代码。每一行都是一个真实的创作，一个关于比特的艺术陈述，将被转换成其他的一些比特集合。从前黑暗的地方，现在有了光明。这是一种美妙的感觉，但这只是其中的一部分。仅仅构建软件是不够的，我们需要了解它何时可以正确运行，这样我们才能够了解它何时会失败。
一个好的测试计划应该向后看，而不是向前看，检查是否一切正常。这并不是能够凭空变出来的能够让人觉得兴奋和刺激的东西。它只是充满了唠叨和提醒，敦促你回去把事情做好。测试通常并不是愉快的。
但是测试和构建代码一样是一门艺术。有太多需要进行测试的东西了，你永远不可能结束它。但如果太少，代码就可能无法正常工作。如果一个软件项目团队不能平衡创造的喜悦和测试的繁重工作，他们将走向失败。
不合理的期望
有些事情对软件的使用者来说太容易了，以至于运行项目的人常常没有意识到让这种神奇的功能发挥作用有多难。许多项目都可以编译并运行，几乎没有错误，但是如果它们不能满足用户的需求，就会被视为失败。有时候问题不在于代码，而在于使用它的人无法实现的梦想。什么?新的数据库也不能治疗我的秃顶吗?我还以为它能像《星际迷航》那样传送并瞬间移动呢!
软件开发人员需要保持对项目的控制，以确保大胆的梦想家或大思想家无法指挥项目。如果期望得到合理的控制，项目就有机会实现它们。如果不是，那么，即使是最出色、无缺陷、低延迟、最先进的应用程序也可能会让人失望。
京公网安备 11010502049343号