ええ、私はタイトルが一口であることを知っています...
私が言いたいのは、コード化されテストされた理論を必要とする主題の専門家とどのようにコミュニケーションを取るかということです.
たとえば、気象シミュレーションは、気象学者、コンピューター科学者、およびソフトウェア エンジニアの共同作業です。コンピュータ サイエンティストとソフトウェア エンジニアは一般的に同じ言語を話しますが、気象学者はまったく別の世界にいます。
分野間のコミュニケーションと理解のレベルをどのように高めますか? 必ずしも天気だけではなく、他の科学も同様です。
ステート ダイアグラムは、そのタスクに驚異的な効果を発揮します。通信相手に適したレベルで計算プロセスを表すことができます。状態には、そこで行われる処理についての簡単なコメントがあります。状態間の弧は、新しい状態への遷移を引き起こす条件を示しています。
基本的なステート ダイアグラムを作成したら、次にステート マシンに供給される情報について説明します。これは、個人のドメイン知識が作用する場所です。ダイアグラムでいくつかのデータをたどって、データがどのように処理されるかの流れを確認します。通常、この時点で、これまで議論されていなかった他の状況に気付き始めます。
別のホワイト ボードにドラッグして、1 つまたは複数の状態を独自の状態図に展開する必要がある場合があります。
その後、一般的に、フローに慣れてきたら、エラー処理を図に挿入します。
このテクニックは私にとってかなりうまくいきました。
可能な限り最短の答えは、継続的な顧客関与です。
美しい UML ダイアグラム、クレヨラ UI モックアップ、4 歳児への説明、およびその他の手法をすべて使用しても、実際のアプリケーションを完全に使用することはできません。消費者をループに入れておくことで、クライアントとクライアントからあなたへのフィードバックサイクルが可能になります。この共生関係は、彼らにとって有用な製品を生み出す可能性が最も高い.
箱に入って、彼らが必要だと思う製品が出てきた場合、それはおそらく彼らが望んでいないものがたくさんあるでしょう. 製品のデモを定期的に行うことで、誤解による影響を最小限に抑えることができ、間違った方向に進むのに多くの時間を費やすことはありません。
それは推測航法と比較することができます。目隠しをして、知っている場所を移動しようとすると、現在地と自分がいると思っている場所との誤差が時間とともに蓄積されます。ただし、定期的に目隠しを外せば、心の位置を更新できます。誤差要因は残りますが、累積誤差要因を排除しています。
自分のコミュニケーション能力や説明能力が一流だと思っていても、彼らのコミュニケーション方法の間違いを考慮しなければなりません。
「可能な限り最短の答えは、継続的な顧客関与です。」
いくつかの特定のアプローチを通じてこれを行うことをお勧めします。
すぐに開発できる言語。Python が私の選択ですが、あなたの選択は異なる場合があります。たとえば、Java はリストの上位には入らないかもしれません。C++ は、迅速な開発には労力がかかりすぎる可能性があります。
小さなものをすばやく構築します。会話を始めることができる何かから始めましょう。ビルド、レビュー、拡張。
早期に頻繁にリファクタリングできる単体テストで結果を形式化します。
しっかりしたものができたら、Java や C++ などで書き直してパフォーマンスを向上させることを検討できます。
ほとんどのコメント投稿者が見逃していることは、実際にはあなたの質問にとって非常に重要だと思います-ドメインの専門家と協力して、彼らの理論をテストするためのモデルの実装を構築しているという考えです.
そこにあるソフトウェアエンジニアリングのほとんどは、この体制についてではありません-そして、あなたが言うように、これは、いくつかのビジネスプロセスの実装またはRFCxxxxを実装する必要があるサーバーの構築とは質的に異なるだけです.
科学者に責任あるソフトウェア エンジニアリングの非常に基本的なことを教えようとしている (例: Greg Wilson のSoftware Carpentry ) と、ソフトウェア エンジニアリングの人々に大規模な計算科学について教えている (例: Steve Easterbrook の非常に興味深いブログ)という、両端からこれに取り組んでいる人々がいます。、これは特に関連性があります)。なぜ物事がこの面で原始的なのか、私にはわかりません。どちらもブログロールに関連する同僚へのリンクがあります。
このレジームには、あなたが教えられたかもしれないものとは多くの重要な違いがあります. 1 つには、科学ソフトウェアの全体的な構造は一般に非常に単純ですが、その繊細さは非常に高く、数値の各行は、多くの分野における 10 年間の科学文献の結果である可能性があります。第二に、仕様の全体的な考え方がひっくり返されます。仕様は「現実を正確にモデル化する」ものであり、科学者が持っているのは、科学者がそれを望んでいるモデルです。ある意味で、科学的なコード開発は、ドラフト仕様を実装することと、実際の仕様を模索することの両方です。
@vfilby は正しい考えを持っています - 継続的な顧客の関与 - しかし、それはそれ以上のものです. これが機能するためには、科学者→理論→テスト→解釈→理論の更新というサイクルではなく、科学者→理論→あなたがコード化する→あなたと科学者の両方が自分自身を解釈するというサイクルに入る必要があります。部品→理論および/または実装の更新。ドメイン サイエンティストは、自分が望むものを最適に実装する方法や、モデルの実装結果からモデルの結果を解きほぐす方法をあなたほどよく知りません。一方、彼らはモデルの意味をあなたよりもはるかによく理解し、理論を更新する方法を理解するでしょう.
これは、バランスを取るのが難しい行為です。それが機能するためには、双方が (a) 他の専門分野を尊重し、(b) その他の分野について少し学び、(c) プロジェクト全体に投資する必要があります。この種の学際的なプロジェクトは、成功するよりも失敗することが多いですが、非常に重要です。簡単で確実に機能するヒントがあればいいのにと思います。
特にアルゴリズムを表す場合、フローチャートは普遍的に理解できるものであることが常にわかってきました。フローチャートは一般的に読みやすく、作成しやすく、広く理解されています。
私は Weiger のものでうまくいきました: http://www.processimpact.com/reqs_book/reqs_book.shtml
ビジョンとスコープのドキュメントを作成することから始めます: http://www.processimpact.com/pubs.shtml#requirements
「市場にいるおばあさんにこれをどう説明したらいいのだろう？」と常に自問する必要があります。それがカバーされたら、あなたの方法と手順をほとんど誰にでも話して説明することができます. 彼らが追加の知識を持っていれば、さらに良いでしょう。
それができない場合は、「問題は彼らの側にないのかもしれない」と自問する必要があります。たとえそれが彼らの側にあるとしても、彼らの視点を理解しようとすることに害はありません.
個人的には、私は本業のプログラマーではありませんが、前述の原則に固執している限り、プログラマーと話すことに問題はありませんでした。
細心の注意と忍耐をもって。理解していると仮定することはできないため、プロトタイピングや写真などの手法を使用して伝達します。
顧客が発言したら、その発言を実行するか、絵を描いて顧客に見せる必要があります。このようにして、彼はあなたの誤解を認識しやすくなります。あなたが理解しているかどうかを知るのは非常に難しいので、私は長い記述を避けます.
顧客はあなたの言語を知る必要はないので、気象学者に CS 用語を教えようとしないでください。あなたは彼の言語を学ぶ必要があります。最も些細な要件であっても、プロトタイプでテストする必要があります。彼らが「私たちはアメリカの地図を見る必要がある」と言ったら、あなたはアメリカの地図を描いて見せ、「あなたが見たいのはこれですか」と言う必要がありますか? 彼は、「でも、この地図にはミシシピ川が見えません」と言いますが、あなたは「でも、川を求めていませんでした」と言うと、戻って地図を描き直します。などなど
顧客はそれが単純であると想定し、私は理解していると想定したため、はるかに単純な要件がひどく間違った状況に陥ったことがあります。
プログラマーとして行動し、「可能な限り疎結合」のアプローチを使用します。
気象学者の場合、私はその分野について少し知っていますが、気象学者とプログラマーは実際のコードについてほとんどコミュニケーションをとっていません。それらのプログラマーは、気象学者が望む方程式を実装するのに十分な数学を知っており、気象学者はソフトウェアを使用するのに十分なオタクです。
トレーダー対クオンツ対プログラマーのケースを関連付けることもできますが、これはさらに悪いことです...
彼らは気象学については議論しませんし、コードについても議論しません。