跨學科網絡的工程與非開發商

Question

是啊，我知道標題是滿嘴...

我的意思是說的是你怎麼用誰需要一個理論編寫和測試的主題專家溝通？

例如，天氣模擬是氣象學家，計算機科學家和軟件工程師之間的合作。計算機科學家和軟件工程師通常講同一種語言，但他的氣象學家處於一個完全不同的世界。

你如何提高學科之間的溝通和理解水平？而不一定只是爲了天氣，其他科學也是如此。

Answer 1

最短的答案是持續的客戶參與。

所有漂亮的UML圖，繪兒樂UI模型，解釋到四歲的孩子和其他技術將永遠不會給使用工作應用程序的完整體驗。保持消費者在循環中可以給客戶和從客戶到你的反饋週期。這種共生關係最有可能生產出對他們有用的產品。

如果你進入一個盒子，拿出一個你認爲他們需要的產品，它可能會是他們不想要的東西的很多。通過定期演示您的產品，您可以限制任何誤解的影響，這樣您就不會花太多時間走錯路。

它可以與航位推算相比較。如果你蒙着眼睛並嘗試在一個你知道的區域進行導航，那麼你的位置和你認爲的位置之間的錯誤將會隨着時間而積累。但是，如果您定期摘下眼罩，則可以更新您的精神位置。仍然會有一個錯誤因素，但你正在消除累積的錯誤因素。

即使你認爲你的溝通/解釋能力是一流的，你仍然必須考慮到溝通方式的錯誤。

Answer 2

非常謹慎和耐心。你不能假設理解，所以使用原型或圖片等技術進行交流。

當客戶發表聲明時，您需要實現您認爲他所說的內容，或者爲其繪製照片並展示給他。他更容易以這種方式認識到你的誤解。我會避免長時間的書面描述，因爲如果你理解它很難知道。

客戶不需要知道您的語言，所以不要試圖教氣象學家的CS行話。你需要學習他的語言。即使是最微不足道的要求也應該用原型來測試。如果他們說：「我們需要看一張美國地圖」，那麼你需要繪製一張美國地圖，並向他們展示並說出「這就是你想看的東西」？然後他會說「但是我不能在這張地圖上看到mississipi河」，那麼你就會說「但是你沒有問河流」然後回去重繪地圖。等等

我有很多簡單的要求，因爲客戶認爲它很簡單，我認爲我明白了，可怕的錯誤的情況。

Answer 3

「最短的答案是持續的客戶參與。」

我建議你通過一些特定的方法來做到這一點。

1. 一種可以快速開發的語言。 Python是我的選擇，你可能會有所不同。例如，Java可能不在你的列表中，因爲它需要一段時間才能讓東西運行起來。 C++可能爲快速開發付出太多努力。

2. 快速構建小東西。從某件事開始 - 任何事 - 可以讓對話開始。建設，審查，擴大。

3. 使用允許您及早重構的單元測試形式化結果。

一旦你有了堅實的東西，你可以考慮用Java或C++或其他東西來重寫，以提高性能。

Answer 4

狀態圖該任務的工作奇蹟。它們允許您在適合您與之通信的人的級別上表示計算過程。各州對那裏的處理進行簡要評論。狀態之間的弧顯示導致過渡到新狀態的條件。

已經構建了基本狀態圖，您可以繼續討論正在饋入狀態機的信息。這是領域知識應該發揮作用的地方。按照圖中的一些數據查看處理流程。通常在這一點上，他們開始注意到其他尚未討論的情況。

可能需要在另一個白板中拖動一個或多個狀態到其自己的狀態圖中。然後，一般來說，當他們對流程感到滿意時，是時候向圖表中注入錯誤處理了。

這種技術對我來說工作得很好。

Answer 5

我一直髮現流程圖是普遍可以理解的，特別是在表示算法時。流程圖通常易於閱讀和製作，並且被普遍理解。

Answer 6

我已經與Weiger的東西很好的成功： http://www.processimpact.com/reqs_book/reqs_book.shtml

開始做一個視圖和範圍文檔： http://www.processimpact.com/pubs.shtml#requirements

Answer 7

你應該總是問自己：「我怎麼會解釋這是OL 「市場上的奶奶？」。一旦你有了這些，你可以向任何人講述和解釋你的方法和程序。如果他們有一些額外的知識，甚至更好。

如果你不能，也許你應該問自己「也許問題不在他們這邊。」即使它站在他們的旁邊，也沒有什麼壞處來試圖理解他們的觀點。

就我個人而言，我不是貿易程序員，但從來沒有任何問題與人談話，只要我們都堅持上述原則。

Answer 8

充當程序員，並使用「最鬆散的耦合可能」方法。

對於氣象學家的情況，我知道一點點領域，氣象學家和程序員的實際代碼幾乎沒有溝通。那些程序員知道足夠的數學來實現氣象學家想要的任何方程，然後氣象學家對這個軟件足夠了解。

我也可能涉及交易者VS寬客VS程序員的情況下，這更是雪上加霜......

他們沒有討論氣象，他們不討論代碼。

Answer 9

我想大多數評論者都缺少實際上是非常重要的你的問題 - 你與領域專家合作，以建立自己的模型的實現，以測試他們的理論的想法。

大多數軟件工程的東西在那裏是不是這個政權 - 而像你說的，這只是比實現一些樓內設有商務過程或構建需要實現RFCxxxx服務器qualitiatively不同。

有兩個人從事這方面的工作 - 試圖教授科學家有關負責任軟件工程的基礎知識（例如Greg Wilson的Software Carpentry）和教授關於大規模計算科學的軟件工程人員（例如Steve Easterbrook的very interesting blog，其中this尤其相關）。爲什麼事情和他們在這方面一樣原始，我不知道。兩者都有相關聯的博客上相關的同事。

有一些在這個政權的東西，你可能被教導的重要差異。一方面，科學軟件的整體結構通常非常簡單，但微妙程度相當高 - 每一行數字可能是許多領域10年科學文獻的結果。其次，規格類型的整體概念被顛覆 - 規範是「準確地模擬現實」，科學家擁有的是他們希望這樣做的模型。從某種意義上說，科學代碼開發既實施了草案規範，又摸索了真正的規範。

@vfilby排序的看法是正確的 - 連續客戶的參與 - 但它比這多一點。對於這個工作，你會得到投入科學循環 - 而不是週期是科學家→理論→測試→解釋→更新理論，這將是科學家→理論→你的代碼→你和科學家都解釋您自己的零件→更新理論和/或實施。領域科學家不會像你那樣瞭解如何最好地實現他們想要的，或者如何將他們模型的結果與實施模型的結果分開;另一方面，他們會理解模型的含義比你更好，以及如何更新理論。

這是一個很難平衡的行爲。爲了使其發揮作用，雙方必須（a）尊重其他領域的專業知識，（b）學習其他領域的一些知識，並（c）將整個項目投入到整體工作中。這些跨學科項目在成功後會更頻繁地崩潰，但它們非常重要。我真的希望我有一些簡單的，保證工作的提示給你。