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