是的，我知道标题是满口的......
我的意思是说你是如何与需要编码和测试理论的主题专家沟通的？
例如，天气模拟是气象学家，计算机科学家和软件工程师之间的合作。计算机科学家和软件工程师通常讲同一种语言，但他的气象学家处在一个完全不同的世界。
如何提高学科之间的沟通和理解水平？其他科学也不一定仅适用于天气。
答案 0 :(得分：2)
最短的答案是持续的客户参与。
所有漂亮的UML图表，crayola UI模型，对四岁儿童的解释和其他技术永远不会提供使用工作应用程序的完整体验。将消费者保持在循环中允许对客户端以及从客户端到您的反馈循环。这种共生关系最有可能产生对他们有用的产品。
如果你进入一个盒子并拿出你认为他们需要的产品，它可能会是他们不想要的很多东西。通过定期演示您的产品，您可以限制任何误解的影响，这样您就不会花费太多时间走错路。
它可以与航位推算进行比较。如果你蒙上眼睛并尝试浏览你所知道的区域，你所处的位置和你认为的位置之间的误差将随着时间的推移而累积。但是，如果您定期摘下眼罩，可以更新您的心理位置。仍然会有一个错误因素，但您正在消除累积的错误因素。
即使您认为您的沟通/解释技巧是最佳的，您仍然需要考虑他们沟通方式的错误。
答案 1 :(得分：2)
状态图为该任务创造奇迹。它们允许您在适合与您通信的人员的级别上表示计算过程。各州对那里的处理进行了简要评论。状态之间的弧显示导致转换到新状态的条件。
构建基本状态图后，您可以继续讨论正在输入状态机的信息。这是人员领域知识应该发挥作用的地方。通过图表跟踪一些数据，以查看如何处理它的流程。通常在这一点上，他们开始注意到尚未讨论的其他情况。
可能需要拖入另一块白板，将一个或多个状态展开到自己的状态图中。
然后通常情况下，当他们对流程感到满意时，是时候将错误处理注入到图表中了。
这项技术对我来说效果很好。
答案 2 :(得分：1)
“最短的答案是持续的客户参与。”
我建议你通过一些特定的方法来做到这一点。
一种可以快速发展的语言。 Python是我的选择，你的可能会有所不同。例如，Java可能在你的列表中不高，因为它需要一段时间来运行。 C ++可能会为快速开发付出太多努力。
快速构建小东西。从一些东西开始 - 任何东西 - 可以开始对话。建立，审查，扩展。
使用允许您提前和经常重构的单元测试来对结果进行正式化。
一旦你有了坚实的东西，你可以考虑用Java或C ++或其他东西重写以提高性能。
答案 3 :(得分：1)
我总是发现流程图是普遍可以理解的，尤其是在表示算法时。流程图通常易于阅读和制作，并且普遍被理解。
答案 4 :(得分：1)
我认为大多数评论者遗漏的内容实际上对您的问题非常重要 - 您正在与领域专家合作构建其模型的实现以测试他们的理论。
大多数软件工程的东西都没有关于这种制度 - 而且就像你说的那样，这与实施某些商业流程或构建必须实施RFCxxxx的服务器在质量上是不同的。
有人正在从两端开展这项工作 - 试图向科学家讲授负责任的软件工程的基础知识（例如，Greg Wilson的Software Carpentry），并教授软件工程人员关于大规模计算科学的知识（例如，史蒂夫·伊斯特布鲁克的very interesting blog，其中this特别相关。为什么事情和他们在这方面一样原始，我不知道。两者都在他们的博客上与相关同事有联系。
这种制度中存在许多重要的差异，这些差异来自于你可能已经教过的东西。首先，科学软件的整体结构通常很简单，但细微之处很高 - 每一行数字都可能是许多领域10年科学文献的结果。其次，整个规范类型的想法得到了改变 - 规范是“准确地模拟现实”，而科学家所拥有的是他们希望这样做的模型。在某种程度上，科学代码开发既是实施规范草案，又是为了实际规范而摸索。
@vfilby有一个正确的想法 - 持续的客户参与 - 但它不止于此。为了实现这一目标，你将进入科学循环 - 而不是循环为科学家→理论→测试→解释→更新理论，它将成为科学家→理论→你编码→你和科学家两者解释您自己的部分→更新理论和/或实施。领域科学家不会像你一样了解如何最好地实现他们想要的东西，或者如何将模型的结果与模型实施的结果区分开来;另一方面，他们会比你更了解模型的含义，以及如何更新理论。
这是一个很难平衡的行为。为了使其发挥作用，双方必须（a）尊重其他领域的专业知识，（b）学习其他领域的一点，以及（c）投资于整个项目的工作。这些跨学科项目经常崩溃然后成功，但它们至关重要。我真的希望我能为您提供一些简单，有保证的工作提示。
答案 5 :(得分：0)
非常谨慎和耐心。你不能假设理解，所以使用原型或图片等技术进行交流。
当客户发表声明时，您需要实施您认为他所说的内容，或者绘制一张图片并向他展示。他更容易以这种方式认识到你的误解。我会避免冗长的书面描述，因为很难知道你是否理解。
客户不需要知道您的语言，所以不要试图向气象学家讲授CS术语。你需要学习他的语言。即使最琐碎的要求也应该用原型进行测试。如果他们说：“我们需要看一张美国地图”，那么你需要绘制一张美国地图并向他们展示并说出“这就是你想要看到的”吗？然后他会说“但我在这张地图上看不到密西西皮河”，然后你说“但你没有要求河流”然后回去重新绘制地图。等等。
我遇到过更简单要求的情况，因为客户认为这很简单，我认为这是理解错误。
答案 6 :(得分：0)
我在Weiger的事情上取得了很大的成功： http://www.processimpact.com/reqs_book/reqs_book.shtml
首先制作愿景和范围文档： http://www.processimpact.com/pubs.shtml#requirements
答案 7 :(得分：0)
你应该总是问自己，“我如何向市场上的那个'老奶奶解释这个？”。一旦掌握了这些内容，您就可以与任何人讨论和解释您的方法和程序。如果他们有一些额外的知识，甚至更好。
如果你不能，也许你应该问自己“也许问题不在他们身边。”即使它站在他们一边，试图理解他们的观点也没有坏处。
就个人而言，我不是一个交易程序员，但只要我们都坚持上述原则，就不会有任何问题。
答案 8 :(得分：0)
充当程序员，并使用“最松散的耦合”方法。
对于气象学家来说，我对这个领域知之甚少，气象学家和程序员几乎没有就实际代码进行沟通。那些程序员已经掌握了足够的数学知识来实现气象学家想要的任何方程式，然后气象学家就足以使用该软件了。
我还可以将交易者与量子与程序员的案例联系起来，这更糟糕......
他们不讨论气象，也不讨论代码。