从字面上看，两年多来，我一直致力于“大爆炸”重写。管理层一直无情地忽视和贬低我的呼吁，即在该应用程序取代其百万美元的赚钱旗舰网络应用程序之前分配时间/资源用于性能测量、容量规划和优化。
最后，他们同意这样做（我们通过推出一个并行的 beta 服务器成功地阻止了他们大肆宣传，该服务器现在正在生产中并将成为测试的目标）。我不喜欢他们等到最后才优先考虑这一点，但迟到总比没有好。
对于以后处理此类情况，大家有什么建议呢？教育经理/客户需要进行此类测试的最佳方式是什么？
我已经向他们展示了 Microsoft 在 CodePlex 上的性能指南，并在开篇页面中附有经验丰富的专业人士的严厉警告。我还给他们看了《放开它！》这本书。以及其作者给出的关于“凌晨 3 点通话”的指导。这最终让他们不情愿地说服了他们，但事实是，这应该优先考虑到开发中，并在最终完整系统测试之前的开发过程中进行部分测量。
许多只编写过 ASP 但从未编写过 .NET 的经理和老派工程师习惯于自己编写所有代码，并且不了解在较新的 .NET 应用程序中缓存、调整和运行状况监控的所有选项。
谢谢
您没有意识到（许多工程师没有意识到）这是一种“销售情况”，而不是工程情况。不管客户是否在公司内部，流程基本相同。
销售就是要找出什么样的问题驱使您的客户，然后展示您的产品如何解决他们的一个或多个问题。如果他们不认为自己有性能问题，那么他们就不会——就这么简单。尽管您可能能够教育他们，让他们以您的方式看待事物，但“教育销售”在时间和金钱上是昂贵的，而且许多客户讨厌被告知“他们已经知道的事情”。听起来你必须通过用书打败他们来教育这个群体，但可能有更简单的方法来实现你的目标。
那会是什么？我不知道，但他们知道，所以问他们。询问是什么最终促使他们做出决定。可能是突然意识到你是对的，但更可能是更基本的事情，比如越来越害怕在董事会或市场上受到羞辱。他们不太可能直接这么说，但如果你真的听他们的回答，你也许能从字里行间读出。在销售中，对销售电话进行事后分析（成功与否）对于了解是什么激励了您的客户以及如何调整自己的表达想法的技能至关重要。
而且，下一次，你会知道问一些开放式的问题，比如你的客户想要实现什么，以及他/她现在和长期的问题是什么。它会一直有效吗？当然不是，但学习处理工程问题的社会方面是一项宝贵的技能。
让他们就他们期望系统能够支持的可靠数字达成一致（并发用户/任务/等的数量），那么确保系统能够满足要求就成为开发工作的一个明显部分。
不要将此作为一个开放式的性能调整和基准测试过程来讨论，因为这会使年长的经理担心你是在钓鱼或给系统镀金。
相反，将其作为认证练习进行讨论。确定您当前的流量水平，添加安全边际，并说明您的测试旨在证明系统将经得起现实生活。
你仍然可以做性能热点工作；你只需要让尖头发的老板放心，你的所有工作都将实现有形的业务目标。
说服人的方法有很多种——你提到的例子是“调用更高的权威”。然而，大多数管理人员不一定会被技术指导所说服。
对于这种情况，我使用了基于风险的方法。对于每个项目，我都会保留一份风险日志，确定项目的最大风险、它们的可能性、影响和缓解方案。通常，您可以量化这些项目——这让经理们可以做出正确的决定。
在重写开始时，您的风险日志可能有以下条目：
风险：系统性能未能满足用户期望
可能性：未知
影响：最终用户因加载时间过长而放弃网站。项目失败。
影响成本：无论您的项目成本如何。
缓解：每两周一次的性能测试。
缓解成本：无论您认为会花费多少时间和金钱
建议：运行性能测试以量化风险。
大多数经理对风险未知，但其代价是项目失败的风险会感到非常不舒服。另一方面，您并没有要求做出巨大的承诺 - 足以量化风险。
我喜欢定期与项目利益相关者一起查看风险日志——至少每月一次。我总是从“高影响/高可能性”风险开始，然后转向“高影响/未知可能性”风险。分发会议记录也是一个好主意，记录利益相关者对每个风险的决定。同样，在书面记录中看到自己的名字与忽略高影响风险的决定相关联的经理会仔细考虑该决定。
一旦你可以量化风险——通过运行一些性能测试——你就可以根据成本和性能问题的可能性做出进一步的基于风险的决策。这也是管理其他经典非功能性问题（如安全性、可访问性和可扩展性）的好方法。
通过量化问题，您可以将其转化为业务决策，而不是工程决策。
仔细记录这个开发项目，包括部署后出现的性能问题。人们会哀叹这些问题，你可以委婉地建议他们更早地优先考虑这类问题。有些人只接受直接的第一人称证据。