【翻译】RFP有什么问题？

科技行业充斥着首字母缩略词和缩写，有时会引发强烈的反应。RfP这些字母总是让我在黯然神伤和极度沮丧之间摇摆不定。

为什么呢？因为征求建议书的过程突出了我们采购和交付软件和基础设施的方式是如何被打破的。

从表面上看，传统的提案申请程序是非常合理的。客户解释它的业务，详细说明它需要解决的具体问题，以及对建议的解决方案的一系列要求，并说明它将如何评定建议。供应商回来后提出他们对解决方案的建议，并列出他们的技术能力和财务信誉。

理想情况下，招标书通过清楚地界定问题和建议的解决方案，帮助客户和供应商降低风险。它还能确保公平竞争，在涉及真正的大项目时尤其重要，无论是在公共还是私人领域。(让我们假装事情不会被偶尔的豪华午餐或异国情调的会议地点所左右）。

当科技界通过云原生（Cloud Native）带来的范式转变，协商与颠覆传统做事方式相关的额外风险时，这都是一件好事，对吗？

嗯，应该是，但其实不是。向云原生的转变只是放大了传统采购的问题，以及它们如何导致项目失败。

就在十年前，麦肯锡的研究发现，价值1500万美元以上的软件项目普遍超出预算66%，超出预期进度三分之一。唯一没有超支的领域是项目交付的效益--平均比预期低17%。

但我们现在应该做得更好，不是吗？嗯，似乎没有。Gartner公司最近发现，60%的基础设施和运营领导人发现自己被公共云的成本超支所困扰，足以破坏他们的内部预算。

预算黑洞和路面沉陷

有些人可能会说，这只是表明IT和软件工程师显然根本不是工程师。我想说的是，我们不要走到那一步，然后我想指出，我最喜欢的两个项目灾难故事是来自科技界以外的，而且是以传统的土木工程为重点。

在荷兰，阿姆斯特丹地铁52号线的扩建工程晚了7年，比预算高出40%，市政府不得不出资31亿欧元，而不是计划的3.17亿欧元。这使该市的财政出现了一个巨大的漏洞，就在该市面临着天坑的困扰、摇摇欲坠的运河，以及解决如何修复1700座桥梁的时候。是的，火车不断驶来，但这个城市的其他问题也不断出现。

在德国边境，柏林的勃兰登堡机场历时30年，错过了7个开放日期，有106,000英里的错误安装和危险的电缆，并且仍然有最小的持续交通连接。令人震惊的是，机场的计划--大概是经过广泛的RfP过程后达成的-- 在最初的开放被推迟后就消失了，只是在一个垃圾箱里出现。

这听起来像是两个非常倒霉的案例，但它比这更糟糕。早在2011年，牛津大学的Bent Flyvbjerg就详细介绍了像英吉利海峡隧道这样的 "伟大的规划灾难 "是如何代表着正常的业务，90%的主要产品成本超支，而需求和效益预测通常超出20%至70%。这种情况是如何不断发生的？他说，基于简单的坏运气或错误的传统解释是不够的，真正的原因是乐观主义的偏见和战略上的错误陈述。

因此，如果传统的招标程序真的有效的话，可以说它们现在已经堕落为冗长的戏剧，以制造竞争和控制及消除风险的假象。

上述例子都是公共基础设施项目，所以没有人要倒闭。而且，大部分丑闻都集中在最初搞砸后的掩饰和否认上。但是，一旦预算被炸毁，它们就不能用于其他项目，比如修桥或招募更多的DevOps工程师。

如果你是一个商业机构，如果你搞砸了，你可能没有时间来掩盖，因为你会忙着倒闭。

而这就是问题所在。在今天的技术领域，试图消除风险是你可以采取的最危险的途径。

传统的方法最终会鼓励你专注于一个繁琐详细的目标，这导致你解决了一系列的小问题，可能是在很长一段时间内，没有任何特别的风险--因为RFP过程寻求消除它可以量化的风险。

生活是有风险的。这里是如何处理它的

这种有限的关注会使你远离解决更大的问题，在这些问题上你永远无法完全消除风险，但回报却有可能大得多。而且，它使你对完全意外的情况，如大流行病，完全没有准备。

例如，将CI/CD投入工作并不能消除风险--有时发布会失败，你将不得不回滚。但这就是问题所在。它还允许你快速开发并运行多个实验，看看什么是有效的，重复的。如果你真的想消除风险，你根本就不会改变任何东西。

而实验和适应是云原生的全部要点。它必须如此，因为世界正在快速变化，而且本身就有风险。历史上的产品周期不再适用，虽然你的组织中有些人必须关心可预测性和稳定性，但其他人必须发现新的机会，以帮助企业继续发展。所有这些都是在同一时间。是的，这意味着要像处理技术变革一样处理文化变革，正如Holly Cunnins在WTF的其他地方所建议的那样。

换句话说，当你说 "我们想采用云原生技术--你能不能填写这100页的建议文件 "时，你已经开始走错路了。

如果有人配合，甚至承诺他们可以带你到云原生并消除风险，他们最好是在浪费你的时间和金钱。在最坏的情况下，他们是在撒谎，并使你面临灭亡的风险。因为你会得到同样的老东西，再加上Kubernetes。但你不会得到帮助，去重塑你的文化和实验态度，这至少与采用任何特定的新技术一样重要。

必须有一个更好的方法来计划和购买云原生时代的产品。

那么，我的处方是什么？首先，开始尝试使用云原生。这毕竟是它的全部意义所在。但你不一定要自己做。你可以与一个合作伙伴合作--是的，比如Container Solutions--他们可以帮助你探索地形并绘制地图。你可以想出你的要求是什么--但希望这些要求比过去的招标书更开放，更多变。

下一步是开始与供应商进行一些更正式的接触，围绕较小的项目。我指的不是单一的供应商。在一系列不同的、较小的项目中与一些供应商合作。你会更多地了解每个潜在的合作伙伴，也会更多地了解你真正要找的是什么。当它成功时，你可以开始建立一个长期的关系。

然后，你就可以开始着手开发一个MVP，并真正开始做一些云原生工作。但这并不意味着艰苦的工作很快就会结束。正如我之前所说的，我们的目标是为持续改进而制作的东西。它将使未来的变化和增长成为可能，而不是让你面临被五年前的RFP文件中的系统所阻挠的风险。

这种方法会消除风险吗？不，因为你永远不可能消除风险。但你可以认识到这个世界是有风险和混乱的，然后寻找方法利用它来实现你的目标。而云原生可以成为你用来做这件事的工具之一。当你掌握了这种世界观，你就能更好地应对未来的任何情况。

如果有人说他们可以帮助你开发一个RfP，我建议你安排与他们见面，也许在柏林机场。