是的，我知道标题是一个拗口...
我的意思是说你如何与需要理论编码和测试的主题专家沟通？
例如，天气模拟是气象学家、计算机科学家和软件工程师之间的合作。计算机科学家和软件工程师通常说同一种语言，但气象学家却处于完全不同的世界。
您如何提高学科之间的交流和理解水平？不一定只适用于天气，其他科学也是如此。
dacracot
问问题
279 次
9 回答
2
最短的答案是持续的客户参与。
所有漂亮的 UML 图、绘儿乐 UI 模型、对四岁孩子的解释和其他技术永远不会提供使用工作应用程序的完整体验。将消费者保持在循环中允许对客户以及从客户到您的反馈周期。这种共生关系最有可能生产出对他们有用的产品。
如果您进入一个盒子并拿出您认为他们需要的产品，那很可能是他们不想要的很多东西。通过定期演示您的产品，您可以限制任何误解的影响，这样您就不会花太多时间走错路。
它可以与航位推算相提并论。如果你蒙上自己的眼睛并试图在你熟悉的区域中导航，那么你所在的位置和你认为自己所在的位置之间的误差会随着时间的推移而累积。但是，如果您定期摘下眼罩，您可以更新您的心理位置。仍然会有一个错误因素，但您正在消除累积的错误因素。
即使您认为您的沟通/解释能力是一流的，您仍然必须考虑他们沟通方式中的错误。
于 2008-11-05T00:24:03.280 回答
2
状态图为这项任务创造了奇迹。它们允许您在适合与您交流的人的级别上表示计算过程。各州对那里进行的处理有一个简短的评论。状态之间的弧线显示了导致转换到新状态的条件。
构建了基本状态图后，您可以继续讨论输入状态机的信息。这是个人领域知识应该发挥作用的地方。通过图表跟踪一些数据以查看其处理流程。通常在这一点上，他们开始注意到尚未讨论的其他情况。
可能需要拖入另一个白板，将一个或多个状态展开为自己的状态图。
然后通常，当他们对流程感到满意时，就该将错误处理注入图表中了。
这种技术对我来说效果很好。
于 2008-11-05T01:07:38.650 回答
1
我一直发现流程图是普遍可以理解的，尤其是在表示算法时。流程图通常易于阅读和制作，并且被普遍理解。
于 2008-11-05T04:43:56.373 回答
1
“最短的答案是持续的客户参与。”
我建议你通过一些具体的方法来做到这一点。
一种可以快速发展的语言。Python 是我的选择，你的可能会有所不同。Java——例如——可能不会在你的列表中排名靠前，因为它需要一段时间才能让东西运行起来。对于快速开发，C++ 可能需要付出太多努力。
快速构建小东西。从可以开始对话的东西开始——任何东西——。构建、审查、扩展。
使用单元测试将结果形式化，使您能够尽早且经常地进行重构。
一旦你有了可靠的东西，你可以考虑用 Java 或 C++ 重写或其他东西来提高性能。
于 2008-11-05T01:04:52.587 回答
1
我认为大多数评论者所缺少的实际上对您的问题非常重要 - 您正在与领域专家合作构建他们的模型的实现以测试他们的理论的想法。
大多数软件工程的东西都不是关于这种制度的——就像你说的那样，这与实现一些业务流程或构建一个必须实现 RFCxxxx 的服务器在质量上是不同的。
有人在这方面工作——试图向科学家传授负责任的软件工程的基础知识（例如，Greg Wilson 的Software Carpentry）和向软件工程人员传授有关大规模计算科学的知识（例如，Steve Easterbrook 的非常有趣的博客，这与此特别相关）。我不知道为什么事情在这方面如此原始。两者在他们的博客上都有相关同事的链接。
这个制度与你可能学过的东西有许多重要的区别。其一，科学软件的整体结构一般都比较简单，但精妙之处相当高——每一行数字都可能是多个领域10年科学文献的结晶。其次，规范的整个想法有点被颠覆了——规范是“准确地模拟现实”，而科学家所拥有的是他们希望这样做的模型。在某种程度上，科学代码开发既是在实施规范草案，也是在摸索真正的规范。
@vfilby 有一个正确的想法——持续的客户参与——但不止于此。为此，您将进入科学循环 - 而不是科学家→理论→测试→解释→更新理论的循环，它将是科学家→理论→您编码→您和科学家都解释您自己的部分→更新理论和/或实施。领域科学家不会像您一样了解如何最好地实现他们想要的东西，或者如何将他们的模型结果与您的模型实现结果分开；另一方面，他们会比你更好地理解模型的含义以及如何更新理论。
这是一个很难平衡的行为。为了让它发挥作用，双方都必须（a）尊重对方的专业领域，（b）学习一些其他领域的知识，以及（c）在整个项目中投入工作。这类跨学科项目失败的次数多于成功的次数，但它们至关重要。我真的希望我有一些简单的，保证工作的技巧给你。
于 2010-12-14T22:39:43.710 回答
0
充当程序员，并使用“可能的最松耦合”方法。
对于气象学家的案例，我对这个领域略知一二，气象学家和程序员几乎没有就实际代码进行交流。那些程序员知道足够的数学来实现气象学家想要的任何方程，然后气象学家足够怪才可以使用该软件。
我还可以将交易员与量化人员与程序员的案例联系起来，这更糟……
他们不讨论气象学，也不讨论代码。
于 2010-12-14T17:40:51.240 回答
0
我在 Weiger 的东西上取得了很好的成功：http: //www.processimpact.com/reqs_book/reqs_book.shtml
首先做一个愿景和范围文件： http: //www.processimpact.com/pubs.shtml#requirements
于 2009-04-03T14:04:50.327 回答
0
你应该经常问自己，“我将如何向市场上的那个老奶奶解释这一点？”。一旦你掌握了这些，你就可以向几乎任何人谈论和解释你的方法和程序。如果他们有一些额外的知识，那就更好了。
如果你不能，那么也许你应该问自己“也许问题不在他们这边。”。即使是站在他们这边，尝试理解他们的观点也没有什么坏处。
就个人而言，我不是一名程序员，但只要我们都坚持上述原则，与程序员交谈从来没有任何问题。
于 2009-04-03T14:18:51.447 回答
0
非常小心和耐心。你不能假设理解，所以使用原型或图片等技术进行交流。
当客户发表声明时，您需要执行您认为他所说的内容，或者画出图片并展示给他。这样他更容易认清你的误解。我会避免冗长的书面描述，因为很难知道你是否理解。
客户不需要懂你的语言，所以不要试图教气象学家 CS 术语。你需要学习他的语言。即使是最微不足道的需求也应该使用原型进行测试。如果他们说：“我们需要看美国的地图”，那么你需要画一张美国的地图给他们看，然后说“这就是你想看的”吗？然后他会说“但我在这张地图上看不到密西西比河”然后你说“但你没有要求河流”然后回去重新绘制地图。等等等等
我曾经遇到过要求简单得多的情况，但出现了可怕的错误，因为客户认为它很简单，而我认为我理解。
于 2008-11-05T00:40:22.373 回答