明日はクライアントとの最初のミーティングであり、そこで彼女は現在（手作業で）何をしているのか、そしてそれが何であるのか、新しいWebアプリケーションは最終的に何をすべきかを教えてくれます。
彼女が私にプロセスのステップを見せてくれる間、私は何をするのだろうと思いました。ユースケースを認識して直接モデル化しますか？プロセスを散文で説明しますか？実世界からモデルにプロセスを記述/転記するにはどうすればよいですか？モデルはコードの基礎になりますか？
新しい開発から始めるためのベストプラクティスは何ですか？任意のヒント？
プロセスと期待の管理がすべてであり、技術的なことはほとんど関係ありません。ほとんどのクライアントが犯す間違い (私見) は、特に小規模なコンサルタント会社では、固定価格の契約 (おそらく、T&M: 時間と材料が請求されるサポート付き) を選択することです。彼らはこれをリスク管理の演習として行っているため、理解できます。
問題は、彼らがその低いリスクに対して次の 3 つの方法で支払っていることです。
これらすべては、クライアントにとって最終結果をより高価なものにし、開発者 (300 ページの Word ドキュメントを書きたいと思う人がいるでしょうか? 真剣に!) をやる気にさせません。プロジェクトの長さに正比例します）。
多くの場合、T&M アプローチを何らかの形式のラピッド プロトタイピング手法と組み合わせて、通常の成果物またはクライアントへのデモンストレーションを 4 ～ 6 週間以内に提供することで、双方にとってより良いサービスが提供されます。これは、期待の管理に向けられています。クライアントが何かが起こっていることを確認できれば、クライアントは安心し、仕事を続けることができます (ガント チャートに沿った会議で時間を保留にするよりも)。
ですから、あなたがすべきことは、クライアントが何を得ているか、どのように進化しているかを確認し、プロセスに参加できる段階的なアプローチ（ベイビーステップ）に進むようにクライアントを説得することです. 結果が早く得られ、最終的には安価になります (両方の当事者がリスク負担を分担します)。
多くの開発者が忘れているように見えることの 1 つは、開発者が 15 世紀のフランスの王族のようなものだということです。彼らは特権、さらには富、そして多くの特典を持っているかもしれませんが、気まぐれで彼らを斬首することができる王（または女王）の喜びで奉仕します. つまり、クライアントは最終的に力を発揮し、開発者としてのあなたはクライアントの生活を楽にするために存在し、その逆ではないということです。
クライアントが上司の iPhone 上の仮想 Vax/VMS サーバー上で動作する Cobol on Rails で開発されたピンクとグリーンの Web サイトを望んでいる場合、それは彼らが手に入れるものです。これで、あなたの専門知識と経験を使って、それは良い考えではないことを彼らに納得させることができますが、最終的に彼らがそれを望んでいる場合は、2 つの選択肢があります。
あまりにも多くの開発者が、人々が求めるものではなく、持つべきだと思うものを人々に与えるという罠に陥ります。大ミス。プロセスの一部は、クライアントとのコミュニケーション チャネルを開いたままにしておくことです。これにより、クライアントがまったく異なる何かを期待しているときに、クライアントが何かを望んでいると考えている (または何かを持っている必要があると判断する) ことはありません。
小規模なソフトウェア開発プロジェクトでも、簡単に 6 桁に達することがあります。これは通常、お金を払っている人にとっては大きな投資です。彼らには緊張する権利があり、あなたには彼らを幸せにする責任があります。
ほとんどの開発者はこれを行うのに時間をかけず、すぐにクラス図とシステム アーキテクチャのモデリングに取りかかりますが、彼女が言及するすべての機能を書き留めることが何よりも重要です。グループ化や、それらがどのように組み合わされるかについて心配する必要はありません。現時点では、可能な限りすべての機能を彼女から取得する必要があります. 離れてアプリケーションについて考え始めると、機能の断片間の相関関係を描き始め、最終的にプロパティとメソッドを持つオブジェクトにグループ化されます。
Eric Evans による" Domain Driven Design "を心からお勧めします。問題のドメインをモデル化する方法を説明し、その過程で、あなたとクライアントがアプリケーションの機能について明確にコミュニケーションできるユビキタスな言語を確立します。
また、ターゲット プラットフォーム用の迅速な開発ツールを見つけられるかどうかも確認してください。そうすれば、クライアントの前で何かをすばやく入手して、初期のフィードバックを得ることができます。たとえば、Java EE を使用している場合は、ラウンドトリップをサポートするSpring Rooを調べてください。
私はあなたのクライアントがそれらのことについてあなたに話したいとは思わない...きっと、彼女はページがどのように構成されるべきか、そして物事がどのように機能することを期待しているかについてあなたにいくつかの図を見せようとしているに違いない.
彼女のプレゼンテーションに従って質問をするだけで (常にユーザーの観点から)、彼女が期待するように仕事をすることができます。技術的なことは自分に任せてください ;)
ユーザーは、それがどのように機能するかには興味がありません。彼らにとっては、インターフェースの構成と、操作を実行するために必要な手順がすべてです。上記の提案に同意し、機能とインターフェイスの要件を書き留めて、モデル化する方法と可能性を確認します。
分析が終わったら、できることとできないことについてもう一度話し、解決策や改善点を提示してください。
クライアントは、あなたが話した最初の 5 分間で、彼らが何を望んでいるかをあなたに伝えた可能性が高いです。それ以降はただのピロートークです。