战略决策有助于加速软件项目利用商业机会，但是IT领导必须注意其中的陷阱和权衡取舍。
当然，IT领导和客户都希望每个软件项目都能更快地被交付。但是快速的开发也可能会导致错误的代码、低劣的测试、不完整的解决方案，或者更糟的，不安全的软件。虽然没有人想要一个失败的软件项目，但有时在某些环境下--包括市场条件、业务需求、机会之窗--可以证明一些有利于速度的权衡措施是合理的。
软件开发不仅仅是一种逻辑上的努力。它也是一门艺术，也是许多组织商业战略中不可或缺的一部分。如果能够高效、公平、简单和安全地完成，在那些重叠的某个地方就存在着获得更高效的开发流程的可能性。你只需要知道折衷方案，并做出有利于精简项目而不是开发完美软件梦想的决定。
当IT领导想要加速一个需要快速进行的特定软件项目时，这里有11个战略决策可供参考。
控制利益相关者的梦想
每个人都希望得到反馈，来自营销团队、运输部门和会计部门的利益相关者都是带着远大的梦想来到会议室的。诀窍在于首先找到最容易实现的梦想。在一次奇迹般的会议中，我的软件团队发现，只需在一个表单字段中添加预填充的默认值，就可以为数据解析器节省数百万小时的工作。成百上千的销售代理每天都会从无到有地填写这张表格。在HTML中多了几个字符，我们就像天才一样被对待。
让利益相关者脚踏实地将有助于控制项目的范围。如果你能让利益相关者关注那些更小、更有价值的特性和改进，那么复选框的填充速度就会快得多了。
阻止开发者异想天开
不仅仅是西装会让人忘乎所以。开发人员也需要脚踏实地。对于项目列表上的每一个项目，开发人员都将其视为最终尝试一些聪明的、新的、非常耗时的流行术语的一个机会。屏幕上有两列不对齐吗?现在是时候用纯函数重写整个堆栈来实现多梯度功率下降优化量子学习算法了。
虽然开发人员的热情对于实现一个加速的时间表是至关重要的，但是确保开发人员的热情能够被引导到一个精简的目标上也是至关重要的。
削减特性
削减需求似乎是个懒人的游戏。毕竟，如果你将“一切”都重新定义为一个更小的集合，自然就能够很容易更快完成所有事情了。
但有时，让团队集中精力也是必要和有用的。巧妙的方法是确保基础仍然足够牢固，以便将来能够重新处理被跳过的特性。例如，确保数据库模式预期了某些增强功能，而这些功能是有人希望在以后的迭代中能够添加的。如果这仅仅意味着现在需要稍微调整一下模式，那么当你返回到此过程中被推迟的特性时，也可以节省时间。
简化测试
部署代码的挑战之一是在运行之前进行测试。最近的趋势是把所有的东西都拆分成可以独立运作的小项目。如果每个项目都必须单独测试，那也就意味着需要进行更多的测试。一些包含大量微项目的新的微服务体系结构必须经过多次测试。
显然你无法摆脱对测试的需求，但其中的一个诀窍是可以测试同时在一起工作的多个项目。有时，将几个部分捆绑在一起可以消除独立测试它们的需要。
简化架构
如果你打算去掉一些特性，把一些工作留到以后做，有时你可以重新考虑架构的设计。有时则不是。
如果这些功能可能会在下个季度甚至明年出现，那么你最好把基础保留好。但如果它们不是必需的，那么清除掉架构中的大块内容将会是一种极大的解放。
回拨性能的保证
当时间充裕时，每个人都希望在毫秒内就得到答案，同时还能够确保数据被复制到三个地理上独立的数据中心上，以防飓风和地震的同时袭击。谁不想要完美呢?
但通常，高性能也意味着需要大量额外的缓存层、负载平衡层和复制层，而这些额外的层需要花费时间来进行构建、配置、调试和维护。减少开发时间的最简单方法之一是说服利益相关者，如果屏幕刷新时间长了一点，希望他们可以稍微放松，或者打消这个想法--他们中的一些人会因为故障而自动消失。并不是每个项目都像脑部手术那样需要那么多的精确度和可靠性。
利用现有的代码
花费更多时间的最简单的方法就是探索一种新的技术。是的，从长远来看，对下一代进行投资是很重要的，但现在不是有人敲桌子要求更快完成的时候。使用与你在过去几十个项目中使用的相同的语言和数据库会更快更简单。你将移动得更快，而且有时还可以重用代码块。不仅如此，你还将保持一致性，使开发人员更容易在项目之间移动。
接受技术债务
当开发人员想要完成某些事情时，他们喜欢谈论“技术债务”。通过现在承诺一个有限的或快速的解决方案，开发人员可以把修复或填补空白的工作留给未来。这是一个需要认真考虑的真实概念，但有时人们的确会想要在操纵流程时调用它。
一些技术债务是可以接受的。使用最新的数据库或最新的语言技术并不总是必要的。有时候，我们可以跳过三代或四代的神奇技术，直接进入最新的版本。跳跃式的前进可以避免很多头痛和熬夜。
这是一种艺术的游戏，它不是没有危险的。但很多时候，技术债务的幽灵远比跳过几代更新的现实更加糟糕。
开源
太多的项目中有太多的自定义代码了。如果你想完成某件事情，而很有可能其他人也有同样的烦恼。有时其他人或组织已经启动了一个开源项目，现在也正是你加入的机会。
开源不是万能的。天下也没有免费的午餐。你经常需要做出妥协，并与其他团队一起工作，以汇集一些适合个人的代码。当这个流程运行良好时，你只需为开源项目贡献一小部分时间，那么每个人就都会成功。
使用基本的工具
许多项目都可以使用现成的工具来完成。使用标准web表单(比如Drupal、Google Forms或是Survey Monkey)可以构建的内容是令人惊叹的，这些表单也可以将数据转储到执行分析的电子表格中。这不是耍滑头。它甚至可能不会被程序员防御联盟称为是“编码”工作。但是，如果它可以以一种可靠和可重用的方式交付答案，那么它就是完成大型开发项目最快的方式。
实事求是
我们都梦想建立一个病毒式的传播网站，所以我们总是计划处理最极端的负载。我看到过一些细心的架构师描述他们的三层系统，其中到处都有负载平衡器和复制的数据库，所有这些都可以支持一个每天可以照顾100人的项目。如果适当进行扩展是容易的，那就不会是问题，但是增加这些层会增加项目的复杂性，延长构建时间，并使维护变得更加复杂。引入新的程序员也会变得困难得多，而解决哪怕是最小的问题也需要长时间的团队会议。确实，一些较新的无服务器工具(如谷歌App Engine)简化了伸缩性，但在复杂性和成本方面也需要进行权衡。
优秀的工程师能够预见未来可能出现的奇怪问题。但是，良好的成本工程需要对可能性有实事求是的态度，也许，当这些异常值出现时，是可以决定接受糟糕的性能甚至是失败的。
